On Wednesday 26 February, I’ll be speaking at the H1 Event in Leeds about delivery style. More specifically, about how to judge where your organisation is with delivery, where you want to be and then deciding on the most appropriate way to get there.
Something that comes up time and again during 101 Ways’ engagements and even during my coaching practice, is understanding the delivery style of an organisation. This can be helpful in terms of adapting ways of working with teams and consideration and mitigation of commercial risks.
To do this, I find it helps to visualise the delivery landscape for the clients I’m working with (Fig 1):
The stages depicted on the left will vary but can be categorised broadly in this way to demonstrate a ‘return point’ for each cycle. To the right, there are four distinct delivery styles, with differing characteristics, processes and practices for each.
Let’s break these down.
Sequential
Technically a ‘waterfall’ course of action – although that term is arguably derogatory – sequential delivery does what it says on the tin and focuses on moving through the delivery stages in one direction only (Fig 2 below):
Forming an idea, vision, or business case; ⇩ 'High level' planning, setting budgets, planning release dates; ⇩ Detailed scoping and analysis, design and technical implementation plans ⇩ Development, testing and delivery |
I’m sure we’ve all worked on sequential projects – some still operate in this way, but it’s fair to say there are fewer about these days. With it, often comes a high level of governance and the need to control things at a distance from the project teams themselves.
Even within sequential environments you still find development/delivery teams adopting ‘agile practices’. There may be stand-ups, even Sprints. There could still be continuous integration, pair programming, collaborative working etc. All of the practices adopted by the development teams however, exist within the bubble of development. They eventually hit a glass ceiling, beyond which they cannot assert influence.
Incremental
From experience, this is where the majority of organisations find their comfort zone. They’ve made the case for the product and had the budget approved and allocated. They then create a plan with delivery dates and a schedule to stay on track and on budget. Finally, the ‘Scrum bubble’ takes over to incrementally deliver on that plan.
The key difference? Rather than the detailed analysis and design happening upfront, it falls into a ‘just in time’ cadence for the Sprints, as depicted above with a loopback around detail and delivery. Whilst this will usually feel more like Scrum, there’s often little impact from the Sprints to influence the product direction or overall plan. Rarely will teams in an incremental delivery environment release into live – or even at all – at the end of each Sprint, until a defined milestone or minimum feature set has been reached.
The Sprint delivery can enable organisations and teams to understand how they are performing against the plan and budget, so in that sense, ‘agile’ is working for them. Eventually however, they will also hit that glass ceiling of influence, whether it is thinner and they choose to break through it, is another matter.
Iterative
This is the style I see most often in smaller organisations, usually where there is good, collaborative team communication and strong leadership by management. The company may have a solid vision and commercial strategy for the product, and there is likely to be defined features which are core to the product, but not necessarily a clear timescale or plan as yet.
The team(s) will jump into development as soon as they’re able, finding a cadence that works for delivery and using that information to influence the plans, priorities, budgets and timescales, but usually not the core product itself. Again, they will usually not release into ‘live’ until a minimum set of features have been developed, thereby missing feedback from the user or customer themselves. I’ve shown this at Fig 1. above as looping back to planning, but leaving the product direction alone.
Adaptive
Adaptive is somewhat of the Holy Grail, and the space that many would love to be in, but in practice, few actually are. Taking the loop all the way back to forming the product direction itself again Fig 1), means testing assumptions on the product as soon as possible, getting a true MVP, and allowing that feedback and learning to influence your product vision.
I truly believe that an adaptive delivery style can elicit the best value from a product. Having said that, it is not necessarily the right style for everyone or every organisation. Whenever I carry out assessments, I refer to this list of styles to analyse where a client organisation or delivery currently sits. It helps me understand a client’s approach to risk, their appetite for change and the characteristics of the organisation, as well as some of the individuals influencing it.
Hopefully, this post will help you appreciate the typical delivery style of the organisation you’re currently in, your own individual comfort zone and the environment you would like to be in. And with the help of these key pointers and my talk at H1, how you can effect real change to move you and your organisation forward to delivering what it should be.
Feel free to get in touch with Emma Hopkinson-Spark if you want to discuss how 101 Ways can help with assessments or to find out more about the event, contact Dan Mills