Why Agile Fails
The Agile Kool-aid …
Working Agile is liberating. Unlike waterfall, where the engineers are ‘done to’ and the business and product owners are disappointed, working in agile teams gives control back to the engineers. The team is unshackled to deliver amazing things which are loved by the business and customers alike. The team focuses on the important, they understand the value of what they deliver, they can change direction on a dime, continuously deploying a highly reliable and predictable train of features that makes RoI calculations simple. Agile is just THE BEST!
Well, that is the agile flavour, but …
In real life, things aren’t that easy nor successful. Taking people who are used to working at the end of a production line delivering strictly technical work, and telling them they are liberated and can do what they want rarely ends up in success. Even when engineers are in a team with a Product Owner, a Business Analyst and an Agile Team Coach, when they have a supportive management, when the company isn’t pushing waterfall ways of working, even with all these positive things, more often than not things go pear-shaped pretty quickly. The two big symptoms of this fruit-silhouette are poorly structured, confusing backlogs and a lack of delivery even though everyone is working furiously. Why is this?
It’s all about the story breakdown!
Yes! That’s right! The secret is in the way we break down the work. How do we even hope to be mildly successful if we don’t have a clear idea of what we want to deliver? And when I say deliver, I mean an outcome to our customer that is valuable to the company in which we all can feel proud.
Everything starts with understanding what it is we are delivering as outcomes to the user and the company, and using a strong systematic method to map the outcomes onto small sets of technical changes. This is a skill-set many of us have never had to learn because waterfall doesn’t encourage such behaviour, and our education systems don’t think to teach it. The silos that we fall into; Product Owner, Business Analyst, Engineer, Agile Coach, each moves us away from across the outcome thinking. Product Owners don’t get into detail of the outcome, so make gross assumptions; Engineers don’t think about user so just deliver technology, and so on. The truth is that it is all and none of our faults. Without the basic tooling, breaking down stories becomes a haphazard series of things that confuse everyone and their dogs.
What does failure look like?
We love to ask ‘what does success look like’, but do we know what failure looks like? To help put this into some familiar terms, let’s imagine how development normally plays out in thousands of companies across the world today. It starts with a project decided upon by the higher ups. They see a problem, in our case, a lack of leads being turned into sales. As a result, the sales team have told the Product Owner that the company needs to improve phone number capture of prospects on their website. The Product Owner has decided that this is best done by enhancing the existing web page with a text box and a submit button. A scorecard is filled out, the project manager says okay and so the Product Owner goes to the team and tells them what needs to be written. To help things, the Product Owner has a wire-frame sketch or two. At the end the Product Owner asks for an estimate so it can be reported back to the Project Manager.
Depending on the pessimism of the team, the Product Owner gets estimates ranging from a couple of days (“it’s just a text box!”) to two complete sprints. The team agrees to add it to the backlog as part of the ‘prospect improvement’ epic which has been running or three months already. The team adds a number of stories such as ‘extend the lead capture web page’, ‘add email validation’, ‘as a programme calling an API, I want to store an email in the CRM’, and so on.
A month later the team starts working on the first story. At this point no one has any idea of what needs to be developed, the overall value of the feature, if it will work, the complexity or how to measure success. The team do not know when this functionality will be available. As the engineers started to write, they uncover issues, have questions, make false assumptions. Each stops development, causes confusion and delays delivery. Eventually something gets out, but no one is able to actually measure the improvement. Has the work improved lead capture, who knows?
This is a simple example, and already we can see how ‘agile fails’. The team thinks they are working in an agile fashion. They have a backlog, they prioritise, they work on stories. The Product Owner thinks they are owning the backlog. However, the finance department has no idea of the return on investment for the £75K spent on the team in that period, and as none of phone numbers captured from the web page have been integrated into the prospect management tool, the sales folk don’t feel that they are getting any help from the technology department.
No one is happy — click here to find out how to improve things >>>>
