8 ms·

The consultants have taken over "Agile" and turned it into a process-heavy set of practices. Over the course of a 2 week sprint I spend more than 8 scheduled h

The consultants have taken over "Agile" and turned it into a process-heavy set of practices. Over the course of a 2 week sprint I spend more than 8 scheduled hours in various meetings (grooming, planning, scrums,etc.) http://programming-motherfucker.com/ http://programming-motherfucker.com/

iovrthoughtthis 9y ago
Safety in process. Ironic that one of the principals of agile is "people over processes"
throwaway2016a 9y ago
To play devil's advocate... that is 10% of your time in meetings that are defined by scrum to have specific goals that should be accomplished in each. It is possible (every case varies) that that 10% of time spent has a multiplying increase on product quality. It is equally if not more probable it is a waste of time too though. Especially if the scrum master can't stay focused. I've been able to get 20 person scrum / standup meetings on schedule for 15 minutes every day from scheduled start to end. You could set your clock by it. But I've seen other teams take a half hour for less people. That is ridiculous. As a fun anecdote, once I gave a project estimate and my client paid us to do detailed project planning because he didn't believe the estimate. We spent 3 days (with 5 people in the room) in requirements gathering, specing, and estimating stories. The end result... 5% more than my "wild guess" that I gave the client originally (that they already thought was too high) only now the client had to also pay for the additional 120 hours we spent in planning. They asked incredulous how my "wild guess" could have been so close and my only answer was... experience. But in the absence of experience those meetings could have provided a valuable service.
- thesz 9y ago
  The time it takes to return to focused/productive state is roughly proportional to interruption time. So this guy above spent 10% of time on meetings and another 10% of his time on the exists and returns to productive state.
- OnlyRepliesToBS 9y ago
  The last sentence is nothing but hope. But the company was definitely billed for consultancy. This pattern of snake oil keeps repeating, all to sell you the ability to force developers to follow Order by PM. This goalpost moving is evil.
- knightofmars 9y ago
  > The end result... 5% more than my "wild guess" How long did the project actually take?
  - throwaway2016a 9y ago
    We missed target but it was because the client changed a major requirement half way through after they saw it working the way they originally requested. I believe that if that didn't happen we would have hit target. Another argument against up-front estimating and fixed cost projects. It doesn't take into consideration things like that. But to that point, really target + what it took to do the estimation. So an extra week + the money..
DanielBMarkham 9y ago
The consultants have taken over "Agile" No, what's happened is that BigCorp has decided to adopt Agile and won't adopt anything without a lot of instruction books and role descriptions. The consultants, at least the ones who know what they're doing, have been trying to fight this all along. It's the industry itself that continues to over-engineer everything it touches, from Javascript frameworks to development processes. What we keep finding is that you can't keep people from themselves, that is, if you don't give somebody a 47-page instruction book full of diagrams and processes they want, somebody else will. I really, really wish the problem with Agile was simply the consultants. Instead, as we've seen with process after process, we keep screwing it up, feeling that the more of something we have, the better it must be. Consultants, tool vendors, trainers, and the like? They're just adjusting their marketing pitch to what people want to hear.
- sidlls 9y ago
  It isn't just a "BigCorp" organizational issue. You touched on it, but gently: developers share some blame here. There's a real anti-engineering bias in this industry. I mean engineering as it's practiced in other contexts. There is a process of design and analysis that is done before build and implementation starts that in this industry is considered wasteful or work to be done by lesser mortals who aren't smart enough to code. That's a big reason why there's all this over-engineering of everything.
  - jerf 9y ago
    I am honestly having trouble parsing through how you simultaneously accuse engineers of being too lazy to use process and then agreeing that there is too much process. I don't engineer as other engineering disciplines do, because my world is not like other engineering disciplines. If architects could push a button and see a skyscraper built in five minutes, then push another button to tear it down and build it with a slightly tweaked again, for basically no cost, often while clients are actually living in the building (!), you'd see them doing a lot less up-front planning from them, too. Stop having "real engineering" envy. As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer. No, we are not in fact specially stupid or lazy, which is exactly the same mistake as thinking we are specially smart or industrious. We're neither, and we do the things we do for reasons every bit as good as the reasons for their processes.
Scarblac 9y ago
Wasn't the Agile Manifesto written by a group of consultants in the first place? I mean they say "individuals and interactions over processes and tools".
brightball 9y ago
Project management is one part resource planning, one part psychology. Waterfall is what happens when you slide all the way toward resource planning and ignore the psychological side of the house. Kanban is probably the farthest to the psychology side you can get in a productive manner. Scrum is somewhere in the middle, but the bigger the organization the more they try to steer towards waterfall. What a lot of business fail to recognize is that different strategies match different businesses. Scrum is a great fit for contract companies with multiple clients. In a larger company where you are continuously building one project, you need to be able to move as fast as your developers can go. That generally means Kanban.
spamizbad 9y ago
> The consultants have taken over "Agile" Taken over? Nah, Agile is native to consultants: Many of the thought leaders behind Agile are consultants themselves.
- gaius 9y ago
  Agile exists to sell books, consulting, training etc If any software gets produced, that is mere coincidence

