If you work in an Agile manner, each sprint can end with a retrospective, but the problem with that is that everyone views it through the same (team) lens. In this blog, our colleague Arjan Wiegman explains the added value of a Delivery Improvement Plan, and shares a practical example.
Why a Delivery Improvement Plan?
During a retrospective, you reflect on the work. As a team, you look at what went well and what could have been done better. In a perfect world, a Delivery Improvement Plan would thus be redundant. But this work method comes with two downsides. If you look at improvement points, you have to be able to put them into context. What are our goals and how are we doing now? First of all, there may be a difference in the goal of a team and the goal of the IT department or of the business as a whole. Furthermore, everyone in a team views things through the same (team) lens. How honest, then, is the answer to the question: how are we doing now? A Delivery Improvement Plan doesn’t have these downsides.
Center of Excellence
It can also help to instate a special Center of Excellence, to support the team and monitor the quality of the process. It is important to not be prescriptive in the actions the team has to carry out. A CoE helps the team formulate its own actions based on the previously formulated goals. That is how to bring about change in a positive way.
A Delivery Improvement Plan in practice
We are currently implementing a Delivery Improvement Plan for a client. How that works?
With a quick scan, we took a high-level inventory based on conversations. First, we identified the direction the stakeholders wanted to go in and what their objectives were. They wanted a more coherent product, more of which can be reused and which can also retain its quality on the long term.
What makes it better?
Then, we researched which improvements the various team members envisioned and which aspects they believe are going well. In that process, we saw that teams e.g. got to work on the business’s request much too quickly, without first looking at how and whether the solution fit in their IT landscape.
When the results were clear, we set up a Center of Excellence. That includes me, but also a test specialist and a Pega specialist, for example. As a team, we translated the insights into a backlog with different actions. When developing new solutions, it can help to stay focused on three aspects: Where does this solution fit in our landscape in terms of architecture? What requirements and wishes does the business have and what do those mean for the larger whole? To then finally fit the solution into the Pega landscape, technically speaking.
Creating support from the bottom up
Then, we did various workshops with the teams. That allowed us to share the set objectives and enable the teams to formulate actions with which the objectives can be met. During the workshops, we not only discovered things we didn’t know yet, but as a result, the teams also became more involved and they started to see the value of the improvements themselves.
Do you want to make improvements visible? Start with an objective quick scan. Curious to see what that enables us to do for your company? Contact us at [email protected] or call us at +31 30 – 20 77 006.