Agile governance: Part I (Need)

overloaded-truck-pakistan

I am working with a client to achieve Org level Agility and methods to sustaining it. It should be such that once I am out of the system, and which is going to be real soon, they should not miss me, they should be self-reliant and be able to drive further changes themselves. In this transformation journey, I will be working with Process, Quality, Tools and Support teams in conjunction to development teams, Product Management group and other enabling bodies (Like UI/UX, Technology Experts, and Architects etc). We know why Organizations need enterprise Agility, and in this blog I am reflecting on factors that ask for Governance to keep Org level Agility intact.

For any organization to achieve enterprise agility or sustain it, governance is an important consideration. In case of technologically advanced and innovating Start-ups who are multiplying workforce and products every year, it becomes difficult to maintain their INTRINSIC Agility. They can only get away with fairly informal governance when they are small, but as they grow larger, they cannot function effectively without formal controls in place.

As a Transformation Agent, my goal is to find the right balance between the complete chaos of no governance based lean Start-up and the overpowering impact of governance on Agile benefits.

Let’s have a look at factors that call for the need of Governance:

  1. Disoriented and disengaged workforce:

The initial group that forms the Start-up is highly motivated, they create vision and mission. But as expansion happens, new people joining workforce might not share vision and mission of initial group. Naturally they will not have same passion, same accountability and of course clarity of vision and mission. There arises need for clear directions, enrollment of new folks into company’s vision and mission. This also creates need for few guiding roles like leads, PMs, Domain Experts etc, which were not needed earlier.

  1. Disconnected focused groups:

When team was small, everyone was doing everything possible, and if not possible, then they learnt to make it possible. That is secret sauce of success for Start-ups. But as they grow, it becomes difficult for everyone, on same BIG team to even know everything. Teams start needing resizing and reorganizing. Doing that is not a problem, but keeping them connected, so that you don’t form silos, so that they still roll up to same vision and mission – that becomes a challenge. So you need some common grounds where they all meet.

  1. Increasing Knowledge Gap:

With creation of focused group, and new people joining workforce, the valleys and mountains of knowledge gap starts emerging. If that is not taken care, it starts backfiring complete strategy.

  1. Missing accountability:

With the smaller group, everyone is doing everything and ensuring the delivery. But with the bigger group and wide range of people (motivation, engagement, focus, knowledge) the chances of missing something important is very high because group accountability starts fading in case of bigger group, and so there comes the need of process that ensures that every check box is ticked. This will give rise to a few new roles clearly defined responsibilities ensure accountability of delivery group.

  1. Need for a Product visionary group:

There had always been a product visionary group, the same group which found organization and let it’s developers to create that wonderful product. Product creation is one aspect and taking it to market, finding clients and living up to their expectation is another. Many Start-up die at this very stage, and those who make it, they struggle with growing customer base. Once these two are achieved. There comes third stage, and which is expansion. With expansion comes the need to clearly communicate vision of company, and separate management of different sub-products / new products. And this can’t be done by initial group of leaders. Its like using same light source everywhere. You need more of them, not the visionary, but their mirrors. This group is called Product Management Group, which takes feed from multiple product stakeholders, treat developers as well as stakeholders, and create 80-20 principle filtered features list.

  1. Better Product Support Group:

Initially this was also part of development group’s job. It was definitely served best this way. But with time team changes, team grows, product line grows, product architecture changes and almost everything becomes so big, that a need for new group that can respond to the P1s and customer calls on priority arises. With multiple teams in existence, there is always confusion about who should actually be fixing the prod bug, and so there has to be one support team that fire fights, and fix it, and then later finds the real culprit (not to crucify but to ensure safety in future).

  1. CI Tools Group:

If you talk about speed and have to bring in automation and CI, and hence, not very big, but a team to manage and support these tools is needed. This team also ensures that everyone adheres to the tools usage process.

These are few top of my mind factors calling for some regulation and checks and balances in place. In the next blog I am going to talk about the paradox here – Agility and Governance. Agile means decide as per need of team, product, customer, so that you are flexible enough to accommodate change; and Governance means controlling and directing; and it was this control and directive approach that killed creativity, beauty of human connection and welcoming change for customer satisfaction, which gave birth to Agile. So we’ll talk about in next blog about Agile Governance.

Leave a Reply