When organisations and teams are looking to understand how good they are and where they should look to improve they often reach for the latest maturity model. The use of maturity models to perform assessments is also an approach adopted by consultants. Whether that’s a health check or a 4 stage stepped model there are a few problems to be aware of.
- Most, if not all, maturity models are context free. They presume to know what is universally good in order to give you a clear way of assessing your current capability and then plotting a path to perfection. But as software development is a complex (as in Complex Adaptive System) problem there is no universal perfection let alone a path to it. For example, Adrian Howard points out that maturity for a 30 person company is entirely different to that of a multinational.
- As Marc Burgauer highlights “they also bias thinking towards the model, i.e. blindfold for context”. That is most maturity models encourage “gap thinking” which involves envisioning their view of an idealised future state and closing the gap. This, in turn, discourages options that might otherwise present themselves.
- Jason Yip points out “they’re suggesting a poor learning order, usually reflecting what’s easier to what’s harder rather than you should typically learn following this path, which may start with some difficult things. In other words, the maturity model conflates level of effectiveness with learning path”.
- In some context being categorised as immature could also been seen as shaming. This then creates an extrinsic motivator for improvement but for that we want teams to be intrinsically motivated.
Trent Hone likens them to a treasure map where X marks the spot. The problem being the terrain you see around you isn’t reflected anywhere on the map. You know something great is out there, you just have no way of navigating your way towards it.
To improve what really matters is that we understand our own context, the challenges we face and our ability to adapt and learn to meet these challenges. That is, we need to focus on “present thinking”. I’d suggest that for a maturity model to provide utility it must reflect the context, and provide some guidance for improvement that can be selected dependent on that context.
When exploring this challenge it struck me that we have a way of understanding our current landscape, the climate, doctrine and context specific approaches to apply to make movement within the environment towards a desired state. Simon Wardley’s mapping gives us all of these things but in the context of strategy. What would happen if we turned it towards team or organisational maturity, what would that look like?
Note: If you’re not familiar with Wardley Maps please watch this before reading on as the rest of this posts assumes a familiarity with Wardley Mapping.
When describing Wardley Maps Simon uses Sun Tzu’s five factors. These are purpose, landscape, climate, doctrine and leadership. Let’s exam these in the context of a development team.
This is the moral imperative, what we are doing and why we are doing it. For a software development team this could be the product they are building, the project, the user need, their mission etc. This is the first point that we realise our maturity map is set in the context of the problem we are trying to solve.
This is the map that shows the value chain that represents how we act towards our purpose. What is the value chain of practices that we use to satisfy our customer need and the maturity, in our context, of each of these practices.
These are the forces that act on our environment. In the context of our software development team we could consider WIP, deadlines, quality, dependencies, team dynamics, work environment (co-location, wall space) etc.
Simon describes these as standard ways of operating, Trent refines this to be a “set of heuristics that inform decision-making”. This could be things like… focus on flow, develop feedback loops, visualise, inspect and adapt etc.
This is about the choices you make, about how you act to improve your situation considering your purpose, the landscape and the climate you operate in.
An example would be good around now
Let me set the scene, to keep it simple we’ll focus on a one team one product example. The Big House company run a popular website for the housing market. One of their teams has the responsibility for the search function and their mission is to ensure home buyers “find the right home”. The team comprises of a Product Owner, 3 back end developers, a dedicated front end developer, a user experience designer and a tester. The team also work with a separate team of DBAs and have an Agile Coach supporting them.
Building the Map
To create a context specific Maturity Map we’ll first need an anchor. Given our example this seems straightforward, our anchor is our mission “find the right home”.
From this anchor we can then create a value chain that reflects how we as a team go about satisfying that customer need. To help guide this I start by considering 3 paths:
- Building the right thing
- Building the thing right
- Building it fast enough
If we follow one of these paths this could lead us to a value chain that looks like: