Where it started
A public authority wanted to automate a business process with 40,000 cases a month. The project was planned for two years, and the team consisted of five developers, a product owner and a Scrum Master. We joined after the first year.
How the bottleneck showed
The first year had gone entirely into technical groundwork. The development team therefore did not yet know the business domain of the project. There had not been a single piece of feedback from the business department. After a year, nobody knew whether the requirements had been understood correctly.
Where it came from
The plan had put a whole year of technology before any business work. As long as nothing business-related was built, the business department had nothing to check. So the feedback was missing for a simple reason: the workflow only planned for it at the end.
What we did
Process
We adjusted the sprints so that at least one business story was always implemented. That made it possible, for the first time, to check whether the business department’s requirements had been understood correctly. Focused on the benefit for the users, we worked iteratively and could deliver value before the end of the project.
IT
Where dependencies would otherwise have blocked development, we worked with dummy data. Development was done almost entirely in mob programming. That prevented knowledge silos and reduced the overhead from merges and code reviews.
What stays
We delivered the full project scope around 3 months before the planned end. Because the team worked on business stories from then on, it was clear before the end of the project that the business domain was mapped correctly. And because development happened in the mob, the knowledge sat with the whole team.
