Why organizations fail in using Agile/Scrum practices – missing the forest for the trees
Virtually every time I start talking with customers about Agile practices, the hemming and hawing begins. “Well, we’re working our way toward Agile, but we’re not there yet.” People make up hysterical terms like “Scrumfall” or “Wagile” to describe their approach, which often devolves quickly into something like “we do our work 2 weeks at a time” or “we have a standup meeting every day”, except no one is standing, the teams are reporting out to a manager, and the meetings take an hour instead of 15 minutes, with half the team checking their phones as the meeting drags on.
This is something we see all the time in ineffective adoptions of other best practices, like ITIL, DevOps, risk management, project management, and many other disciplines. It’s a deep lack of WHY: WHY are we doing this? What are we actually trying to win by “going Agile,” other than joining the buzzword of the month club?
Agile exists for a few basic reasons
1) People learn – as we work together with stakeholders to solve problems, everyone at the table gets smarter, and it creates opportunities
2) Stuff happens – In a typical 6-month project, 60% (!) of the requirements will change. This happens for any number of reasons; changes in legal and regulatory requirements, competitive threats, customer expectations, new technologies, security risks, and many other issues. The idea of “complete requirements” or a “total solution” is FICTION. We need to disavow everyone of this mirage…the magic 100% solution doesn’t exist.
3) It’s not about the project, but the service – Projects end; by definition. Thinking about a service as being “maintained” is actually the wrong way to think about it. It’s not maintenance at all, but new capabilities, changed business needs. The only constant will be the need for changes; hundreds and thousands of them over time. Whatever service you go live with is just table stakes for the thousands of changes you will make. We need to stop funding PROJECTS and start funding SERVICES across their lifecycle. Over a service’s life, the total cost of ownership of a service is often 3X of the project. Customers need to understand this and fund and staff accordingly. This means
4) We need intact teams – with the ability to create and modify services over the long run; notice I did not say maintain them, but much more than that: modify them and realign them to meet the constant changes in business need. The evidence is in on this one: intact teams can be up to 3 TIMES more proficient at delivering capabilities. Quite bluntly, any other model GUARANTEES that your competitors will beat you to market.
If your teams think Agile means meetings, sprints, and user stories, that’s a good start, but it’s only a start. Stop focusing on the trees (what stuff do we do in this framework?) and raise your game to think about the forest (WHY will Agile practices help us be competitive and help us transition to a services model).