Customer-driven Agile software development
Written by Timo Hoogendorp – ICT lead
Why we chose this route?
Pretty early in the creation of my current team, it was obvious we have a group of people with a pretty wide selection of skillsets that could all contribute to a variety of projects on our roadmap. It was very hard to get external and internal stakeholders to agree on urgency vs. priority and timelines. Then there was the additional complexity of external deadlines and revenue. If a customer is paying, or even has paid, for something to be developed and there is a timeline, does this mean it automatically takes priority over other things that SHOULD be taking precedent? Furthermore, is the decision with the technical team, or with someone else?
Some of these projects were big/long-term projects that would mean these scarce resources would be locked into this project for up to a year. Impact for the timeline for other projects would be significant, and as a result these bigger projects were typically assigned a lower priority by the stakeholders of the operational teams. As an inevitable result, we would also see quick-win and short-term projects being picked up over more fundamental redesign projects or more ambitious new market projects.
Another observation we made, is that the requirements and specifications of projects would sometimes change as development went on. The typical project initiation document and the requirements it contained were always wanting in details. Sometimes, as we were iterating, it felt like the requester themselves weren’t really aware of what they wanted until we started ‘improving’ our initial deliverable.
The tangible product that was developed so far would often inspire or alert the requesters or stakeholders of what exactly we were doing and introduce certain must-haves for adoption in our operational organization, or even objections to the project entirely as it would conflict with other internal projects or processes. It would also lead to additional feature requests that ‘had’ to be part of the project. Requests which, in hindsight, should’ve been part of another project picked up in a different sprint. A typical example of unnecessary scope inflation, despite the best intentions of my colleagues.
This disconnect between the technical team and the requester, and the lack of guidance, and a pretty long feedback loop left some room for improvement. We wasted resources building things that would have to be completely rebuilt, didn’t fulfill the user’s need, or were not what the user requested or needed. Furthermore, this disconnect led to a pretty time intensive user adoption process. Typically, when the project was ‘done’, user adoption would mean some sessions to explain how the product works, where specific high-priority features and processes could be found and a nice list from the trainees/users of ‘should have and could have’ functionalities that we should ‘definitely pick up in the next sprint’. The product already felt outdated and a subject to improvement when the user started using it.