6 ms·

The reason agile came to prominence 20 years ago was that responding to change was more valuable than sticking to a plan. And yet, this feels more relevant tha

The reason agile came to prominence 20 years ago was that responding to change was more valuable than sticking to a plan. And yet, this feels more relevant than ever. Agile has been thoroughly taken over by management and consultants. We might have some new tools and phrases, but behind the facade it’s all waterfall. And that comes with sticking to the plan with the caveat that certain special people absolutely can change the plan, in some cases very quickly and dramatically. Having something empirical to point to that maybe that reduces productivity is absolutely a positive.

keyle 4y ago
It's very true, but to get agile to work well, I found you need quality senior people at every levels. Otherwise, gateways come in place to make up for the lack of experience... and you wind back in the waterfall hell scape. Also a lot of people have taken in agile and bastardised it. They kept the keywords and love it in business speak, but won't let a sprint run without putting their hands on everything and everyone, destroying the actual velocity of the said team. And that is I think why so many people now hate agile. We went from increased engagement and transparency to impossibility to concentrate.
- carschno 4y ago
  Whenever I join a new company, I encounter this phrase sooner or later: > This is X, project manager. But we actually call her/him product owner because we do agile.
  - donkeyd 4y ago
    I had one assignment where we had a Scrum Manager. He was a project manager who was also the scrum master. Luckily he was aware of the conflict in these roles, so he took my criticism well and was later replaced by an actual scrum master.
mushbino 4y ago
It's hard to create something innovative or new using agile. Things always seem to turn into a feature factory.
- papito 4y ago
  Agile has nothing to do with it. That just sounds like lack of general vision and direction. Or complete misunderstanding of Agile. "We have only two weeks, so we can't undertake anything big that spans multiple sprints!"
  - lightbendover 4y ago
    Plenty of managers do lack vision and direction (often feels like the norm) so it's not surprising that they lack creativity when it comes to assigning work to be completed within a single sprint. If they were free of that self-imposed creative barrier, they may be better positioned to develop an overall strategy.
friendzis 4y ago
> but behind the facade it’s all waterfall. That is to be expected, because "waterfall" or pipeline is the general structure of work. At the very least you have design, production and verification steps. Agile is not about removal of waterfall, but rather applying 1. waterfalls to small chunks of work 2. multiple "tiers" of waterfall. The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project. If you start building image manipulation software you generally do not pivot to building a presentation software without redefining or scrapping the "master" waterfall. Stages of the whole project generally do have dependencies on other stages, there is no way around that. As long as you have at least some visibility into the project you are going to have stages and checkpoints and in the end a "waterfall" will surface somewhere. Waterfall is at the core a way to represent staged/checkpointed work.
- vegetablepotpie 3y ago
  My argument is that the things that waterfall specializes in, which is managing stages of work and dependencies between work is actually insignificant to the success of projects people care about. Waterfall is good when you are building structures. But value exclusively comes from the integration, verification, validation, and deployment of structures. With these types of tasks, the variance in estimates exceeds the mean of those estimates. Effective workers constantly probe different pathways to success and this makes your project network, with its delineated stages and strict dependencies, totally divorced from reality. The outcome of knowledge work, is knowledge. Not story points allocated, not dollars spent, not time used. The best hope of having a project management approach with valid predictive power is to track knowledge earned and not EVMS metrics satisfied.
- donkeyd 4y ago
  > you generally do not pivot I'm just going to grab this tiny part and focus on it. I've seen Agile fail many times for this exact reason. In start-up land, one might pivot and massively change an end goal. In corporate land that's a lot less off a thing. I've worked on some big projects in government and fortune 500, all of them pretended to be Agile and all of them had predefined scopes, deadlines and budgets. In all of those projects, Agile was more of a disturbing factor than anything else. The only flexible part was the scope of work, because of renewed insights or lack of specification while planning. This always ends with teams getting pressured to make deadlines (because those are never flexible), so they cut corners and work extra long hours. I think it would be much better for these types of projects (and the sanity of devs) not to pretend to be doing Agile, but just admit they want a more Prince2 led Waterfall approach. This won't happen though, because that puts the pressure with management in stead of the dev teams.
