A blog about software delivery, Agile & DevOps by Mirco Hering

Agile Governance – A short overview

I recently ran a seminar on Agile governance, so what does this even mean? Agile governance requires you to find the right balance between the complete chaos of no governance at all and the smothering of all Agile benefits in overbearing governance. In this article I want to provide an overview on Agile governance across a few levels: Transformation, Program, Project and team level. There is a lot more to be said than I can put into this post, so expect me to come back to this over time.

Agile Transformation governance

To borrow from Lord of the Rings “One does not simply transform an organisation to Agile”. At the transformation level it is important to provide support for teams as they encounter challenges for adopting Agile. Some problems can proactively be addressed like training, coaching and enable good engineering/DevOps practices. Others will be uncovered as you start down the adoption path. Those blockers can be identified from the retrospectives at the team level as well as by speaking to Iteration managers and coaches. These blockers should be prioritised and provide the transformation backlog to address at organisational level. I find the below transformation governance structure very helpful as a starting point:

Agile governance at the program/project level

I have shared my view on how to manage at the program level before here. Just one additional word of warning: Do not try to compare teams against each other for performance measurements, even under the guise of gamification this really can only lead you to bad development patterns. There are teams where this works and where their leaderships does not use the information for the wrong reasons, but the risks are higher than the benefits. Defining the success criteria for each team individually is a much better way to deal with this.

Agile governance at the team level

At the team level the SCRUM methodology provides a set of useful governance elements which you should leverage, adopt and adapt:

Sprint Reviews

Sprint Planning

Retrospectives

Team based estimations

Additionally you can use Agile maturity models and Agile metrics for teams to evaluate themselves and their progress in maturing their Agile practices. Good coaches can help teams in this evaluation without being judgmental.

A comment on measuring individual productivity:How do you measure the productivity of team members in your Agile teams? The short answer is YOU DON’T. I have talked about productivity in this post and if you don’t believe me perhaps Dilbert can help you understand how poisonous this idea is for your teams:

I am looking forward to hear from the community what you use to govern your Agile adoption across the different levels.