251–260 of 320 posts
The problem I see with various flavors of Agile is that they don't fit in particularly well with how things actually get done at companies. For example, teams running Agile are very reluctant to give both a delivery date and a fixed set of features. They're willing to promise one or the other, but not both. And that's a problem, because the whole rest of the organization really wants to know when they can announce th…
So my next task, obviously, was to define the content of all the sprints and write them down in the proposal. I was well aware of the absurdity of the whole thing but did it anyway, carefully planning out what would be done in each sprint. Sure, it sounds stupid, but just look at how cute it is! It's like a whole bunch of little waterfalls! People pay good money to see such nice waterfalls, you know!
Earlier quoted context omitted.
> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…
The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…
Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto.
> I once had it used against me to justify not writing tests
If you thought of your work as a complex system where there are a lot of variables which have multiple underlying causes, then you would have been able to describe some undesirable effect as being heavily caused by not having writing tests. And really, this is why people don't get Agile--they don't see their work and their organization as a complex system.
Earlier quoted context omitted.
> This sounds soul-crushing and I hope never to work in such an environment. It isn't. Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.
The "scrum master" is not telling you how long a ticket will take. They're asking you, can you break this ticket down any further? I see that you have a task to implement validation in the phone number field, can we break that down into three tasks? Determining the format which needs to be applied and edge cases, adding validation to the field on the client side, and also on the server side? Right away, thinking abou…
It was a special place to work.
Agile taught me about refactoring but in reality I get less opportunity to refactor bad code than I've had under Waterfall-type process. My understanding of our evolution into Agile has always been like: 1. Big Ball of Mud: work without a plan 2. Waterfall and alike: make a very elaborate plan and stick to it 3. Agile: work without a plan, but promptly refactor issues caused by lack of foresight Waterfall worked well…
Three months ago I found myself writing a proposal for work that would take several times the budget that was available. A manager had an idea: why not do it 'agile'? We would have two-week sprints, and at the end of each sprint a meeting with the customer to present work and define the direction of the next sprint. Great idea, right? So my next task, obviously, was to define the content of all the sprints and write…
Earlier quoted context omitted.
The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…
> It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto. > I once had it used agai…
Funnily enough the features of language which are ideally suited for flirtation and writing poetry and preaching religion or nationalism and other such "let your fantasy go wild and fill in the gaps" uses of language aren't as appropriate when you're doing engineering.
Law and contracts ARE different (more like engineering), incidentally. What is described as "legalese" actually exists because non-legal equivalent language is often insufficiently precise and subject to dangerous and costly misinterpretation. Mathematical discussion has the same problem to such an extreme degree that it's almost pointless using English at all most of the time.
>And really, this is why people don't get Agile
The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.
Earlier quoted context omitted.
This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iter…
Co located teams is what you really need (sorry WFH fans)
The majority will rather pick other vendor that doesn't propose such change into their internal processes.
Unless they are asking for consultation on how to change work processes, that is.
Earlier quoted context omitted.
This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iter…
Co located teams is what you really need (sorry WFH fans)
Three months ago I found myself writing a proposal for work that would take several times the budget that was available. A manager had an idea: why not do it 'agile'? We would have two-week sprints, and at the end of each sprint a meeting with the customer to present work and define the direction of the next sprint. Great idea, right? So my next task, obviously, was to define the content of all the sprints and write…
Last office had a team with 5-years of well planned out sprints. I could never dissuade them from the notion that this was "agile". They didn't use the end of each sprint to change direction if a problem was coming up, sticking to the plan for months after things started going wrong. Then they sat down and redid the next 4 years or so of sprints. Repeated after the next year. I guess it was more agile than making a 5…
Of course I'm assuming that they'll kick us off next week. Right now the project is in the "let's delay starting until missing the deadline is guaranteed" stage. One more week, and then my careful planning will have become officially impossible and it will be panic all around, and demands that I work days, nights, and weekends to make up for the delay they themselves caused.
Do you want to guess who isn't allowed to go on holiday because of this incredibly urgent project? :-(