iovrthoughtthis 9y ago

Safety in process. Ironic that one of the principals of agile is "people over processes"

throwaway2016a 9y ago

To play devil's advocate... that is 10% of your time in meetings that are defined by scrum to have specific goals that should be accomplished in each. It is possible (every case varies) that that 10% of time spent has a multiplying increase on product quality. It is equally if not more probable it is a waste of time too though. Especially if the scrum master can't stay focused. I've been able to get 20 person scrum / standup meetings on schedule for 15 minutes every day from scheduled start to end. You could set your clock by it. But I've seen other teams take a half hour for less people. That is ridiculous. As a fun anecdote, once I gave a project estimate and my client paid us to do detailed project planning because he didn't believe the estimate. We spent 3 days (with 5 people in the room) in requirements gathering, specing, and estimating stories. The end result... 5% more than my "wild guess" that I gave the client originally (that they already thought was too high) only now the client had to also pay for the additional 120 hours we spent in planning. They asked incredulous how my "wild guess" could have been so close and my only answer was... experience. But in the absence of experience those meetings could have provided a valuable service.

thesz 9y ago
The time it takes to return to focused/productive state is roughly proportional to interruption time. So this guy above spent 10% of time on meetings and another 10% of his time on the exists and returns to productive state.
OnlyRepliesToBS 9y ago
The last sentence is nothing but hope. But the company was definitely billed for consultancy. This pattern of snake oil keeps repeating, all to sell you the ability to force developers to follow Order by PM. This goalpost moving is evil.
knightofmars 9y ago
> The end result... 5% more than my "wild guess" How long did the project actually take?
- throwaway2016a 9y ago
  We missed target but it was because the client changed a major requirement half way through after they saw it working the way they originally requested. I believe that if that didn't happen we would have hit target. Another argument against up-front estimating and fixed cost projects. It doesn't take into consideration things like that. But to that point, really target + what it took to do the estimation. So an extra week + the money..

DanielBMarkham 9y ago

The consultants have taken over "Agile" No, what's happened is that BigCorp has decided to adopt Agile and won't adopt anything without a lot of instruction books and role descriptions. The consultants, at least the ones who know what they're doing, have been trying to fight this all along. It's the industry itself that continues to over-engineer everything it touches, from Javascript frameworks to development processes. What we keep finding is that you can't keep people from themselves, that is, if you don't give somebody a 47-page instruction book full of diagrams and processes they want, somebody else will. I really, really wish the problem with Agile was simply the consultants. Instead, as we've seen with process after process, we keep screwing it up, feeling that the more of something we have, the better it must be. Consultants, tool vendors, trainers, and the like? They're just adjusting their marketing pitch to what people want to hear.

sidlls 9y ago
It isn't just a "BigCorp" organizational issue. You touched on it, but gently: developers share some blame here. There's a real anti-engineering bias in this industry. I mean engineering as it's practiced in other contexts. There is a process of design and analysis that is done before build and implementation starts that in this industry is considered wasteful or work to be done by lesser mortals who aren't smart enough to code. That's a big reason why there's all this over-engineering of everything.
- jerf 9y ago
  I am honestly having trouble parsing through how you simultaneously accuse engineers of being too lazy to use process and then agreeing that there is too much process. I don't engineer as other engineering disciplines do, because my world is not like other engineering disciplines. If architects could push a button and see a skyscraper built in five minutes, then push another button to tear it down and build it with a slightly tweaked again, for basically no cost, often while clients are actually living in the building (!), you'd see them doing a lot less up-front planning from them, too. Stop having "real engineering" envy. As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer. No, we are not in fact specially stupid or lazy, which is exactly the same mistake as thinking we are specially smart or industrious. We're neither, and we do the things we do for reasons every bit as good as the reasons for their processes.

Scarblac 9y ago

Wasn't the Agile Manifesto written by a group of consultants in the first place? I mean they say "individuals and interactions over processes and tools".

brightball 9y ago

Project management is one part resource planning, one part psychology. Waterfall is what happens when you slide all the way toward resource planning and ignore the psychological side of the house. Kanban is probably the farthest to the psychology side you can get in a productive manner. Scrum is somewhere in the middle, but the bigger the organization the more they try to steer towards waterfall. What a lot of business fail to recognize is that different strategies match different businesses. Scrum is a great fit for contract companies with multiple clients. In a larger company where you are continuously building one project, you need to be able to move as fast as your developers can go. That generally means Kanban.

spamizbad 9y ago

> The consultants have taken over "Agile" Taken over? Nah, Agile is native to consultants: Many of the thought leaders behind Agile are consultants themselves.

gaius 9y ago
Agile exists to sell books, consulting, training etc If any software gets produced, that is mere coincidence