With 65 percent of projects adopting Agile practices failing to be delivered on time
They’re not “failing to deliver”, they’re being Agile in disappointing everyone involved!
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
Which shouldn’t surprise anyone, but I know some managers, directors and users loathe the idea of the people who’ll do the actual job having any say other than “yes, sir”.
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
Good documentation is critical and process-agnostic. If people can read and understand it, it’s good. It’s something that can be used as a shield and weapon against users/higher ups who want too much, it can create a trail of responsibility.
Someone would look at our process and say “that’s not agile!” and they might be correct, technically speaking. I don’t personally care what it’s called as long as it works.
We agree to requirements up front with our customer; we might change stuff as we go along if our customer realizes that what they asked for won’t work (this happens occasionally), which is fine, but otherwise we don’t let them change stuff around on a whim, and we don’t allow scope creep. If they want a new feature, that’s version 2 (or 3, or 4).
We don’t meet very frequently. We do check in to make sure we’re on target, and deliver features incrementally when it makes sense to do so. We do sprints. We talk about when things are working and when they aren’t, but only when we think it’s a good time to do so.
At the end of the day, you need to tailor the process to your needs and what makes sense to you and your team.
I liked agile as it was practiced in the “Extreme Programming” days.
-
Rather than attempt to design the perfect system from the get-go, you accept that software architecture is a living, moving target that needs to evolve as your understanding of the problem evolves.
-
Rather than stare down a mountain of ill-defined work, you have neat little user stories that can be completed in a few days at most and you just move around some Kanban cards instead of feeding a soul-sucking bureaucratic ticketing, time tracking and monitoring system.
-
Rather than sweat and enter crunch mode for deadlines, the project owners see how many user stories (or story points or perfect hours) the team completes per week and can use a velocity graph / burndown chart to estimate when all work will be completed.
.
But it’s just a corporate buzzword now. “We’re agile” often enough means “we have no plan, take no responsibility and expect the team to wing it somehow” or “we cargo cult a few agile ideas that feel good to management, like endless meetings with infinite course changes where everyone gives feel-good responses to the managers.”
Having a goal, a specification, a release plan, a vision and someone who is responsible and approachable (the “project owner”) are all part of the agile manifesto, not something it tries to do away with. I would be sad if agile faces the same fate as the waterfall model back in its time and even sadder if we return to the time-tracking-ticket-system-with-Gantt-chart hell as the default.
Maybe we need a new term or an “agility index” to separate the cases of “incompetent manager uses buzzword to cover up messy planning” from the cases of “project owner with a clearly defined goal creates a low-bureaucracy work environment for his team.” :)
-
The project manager’s revenge: the last Scrum Master.
Normal development: measure twice, cut once. Agile development: measure once, cut twice.
Shockedpikachu.jpg when things fall apart.
Ha, “fail faster” indeed
Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it’s a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I’ve been exposed to. No days or weeks of design meetings, just “hey we want this feature” and it’s in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
I’m not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
Again, not sure how shipping with bugs is an agile issue. My understanding of “fail fast” is “try out individual features to quickly see if they work instead of including them in a large update”, not “release features as fast as possible even if they’re poorly tested and full of bugs.” Our team got itself into a “quality crisis” while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.
The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book “Impact Engineering,” conveniently available on Engprax’s site. Not to say this necessarily invalidates the study, or that agile hasn’t had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he’s no hack when it comes to engineering.
I could be wrong, but from what I’ve experienced,
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
is not always the norm. I’ve worked in agile environments where we had to work fast because the large corporate stakeholder had such a rapid turnaround that discussing and addressing problems meant slowing the process down, so no one wanted to be the one to say anything.
Agile feels like one of those things that works well on paper and when practiced properly, but when you get the wrong type of stakeholders involved, their lack of understanding rushes everything and makes the process and the final product bad for everyone.
I definitely agree, but that’s true of any system. The particulars of the pitfalls may vary, but a good system can’t overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don’t always know what will be complex and what will be trivial, so they accept the effort we assign to items.
Remember that it is frightingly easy to lie with statistics. This is just a correlation. Smaller companies (whom may have less experience, worse less-paid engineers) may prefer agile due to the amount of up-front effort for things like waterfall.
Agile is LinkedIn religious bollocks. Might as well just pray. Bunch of corporate nonsense.
BUt YoUrE NoT DoINg it RIghT!!1!
Should be reciting the creed in Latin, presumably.
Every time I see a discussion of agile, there are plenty of comments about how mentally exhausting and useless/wasteful the meetings are. And the defenders can only say, “you’re doing meetings wrong!” Maybe if everyone is doing it wrong the process itself is fundamentally flawed and lends itself to misinterpretation.
There aren’t any meetings that are part of Agile. The point of Agile is that you’re supposed to let teams self-organize and define their own process through iteration but managers hate that so they issue a top-down mandate to implement the Scrum process without allowing anyone outside of management to change it in any way and call it “Agile”.
Maybe if everyone is doing it wrong the process itself is fundamentally flawed and lends itself to misinterpretation.
Like Communism.
Just like saying AI will solve all your problems even if you misuse. It’s just like a pattern big companies use to mask when they’re talking out of their asses.
Is it really that unlikely that companies that jumped into the agile hype train do it wrong?
I’ve been in agile projects that worked really well and didn’t have soul-sucking, time-wasting meetings. It can be done well, it just isn’t most of the time.
Same, I’ve been on agile projects with quick efficient meetings most of the time. But I’m a project now with a 45 minute standup every morning for like 15 people. The lead just lets people ramble on and try to solve issues in standup. Backlog grooming and sprint plannings get equally sidetracked as well.
One common thread between these projects was that we used actual, physical note cards to track things. They were also logged in Jira, but the standups were 5-10 people actually standing in a room tracking burn down and status with cards taped to a wall. Nobody wants to be standing for more than 15 minutes, and anything that needed a sidebar was handled with a smaller group in another impromptu meeting.
I agree, in my experience in person stand-ups are much better than online.
- People don’t want to sand around and want to get back to their desk.
- Parking lot discussions can just be handled in the hall outside the meeting room 90% of the time and don’t require adding a new meeting to a calendar, although if there is only one issue that needs further discussion we just usually let everyone else drop call and handle it then.
Similar, except we only budget for half an hour so as it drags on past the first or sometimes even second hour it takes over lunchtime.
Even when people avoid trying to say anything so as not to drag it out, the mere fact that the meeting is happening means that it will manage to take up the whole block of time and then some.
Ironically I’m starting to wonder if the solution might be MORE rather than fewer meetings, bc people need SOME time to work it all out, so if there were other more focused ones then all that could go there rather than have to take place in the only meeting it can - where it takes up the time of the entire team.
Well, you’re supposed to refer to them as “rituals”. “Meetings” are so waterfall. No wonder it isn’t working.
I prefer séance
Maybe if we mix in another metaphor, Agile will work.
Great idea! Let’s huddle with the Coach at the retrospective.
It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.
It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.
In the days before Agile the Waterfall projects failed too. Though not necessarily for being late, they failed because they didn’t deliver the thing that the business thought they were building, they delivered something else due to a misunderstanding. If nothing more, Agile gives more visibility into the process and allows for course correction.
Right off the bat i read
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation.”
You need clearly defined requirements to write a good user story. Documentation comes after.
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. “We don’t need a test team because we’re Agile” is a cost-saving abdication of responsibility.
Precisely, once once have i worked in a company where agile was properly implemented and, yes, user stories were well documented and discussed before being developed. All others are just waterfall in disguise, or Fragile™.
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. “We don’t need a test team because we’re Agile” is a cost-saving abdication of responsibility.
You need clearly defined requirements to write a good user story.
This is the main reason the last company I worked for lacked in project delivery. They had just transitioned to Agile, and their whole teams lacked proper Agile experience and the training provided was very superficial. They barely put any time in refining the requirements and this trickled down to developers.
Projects that allow for clear requirements before really starting on them are clearly more likely to succeed than ones that have a higher complexity due to unknowns.
Agile went through the mgmt human centipede and now it’s an unrecognizable broken system built on conflated ideas. I bet a good number of those projects are ‘agilefall’ anyways.
We prefer the term “wagile”.
I liked frAGILE
I’ve literally never actually seen a self proclaimed “agile” company at all get agile right.
If your developers are on teams that are tied to and own specific projects, that’s not agile.
If you involve the clients in the scrum meeting, that’s not agile.
If your devs aren’t often opening PRs on a variety of different projects all over the place, you very likely aren’t agile.
If your devs can’t open up a PR in git as the way to perform devops, you aren’t agile.
Instead you have most of the time devs rotting away on the sane project forever and everyone on “teams” siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because “they worked on it so they knpw how it works”
Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.
Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.
Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.
A really helpful metric, to be honest, of agile “health” at your company is monitor how many distinct repos devs are opening PRs into per year on average.
A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.
I don’t disagree with you (on giving devs some creative freedom), but “Agile” as a process methodology isn’t about developers working on multiple things to keep their interests up.
That’s actually a pretty important part of its original premise.
It’s a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what’s up, if they like.
Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.
The whole point of the process was to address 2 things:
-
That client requirements can’t easily be 100% covered day one (But you still need to get as many as you can!)
-
To avoid silo’ing and tying devs down to specific things, and running into the one bus rule (“how fucked would this project be if <dev> got hit by a bus?”)
And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they’re familiar with a challenge, etc.
One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.
An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.
If your company doesn’t even have a “ask for help on (common topic)” channel for peeps to imfoshare, you are soooooooo far away from being agile yet.
I don’t know man. Nothing in the Agile Manifesto talks about not focusing on one project.
In addition, I think most people (and studies) would agree that “focus” is key to building almost anything of quality. Not flittering about working on shiny pennies of the day. I mean, a key tenant of sprints is “Don’t interrupt the sprint”. The whole concept is about letting developers focus.
Agree to disagree I guess.
Might wanna read it again, it’s right there :)
The best architectures, requirements, and designs emerge from self-organizing teams.
It’s an incredibly critical part companies love to completely ignore.
If you assign devs to teams and lock em down, you’ve violated a core principle
And it’s a key role in being able to achieve these two:
Agile processes promote sustainable development.
And
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is talked about at length by the likes of Fowler, who talk about how locking devs down us a super fast way to kill sustainable development. It burns devs out fast as hell.
Note that it’s careful not to say on the same project
-
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates. ®
Random trademark symbol. What’s the registered trademark here? The dot? “advocates”?
Its just the symbol The Register uses at the end of an article. Like how some papers use a filled in square.
Lol I’m going to send this to my project manager
According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase.
Is this not self-evident to most teams? Of course you will not reach your destination if you don’t know where you’re going.
On the other hand you can just call wherever you end up the destination, and no one can prove you wrong. 100% success rate.
Congratulations you’ve just been promoted to product manager
On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development. Often claiming that we can’t know the requirements up-front, because we’re agile.
On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.
I don’t think this is an Agile thing, at all. I mean, look at what Agile’s main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.
How did they know how to break things down into tasks? How did they know if a task would fit in a sprint? 😄
We’re so agile the sprint became a time-block framework rather than a lock-down of tickets that we certainly will finish. (In part because stuff comes up within sprint.)
For your sake, I hope your employment was agile as well. Those jobs sound like they were dumpster fires waiting to happen.
Also seems like a shitty get-outta-jail-free card. With no design in place, timelines and acceptance criteria can’t be enforced. “Of course we’re done now, we just decided that we’re done!”
That’s boneheaded.
