I have had the pleasure of talking to some very successful people over the past week. One has run over two hundred projects successfully in his capacity as a BA, and the other gives talks globally on the merits of the Agile philosophy. The Agile Manifesto is the definition of the tenets of the Agile philosophy and is stated simply at http://www.agilemanifesto.org/. Here I speak of Agile only in the context of software development; at reinteractive we run all software projects using the Agile philosophy. It came as quite a surprise to hear from my BA friend that some Agile projects failed and were four times more costly than waterfall projects. The Agile spokesperson gave me a few pointers as to why some Agile projects don’t work out.
The Product Owners are Terrible
If the project’s Product Owner is not able to make decisions on the fly (or makes bad decisions) this can adversely affect the project’s timeline. For example, if the Product Owner says “yes” to a feature and weeks later change their mind to a new feature, the developers will spend time undoing the work that they had already done (or stashing it for later in its half-done form), figuring out the new requirements and starting on the new feature. This is called “switching contexts” by developers, and can take up day or weeks of time over the course of a project.
Also, if the Product Owner does not verify that delivered features are complete in a timely manner then the developer will need to drop whatever they have moved on to and switch back to that feature.
Scrum Masters as Managers (not facilitators)
Scrum Masters are not often skilled developers but fall into the trap of trying to manage workflow by directives. A Scrum Master is primarily an expert in the Scrum methodology and so only has expertise in facilitating the flow of ideas in a Scrum session. There is a lot of value in bringing insights out of experts in the business and technical domains and this is what really maximises the value of the Scrum Master.
Workers are Under-skilled
Having developers that don’t know what they are doing slows the project down. This is true for both the planning and execution phases. Developers who don’t have high experience of complex software architecture may lead the team down a rabbit hole which could stretch the timeline out significantly.
Teams are Too Small or Large
Although neither Scrum nor Agile state any ideal team size, there have been many psychological studies conducted that suggest a team size of 3-9 promotes idea sharing and limits excessive “death by committee”. Some projects need a lot of manpower to achieve, but the work should be broken down into teams of 3-9 people if Agile methods are going to work for the project.
Conclusion
If your Agile projects are still failing after applying all of these guidelines then please let me know. Agile has been working for reinteractive for five years, and I’m keen to clear the name of Agile so more software projects can be successful and enjoyable. Having an excellent Product Owner is probably the single biggest cause for success or failure and I hope to write more about what makes an excellent Product Owner in future blog posts. Following the Agile Manifesto is important, but I hope you will be able to avoid any Agile project of yours failing in the future by understanding how teams building software in the name of Agile fails in the wild.
