The purpose of governance is to provide confidence that expensive development projects are progressing at a satisfactory pace and will deliver the required outcomes at the required quality.
They are often applied at a ‘whole organization’ level, with all teams required to report into them in the same way. They have often evolved from traditional, linear project management processes, often with checkpoints, gateways, milestones and compliance documents. Which is fine if we believe that the solutions being delivered are relatively stable and unlikely to change. However, what if that’s not the case? How do they cope if the problem space evolves, the criteria for success are unclear or the stakeholders change their minds?
Our approach to Governance is fundamentally broken
It isn’t just the processes that are broken, but our whole approach to Governance. We need to fundamentally change how we approach Governance. We need to move away from linear, lagging measures and treat Governance as a constantly evolving landscape that we test iteratively and look for signs of incremental progress through leading measures.
Luckily, this is exactly what Essence enables us to do. Unluckily, it isn’t that obvious. Like many paradigm shifting changes, when we view it through the wrong lens we can apply it in the wrong way, getting the same results as we get today, just with some new language. But when we shift our outlook, we unlock a powerful new approach to governance that works with Agile teams, not against them. And gives us a far more honest and valuable insight to our progress.
The prevailing wisdom
Currently, we assume that development is a linear progression from start to finish. Each stage we complete is a cause for celebration; a step along the path that we can check off and forget. We set out these paths in advance. We define checkpoints, acceptance criteria, roadmap items, workflow steps, Kanban boards and definitions of done. We often see teams breaking epics or features into stories and Sprint goals into tasks.
We then see the reverse in action. When all the tasks are complete, we declare the goal met; when the stories are done, the Epic must also be complete. We can solve some of this by setting the critical acceptance criteria at the higher level – the goal or Epic – but the tooling and, critically, the governance often doesn’t encourage this. We are conditioned to reporting progress of a higher level goal – a feature or release – in terms of how far through the list of subservient items we have come.
The problem is that these are lagging measures – we don’t know we have a problem until we have already failed. the expected item isn’t met. And because the artifacts we are measuring are part of the team’s process, it becomes hard to measure unless the teams are all using the same process. If one team uses ‘Feature’ to describe what another calls ‘Goal’ and a third calls ‘Epic’ it becomes confusing - especially if team 1 also use the work Goal, but for something else. We can see why we end up mandating the same process on everyone.
Progress isn’t cumulative any more
The traditional approach to measuring progress places huge value on what you have been doing. However, that’s really not important at all - what matters is where you are now, not where you have been.
We are not marching forward along a path, with each step taking us closer to our pre-determined destination, and each action laying a solid foundation for future work to build upon.
Modern development in today’s volatile, uncertain, complex and uncertain world isn’t a temporal path; it’s a set of independent locations that we jump between. Often building on previous work, but also frequently discovering that earlier success needs ripped up and replaced. Being successful three sprints ago is no longer a good indication that we are still being successful now.
This means that measuring progress is an iterative and stateless process. The previous condition of the team or the product bears little relevance to their current condition, since the things that led to the previous assessment could (and probably have) changed.
This shift - from seeing development as a linear progression from start to finish, to seeing progress in a series of temporal snapshots, each showing the current state of the endeavor – is a profound and fundamental paradigm shift.
How does Essence solve this?
Essence helps thus situation in two ways. The first is simple. By describing a kernel that is the common ground for all software development, it offers a method agnostic platform from which to build a governance perspective from. Teams can then use the set of practices and approaches that best suit and as long as they can relate their work down to the essence elements, we can get a consistent set of reporting, even when teams use vastly different development approaches.
We can even build a minimum viable governance layer on top of the kernel of organization specific elements that are particularly significant, for instance, security artifacts or high level goals.
But this doesn’t solve the whole problem. We can still use the Essence kernel states as if they were a series of milestones that, once achieved, can be celebrated and forgotten about. In that respect, it starts to look a lot like any other development approach. We may be standardizing our governance from the bottom rather than the top, but we are still thinking in a linear way.
The real power of Essence comes when we use it to enable a different way of thinking. When we treat each state assessment as an independent event. Essence enables progress to be measured by repeatedly observing the current states of the things we care about and using that to indicate the health of our endeavour. Since developing software involves multiple moving parts and frequent change, the progression of state is not always forwards.
Each observation of state is a fresh look at the whole endeavour. Since states are additive, each state assumes all previous states have been achieved and, critically, continue to be achieved. This means we should revisit the checklists for states previously achieved. Since the states represent the current state, they can move backwards aswell as forward. This means they are leading measures. They can indicate future problems in ways that tracking tasks and epics cannot.
This subtle but important shift underpins the power of Essence for Governance and compliance. It allows the governance perspective (defined in terms of Essence elements) to change as circumstances change. This forces teams to have an holistic view on their endeavour, always focusing on the whole endeqavour, not just the next step forward.
It makes it easier to dial down (or up) governance when you need to. You define the minimum viable governance, allowing team autonomy in other areas. When a governance viewpoint changes, it will automatically be retrospectively applied by teams the next time they review their state achievement (since there may be different checklist items, prompting reviews of previously achieved states).
Applying governance and compliance in this way empowers the teams to show confidence that the work is always on track, connects teams to the important compliance and governance concerns, while freeing them to deliver their product in the best way for them. This connection of purpose is not only more empowering, which should lead to higher performing teams, but also provides a much more accurate view on progress and faster identification of problems.
It’s the best of both worlds.