In fall 2017 we switched a client project from a classic project setting to Scrum. The project has been going for almost 10 years. During this time we’ve been managing both the development of new features as well as maintenance and support. The software that we’ve developed has become an integral component of the client’s infrastructure and we are dealing with many stakeholders, each having different requirements to the software. As the current Scrum master and previous project manager i’d like to share my experience on what impressed me most. Specifically, I’m going to examine the different approaches to answering the client’s question “When can you ship feature X?”.
Answering the question in a classic project setting In an ongoing classic project the question of “When can you ship feature X” is handled as part of the “Change Request Management”. At first sight the question seems very simple. However, coming up with the answer requires the following tasks:
In practice, when answering this question, a project manager usually goes with his gut feeling – or asks the development team to make a judgement. Nevertheless, my goal was to demonstrate that the answer to this question is not as trivial as expected and it can involve considerable amount of work – especially if the project manager needs to organize more resources and if he constantly needs to keep his overview of the current release up to date.
Finally, answering this question can be stressful. It requires a project manager that can potentially push back and occasionally “say no” to the customer in order to keep a good balance of timely delivery, quality, and costs.
Ow, let’s examine the question of “When can you ship feature X?” in Scrum. The second principle of the Agile Manifesto reads as follows: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
As this principle already implies, Scrum provides you with several tools that help you answering the question.
If circumstances change and the product owner needs to prioritize other work, the delivery date of feature X can be easily reevaluated. Whereas in a classic setting the project manager could get the blame for the delay, Scrum creates a lot of transparency and a shared responsibility between the product owner and the rest of the team to work towards a timely delivery of the new feature.
As a project manager, answering these kinds of questions took a lot of time and caused a lot of headache. Of course, switching to Scrum can have many benefits – however, in my opinion this point alone already made it worthwhile.