“Death caps have been reported to taste pleasant. This, coupled with the delay in the appearance of symptoms—during which time internal organs are being severely, sometimes irreparably, damaged—makes it particularly dangerous.”
The development team is following an agile methodology of choice, everything appears to be going smoothly, all ceremonies and activities are being followed. Early symptoms include the warm glow of satisfaction that agile appears to be working. Signs that something may not quite be right only appear close to or after delivery when end users fail to use or adopt a feature or product. In severe cases those affected may never notice that something is wrong. In the end the product fails to meet any of its intended objectives and silently dies leaving behind a redundant codebase and a missed opportunity.
The end result of Agile Death Cap similar to the Death March commonly attributed to Waterfall projects, the difference being that no-one is aware they are affected until it is too late.
What’s gone wrong?
The development team are successfully implementing agile principles but only within the reach of their team and immediate stakeholders. In their desire to be agile and their frustration that no-one else seems interested, development team will often take the lead in writing user stories. They will feed off pieces of information during ‘story writing’ sessions with business representatives and fill in the gaps to keep things moving. The stakeholders may be delighted at first as it is one less thing for them to worry about and on the face of it things are working well. They ‘trust’ the development team to get it right and end up accepting the development teams assumptions without verification. Everyone is happy, prioritised stories are being delivered on time that meet the story’s acceptance criteria, the team finally get their wish in being agile. Sadly, the project is doomed for failure.
Who can it affect?
Any software development team, particularly susceptible are early agile adopters where change is being driven from the development team out.
Be sure to identify all the people who care about your product up front. Create a shared understanding of the problem being solved and all expected outcomes. Understand how you will validate the assumptions and decisions you make throughout the project.
As always feedback is key, however far too often validation and feedback only goes as far as a tester or the project owner.
A Case of the Agile Death Cap
Mike, the managing director of a company offering inventory tracking software to large construction companies, is a busy man. His primary goal is to grow the business by increasing sales. During a series of conversations with some key customers he identifies an opportunity to offer additional services that he believes will help his quest.
Previous software development attempts have been far from successful. Simon, the development team lead believes an agile approach will help and discusses his plans to adopt Scrum with the organisation. Everyone is more than happy to try it out given past software development failures. The current Project Manager, Paul, becomes the Product Owner. Simon the Scrum Master. Everything is set.
Day 1: Requirements gathering Story writing
Simon, Paul and Mike are gathered in a meeting room. Mike explains his idea to the others.
“So I’ve been speaking to a few of our top customers recently. They keep saying how they want a contract management system and they are prepared to pay for it. If we can add this into our core product they will be blown away”
Paul and Simon write down user stories on some index cards. The contract management system will capture basic details of customer contract. It will allow users to enter rates for labour, consumables and equipment. They even get their hands on a real paper contract so they can be sure they can reproduce it. Finally Mike picks the stories that describe the Minimum Viable Product.
Day 2: Estimation
Simon and the development team get together to estimate the stories from the previous day. Estimation turns out to be harder than they first thought. How can they estimate these stories, they don’t have enough detail? The team spend several hours debating the scope of each story. In order to move forward they finally agree to write down some of their assumptions against each story before assigning points.
Later Simon discusses these assumptions with Mike and Paul, they highlight a few minor issues but are on the whole very happy that the development team seem to on top of things. Mike leaves the discussion a happy man, this agile process is making his life so much easier.
Day 3: Sprint Planning
A number of stories are pulled into the sprint and work begins.
Day 4 – 17: Development
The team work tirelessly on the stories. Paul is kept up to date with progress during stand up meetings. A few questions come up during the sprint which Paul is is happy to answer based on his understanding and judgement. Everything is going well, the burn down chart is pointing in the right direction, the team is nailing it.
Day 18: Sprint Review
As predicted the development team have managed to get all their stories completed. The CI server is green, the automated deployments have worked perfectly. The tester is happy that all stories meet their ‘conditions of acceptance’. The team proudly demonstrate the results of their efforts. Mike is delighted.
Several sprints later…
All project objectives have been met, user guides have been written and the new feature is deployed to production. News of the success story spreads, beers are opened, the new agile process is declared a huge success.
Several weeks later….
Simon catches up with Mike in the kitchen and asks how the the contract management feature went down? Mike explains that he gave a demo to a few customers but oddly they weren’t so keen when they saw it. It probably just needs a bit of tweaking but that will can wait, he has a great new idea which is now a top priority.
Only later did it become apparent that the customer didn’t really want a contract management system at all, but simply a means to effectively bill their customers. They already had a well-known accounting system that did most of what they wanted, all they really needed was some form of integration between the two systems. An export would have sufficed. The word ‘contract’ was used by customers in early discussions and this triggered a set of assumptions that were never verified. Even when a customer was shown an early version of the feature the problem was not picked up, the customer simply assumed that the feature would be relevant to someone else.