I recently ran a seminar on Agile governance, but 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 blog, I want to provide an overview on Agile governance across a few levels: Transformation, Program, Project and Team.
Agile governance at the transformation level
To borrow from Lord of the Rings, "One does not simply transform an organization 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 and 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 prioritized and provide the transformation backlog to address at the organizational 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:
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 hearing from the community on what you use to govern your Agile adoption across the different levels. Please reach out @MircoHering.