albert_e 4y ago
Managers with half knowledge and semi sincere attitudes have tried to pull "agile means you need to be flexible" on my team. To force a scope change and brand new stories in the middle of a 2-week sprint. The same folks would not accept any explanation whatsoever on why some stories didn't make the sprint delivery -- even if the blockers were completely in their court. These buzz words just become intimidation tools at times. A junior team member cannot say it to their face that Agile doesnt mean what they think it means and should learn things before they speak.
- lightbendover 4y ago
  Back when I was a software manager, I had to sequence work into sprints or everyone (up and down) would freak out. The part I relaxed the team on: I didn't care at all if work spilled over into the next sprint. This alone removed the stress of adding mid-sprint activities (which obviously needs to be done from time to time for at minimum reactionary purposes) and allowed more thoughtful medium-term analysis and execution. I was still on-time for delivery (at least above par on delivery timelines compared to sister teams), but with much less burn-out and generally more favorable ratings and well-constructed systems. The thought that any meaningful work (including components of meaningful work) would naturally fall within a 2 week period of time has always baffled me. That said, I have always been very good at identifying critical paths, minimal requirements, and estimated effort; I'm not sure if this strategy would work well without sufficient planning.
  - grugagag 4y ago
    > The thought that any meaningful work (including components of meaningful work) would naturally fall within a 2 week period of time has always baffled me. Sprint duraration is supposed to be flexible and adjusted to each project type and yet everywhere I’ve been workint at it’s always 2 weeks
AnimalMuppet 4y ago
An amazing comment about the difference between agile and waterfall: https://news.ycombinator.com/item?id=29458652 https://news.ycombinator.com/item?id=29458652 Still the best comment I've seen on the topic.
- knob 4y ago
  Thanks for sharing. Loved it.
snarf21 4y ago
In my many years of software, I've come to the following conclusion: The "worst" process followed consistently across all levels of a company will always outperform the "best" process followed haphazardly with no real buy-in. The reason agile fails at so many companies is that Product and Leadership don't want to do the hard work of keeping an up to date rank ordered list of groomed and deconstructed work that provides the greatest value to the business. Agile is about progress and learning and using that new information to decide what to do next. At my current company we are using SAFe, where you plan 3 months of work at a time which is the complete opposite of being agile. Again, it asks the wrong questions. It asks "What are we committing to during this PI?" instead of "What is the most important and business value adding tasks we should be working on?" Leadership only wants the answer to when it will be done but that is up to them. It will get done as soon as they make it the highest priority thing.
- nradov 4y ago
  SAFe doesn't require planning in 3-month program increments. The methodology is flexible and allows much shorter planning horizons when appropriate such as when the team is small and requirements are in rapid flux. I think everyone understands that running long program increments isn't ideal from an agile development perspective. However, sometimes it is the least bad option for the enterprise as a whole. There are often a variety of program stakeholders outside the core team who can provide valuable input but aren't always available. It's a lot more practical to pull in everyone for two days of focused PI planning than to try to chase them down and schedule meetings on demand.

keyle 4y ago

It's very true, but to get agile to work well, I found you need quality senior people at every levels. Otherwise, gateways come in place to make up for the lack of experience... and you wind back in the waterfall hell scape. Also a lot of people have taken in agile and bastardised it. They kept the keywords and love it in business speak, but won't let a sprint run without putting their hands on everything and everyone, destroying the actual velocity of the said team. And that is I think why so many people now hate agile. We went from increased engagement and transparency to impossibility to concentrate.

carschno 4y ago
Whenever I join a new company, I encounter this phrase sooner or later: > This is X, project manager. But we actually call her/him product owner because we do agile.
- donkeyd 4y ago
  I had one assignment where we had a Scrum Manager. He was a project manager who was also the scrum master. Luckily he was aware of the conflict in these roles, so he took my criticism well and was later replaced by an actual scrum master.

mushbino 4y ago

It's hard to create something innovative or new using agile. Things always seem to turn into a feature factory.

papito 4y ago
Agile has nothing to do with it. That just sounds like lack of general vision and direction. Or complete misunderstanding of Agile. "We have only two weeks, so we can't undertake anything big that spans multiple sprints!"
- lightbendover 4y ago
  Plenty of managers do lack vision and direction (often feels like the norm) so it's not surprising that they lack creativity when it comes to assigning work to be completed within a single sprint. If they were free of that self-imposed creative barrier, they may be better positioned to develop an overall strategy.

friendzis 4y ago

> but behind the facade it’s all waterfall. That is to be expected, because "waterfall" or pipeline is the general structure of work. At the very least you have design, production and verification steps. Agile is not about removal of waterfall, but rather applying 1. waterfalls to small chunks of work 2. multiple "tiers" of waterfall. The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project. If you start building image manipulation software you generally do not pivot to building a presentation software without redefining or scrapping the "master" waterfall. Stages of the whole project generally do have dependencies on other stages, there is no way around that. As long as you have at least some visibility into the project you are going to have stages and checkpoints and in the end a "waterfall" will surface somewhere. Waterfall is at the core a way to represent staged/checkpointed work.

