Note that this is failure to deliver on time, not failure to deliver full stop.
I also think a lot of places claim to be agile, but don’t follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what’s in the agile manifesto and claim that it’s a representation of what it says.
Maybe that’s a fundamental problem with agile. It’s just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it’s just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.
For anyone that wants to refresh their memory on the agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile was designed for contractors to deliver contract work. It’s a terrible design for any sort of sustainable business plan, hence “working software over comprehensive documentation”. That line right there causes the majority of outages you as a consumer encounter.
The very first mistake most people make when reading the agile manifesto is that “a over b” means “don’t do b”.
100% that.
Especially that working software over comprehensive documentation part, which can be automated so easily if done right.
There’s so much value in TDD and providing a way to do integration and automated UI tests early on in a project, yet none of the companies I’ve worked at made use of it.
Also automated documentation tools like Swagger are almost criminally underutilised.
Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
- Hack together a proof of concept
- Works well enough that management slaps a “done” sticker on it
- Pile of hacks becomes load bearing
- One or two dependencies change, the whole thing falls over
- Set evenings and weekends on fire to fix it
- Management brags about moving fast and breaking things, engineers quit and become cabbage farmers and woodworkers
- New graduates are hired, GOTO 1
If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work
Or create a better UI that doesn’t require so much documentation.
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Gotta remember it was a response to water fall. Docs didn’t mean the man page or the wiki, they ment the spec sheet, PowerPoint’s, graphs, white papers, diagrams, aggreements and contracts, etc. Where you might go MOUNTHS making paperwork before you ran a single line of logic.
Docs SHOULD be the last resort of an engineer if your UX just can’t be intuitive in some way or some problem domain just can’t be simple. You should first strive to make it work well.
For example Lemmy, it just would work if you needed to read the Lemmy user guide first to post on Lemmy. That would indicate bad UX, but that was how it was back in the day.
It wasn’t, Waterfall in itself was a contrived example of a bad setup. More common was UP, or something UP-like.
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
It sucks for any large group that requires a lot of coordination. Some parts of it are still helpful as part of a blended process, like more collaboration with the customer and responding to change, but those can easily derail a project if not everyone is on the same page through scope creep or losing sight of long term goals.
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
I think you got it entirely backwards.
The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.
The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.
I wonder why anyone would downvote you. to break down what you said:
The primary problem is using agile all the time instead of when it is actually intended to be used
this applies to everything in life. zero reason to downvote this unless you’re a zealot who doesn’t understand nuance
short term work that needs to be done quickly by a small team that are all on the same page already.
the whole point of agile is to be short term, maybe your downvoter thinks that the team doesn’t need to be on the same page??? don’t know how that is in any way a good idea. it means you haven’t done a good job communicating…
Some parts of it are still helpful as part of a blended process, like more collaboration with the customer and responding to change, but those can easily derail a project if not everyone is on the same page through scope creep or losing sight of long term goals.
anyone that disagrees with this hasn’t actually gone through with Agile according to all the tenets. It sucks for anything more than the tiniest projects that don’t need long term maintainability. I’m guessing this is where someone disagrees, but I can’t fathom why. Maybe they’ve only worked at one place, they think it actually is working, yet haven’t been there long enough to see the downsides or something.
There is nothing in the agile tenets about only using it for short term projects. I’ve had very successful multi-year agile projects.
Frankly “agile” just goes over most people’s heads. They think it means sprints and stand-ups with no documentation.
the whole point of agile is to be short term
Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.
This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.
Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.
I don’t understand what you mean, why would coordinating across a large group be against the agile principles? It sounds like the main issue here is lack of communication and planning which are both important parts of any process including one based on agile.
Planning becomes more important for a larger project but if you hyper focus on sticking to the plan even if things change you can end up delivering something that is not useful for your customers, so I think the principles still make sense there.
Note that this is failure to deliver on time, not failure to deliver full stop.
It’s also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It’s easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.
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.”
Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.
The study’s sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don’t adopt agile if you were already successfully delivering projects.
Yes, and daily standups are not a requirement of agile in any way. The whole point is people over process and adapting to change rather than following a plan so if standups aren’t working you should stop doing them rather than following a rigid process!
💯
Agile is not an excuse to be stupid. If you need documentation then fucking do documentation. If your stand-ups suck then either change them or stop. You don’t just do things “because agile”.
I was going to say most of this, too. I’m a big adherent of BDD, which works well with agile. It clarifies what everyone is working on without getting weighed down in unnecessary minutiae or “documentation for paperworks sake”… it lives and evolves with the project, and at the end becomes both testing criteria and the measurement of success.
Requirements ≠ Documentation.
They are part of documentation, but not all documentation.
The difference is in exact wording Agile: the software shall properly authticate a user within our active directory.
Documention : user authentication will be provided by functions ”valisate username” as described in section 14,7 subsection 4, ”validate password” as described in section 16.2 and validate the correct pasword as described in section 23.4.Proper authication to the correct use group shall comply with the requirements in document 654689 section 64.7 subsection 17
Yes there is a difference and one is better…
So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.
The details on HOW to authenticate are ALSO documentation. Not all documentation describes functionality.
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.
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 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.
For your sake, I hope your employment was agile as well. Those jobs sound like they were dumpster fires waiting to happen.
How did they know how to break things down into tasks? How did they know if a task would fit in a sprint? 😄
On the other hand you can just call wherever you end up the destination, and no one can prove you wrong. 100% success rate.
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.
