With the application of agile delivery methodologies to technology programmes of ever-growing complexity, it becomes increasingly difficult to answer the simple question “are we on track?”. As our enforced experiment in remote working moves from being a short interlude to the new normal for systems delivery, it becomes harder to maintain the creative collaboration that helps keep sight not just of your own piece of the jigsaw but the full picture.
So while virtual post-its are marching across your Kan Ban board, fires are regularly being put out as you work through the burndown list and velocity is increasing with each new sprint, can you really be confident that your agility is taking you in the right direction?
We’ve been using an Engineering Maturity Model to help maintain coherence as we work through discovery and into delivery across a range of projects. It helps us take a step back at the outset by reviewing nine key aspects of delivery.
While the breadth may seem surprising for the Engineering team to wish to model, this holistic approach ensures that our effort is focused on the right activities – at the right time. We consider all aspects of the delivery and have identified a set of maturity states to describe each, starting at the very beginning with the identification of the opportunity, through into solution definition, delivery and realisation of benefits.
With each aspect of the programme will mature at a different rate, this is by no means a sequential process and modelling all aspects in parallel and understanding the interdependencies can help us rapidly identify where delivery may be going off track. Aligned with each maturity state, we have identified a set of core artefacts that should be in place before the delivery could be expected to move onto the next level of maturity.
Any red flags around the completeness of a key artefact set can highlight a risk if delivery progresses any further. Similarly, we can identify any mismatches between different aspects that could raise cause for concern. For instance, in a situation where you have only reached Maturity State 2 (Bounded) for capture of requirements, can you be confident that Functional Analysis has reached Maturity State 3 (Coherent)?
While the level of complexity and interdependency between each aspect will vary from one delivery to another, most deliveries that we work on encompass all aspects. Rather than mandating the list of artefacts to be produced against each aspect of delivery, we have put together a menu and on project mobilisation would look to agree the baseline artefacts for each, and at what point in maturity each is required. This helps us identify interdependencies across different aspects and where different teams are required to reconnect with each other, rather than pursuing their own burndown list. Once the model parameters are agreed, maintaining it and using it to keep delivery on track becomes established as one of the agreed ways of working across all teams.
Applying agile delivery techniques to large scale multi supplier programmes of work brings its own challenges. While the end goal is clear, planning the next increment across multiple teams needs a good understanding of how to keep in step without constraining each supplier’s velocity. The Engineering Maturity Model has helped us with setting proximate goals – by enabling a better understanding of the interdependencies between each aspect of delivery and whether each is on track.
As Systems Engineers, we can face the accusation that we lose interest once delivery work is underway – with architectural modelling and design completed, what’s left is the far less interesting task of just building the thing. By including aspects such as Team, Ways of Working and Work (the messy business of what gets done when by whom) in the model, we can apply engineering rigour to all aspects of delivery. In the past (way back in February) we expected teams to form themselves organically with many day-to-day opportunities for spontaneous collaboration and course correction. Without that natural social element in our work, there is a need for far greater clarity in what is expected of individuals and teams and the Engineering Maturity Model provides a mechanism to set out what that is – and track progress towards it.
That brings us back to our original question – are we on track? We’ve used the Engineering Maturity Model concept across a range of deliveries and it’s become an essential tool within Principle One for ensuring we are focused on the right tasks at the right time. It can very rapidly show where disconnects exist between different aspects of delivery, basing the assessment on “facts not opinions”; if the answer is that the project is not on track, the Engineering Maturity Model helps us course correct earlier, more quickly and at lower cost.