vegetablepotpie 3y ago
My argument is that the things that waterfall specializes in, which is managing stages of work and dependencies between work is actually insignificant to the success of projects people care about. Waterfall is good when you are building structures. But value exclusively comes from the integration, verification, validation, and deployment of structures. With these types of tasks, the variance in estimates exceeds the mean of those estimates. Effective workers constantly probe different pathways to success and this makes your project network, with its delineated stages and strict dependencies, totally divorced from reality. The outcome of knowledge work, is knowledge. Not story points allocated, not dollars spent, not time used. The best hope of having a project management approach with valid predictive power is to track knowledge earned and not EVMS metrics satisfied.
donkeyd 4y ago
> you generally do not pivot I'm just going to grab this tiny part and focus on it. I've seen Agile fail many times for this exact reason. In start-up land, one might pivot and massively change an end goal. In corporate land that's a lot less off a thing. I've worked on some big projects in government and fortune 500, all of them pretended to be Agile and all of them had predefined scopes, deadlines and budgets. In all of those projects, Agile was more of a disturbing factor than anything else. The only flexible part was the scope of work, because of renewed insights or lack of specification while planning. This always ends with teams getting pressured to make deadlines (because those are never flexible), so they cut corners and work extra long hours. I think it would be much better for these types of projects (and the sanity of devs) not to pretend to be doing Agile, but just admit they want a more Prince2 led Waterfall approach. This won't happen though, because that puts the pressure with management in stead of the dev teams.

albert_e 4y ago

Managers with half knowledge and semi sincere attitudes have tried to pull "agile means you need to be flexible" on my team. To force a scope change and brand new stories in the middle of a 2-week sprint. The same folks would not accept any explanation whatsoever on why some stories didn't make the sprint delivery -- even if the blockers were completely in their court. These buzz words just become intimidation tools at times. A junior team member cannot say it to their face that Agile doesnt mean what they think it means and should learn things before they speak.

lightbendover 4y ago
Back when I was a software manager, I had to sequence work into sprints or everyone (up and down) would freak out. The part I relaxed the team on: I didn't care at all if work spilled over into the next sprint. This alone removed the stress of adding mid-sprint activities (which obviously needs to be done from time to time for at minimum reactionary purposes) and allowed more thoughtful medium-term analysis and execution. I was still on-time for delivery (at least above par on delivery timelines compared to sister teams), but with much less burn-out and generally more favorable ratings and well-constructed systems. The thought that any meaningful work (including components of meaningful work) would naturally fall within a 2 week period of time has always baffled me. That said, I have always been very good at identifying critical paths, minimal requirements, and estimated effort; I'm not sure if this strategy would work well without sufficient planning.
- grugagag 4y ago
  > The thought that any meaningful work (including components of meaningful work) would naturally fall within a 2 week period of time has always baffled me. Sprint duraration is supposed to be flexible and adjusted to each project type and yet everywhere I’ve been workint at it’s always 2 weeks

AnimalMuppet 4y ago

An amazing comment about the difference between agile and waterfall: https://news.ycombinator.com/item?id=29458652 https://news.ycombinator.com/item?id=29458652 Still the best comment I've seen on the topic.

knob 4y ago
Thanks for sharing. Loved it.

snarf21 4y ago

In my many years of software, I've come to the following conclusion: The "worst" process followed consistently across all levels of a company will always outperform the "best" process followed haphazardly with no real buy-in. The reason agile fails at so many companies is that Product and Leadership don't want to do the hard work of keeping an up to date rank ordered list of groomed and deconstructed work that provides the greatest value to the business. Agile is about progress and learning and using that new information to decide what to do next. At my current company we are using SAFe, where you plan 3 months of work at a time which is the complete opposite of being agile. Again, it asks the wrong questions. It asks "What are we committing to during this PI?" instead of "What is the most important and business value adding tasks we should be working on?" Leadership only wants the answer to when it will be done but that is up to them. It will get done as soon as they make it the highest priority thing.

nradov 4y ago
SAFe doesn't require planning in 3-month program increments. The methodology is flexible and allows much shorter planning horizons when appropriate such as when the team is small and requirements are in rapid flux. I think everyone understands that running long program increments isn't ideal from an agile development perspective. However, sometimes it is the least bad option for the enterprise as a whole. There are often a variety of program stakeholders outside the core team who can provide valuable input but aren't always available. It's a lot more practical to pull in everyone for two days of focused PI planning than to try to chase them down and schedule meetings on demand.