Progress is impossible without change, and those who cannot change their minds cannot change anything. ~ George Bernard Shaw

Standardization and Autonomy - Can they co-exist?

Companies have two avenues for growth: acquisition, or organic growth. Regardless of how they are growing their increasing size increases the difficulty of the company successfully responding to change. Retaining as much as possible of advantage of that small company’s ability to rapidly pivot can be a key element of a company’s success.

In the past, large organizations were seduced by the notion of having a standardized process across all their product teams within the organization. I can understand the appeal of having one “best process” uniformly across the organization. However this appeal is based on a manufacturing paradigm of working with tangible items which does may apply in other industries.

Process standardization at the organizational level gives the benefits of:

common reporting/monitoring processes, formats, and channels
simpler governance decision-making

One other presumed benefit is a reduced cost of moving teams around the organization, but this is rarely realized because intellectual work cannot be mass produced.

Having a standardized process across the organization forces process design to accommodate the lowest common denominator. It also takes a larger effort and time for the organization to be able to pivot and adjust to move as one entity because of the critical mass. From a people perspectives, employees feel like there a cog in the wheel and they're not motivated to improve how they work because they believe it is a big bureaucratic exercise (which it usually is in large organizations) that "other" people have bestowed down on them. This standardization comes at a huge cost for productivity and efficiency within the majority of the product groups.

Giving product groups (and teams) autonomy empowers them figure out the best way for them to work as smaller units to optimize productivity and efficiency. Smaller teams can have shorter feedback loops and can inspect and adapt more frequently and progress more quickly. Smaller scope for process design allows them to optimize more precisely because it is based on a smaller set of skills, expertise, team makeup, and particular product/technology.

From the people perspective, giving the individuals autonomy to define how they work, how to best optimize their own work leads to higher morale, motivation, and productivity. Even when the technology changes over time, giving the autonomy at the smallest reasonable unit allows them to rapidly go through and adopt the change quicker. It also allows each product group (and teams) inspect/adapt/change at the rate that is within their threshold and within the context of their business needs.

Autonomy is one of the factors a motivation that Daniel Pink talks about in his book Drive. I think we can all agree that we want to motivated workforce.

The downside of that autonomy is that the operations of the organization becomes less transparent. Or simply, make it more complex to be able to see if your organization is moving forward.

Can you marry the two to get the best of both worlds? In my experience, YES!

You can do this by loosely defining workflows and processes from the above at a very high level and . This way the organization knows that the highest level of the flow that goes through to deliver products or services. When product groups (even teams within the groups) create their own processes and practices they do it and to detail out between the boundaries that they have to play with. The organization themselves reports on the high level processes to be able to monitor how all the work is progressing to be delivered. Each product group can define their own product group practices and processes for all the teams within their product group, trying to define them at the highest, but still responsible level to allow individual teams discern autonomy and how they specifically meet those.

A good example would be The Definition of Done.

The organization will have guidelines that they want all their products and services to ensure encompasses what they call a releasable product. Each product group will have their level of definition of done that meets their particular products needs in order to transfer the product is ready to be released to the market. Furthermore, each team will have their own specific definition of done that addresses all of the above in any specific things that they feel they need to do to produce releasable software. This should help ensure transparency from the top down. This also allows for easier updates at the appropriate level without it being all or none.

One thing that I did not mention in this post, is that this hybrid will cause more work for external auditors because they will not have one central place to review the processes. However, I would rather put the burden on a few than many of the organization. The regulatory auditors are going to have to just the way in which they audit software companies going forward to meet the new agile paradigm.

This is just one of the scaling mechanisms that I have seen prove successful. I will be sharing more and hope to hear back from you about techniques that you have used in scaling agile across a large organization.

• Organizational Agility Blog