For years, companies and teams have focused on adopting agile at the team level. Team members and ScrumMasters work to improve their sprint planning and collaboration techniques—the things they do on a day-to-day basis to execute work. Product owners, ScrumMasters, and team members also focus heavily on delivering projects—learning how to use a product backlog, do release planning, and deliver more, faster. The problem is, being good at executing Scrum or Kanban is not the goal. Organizational agility is the goal.

Suppose, for example, you reach a point in your agile implementation where teams are delivering and executing in a much more productive and efficient way. That begs the question, are they delivering the right things? Now that teams can deliver faster with better quality, how does an organization leverage these newly acquired super-skills? 

The answer is clear: the business and product strategies have to change, too. If teams can deliver faster and more iteratively then we need a product or business strategy that can take advantage of these capabilities. It’s not enough to continuously improve how we deliver. It’s not enough to just keep scaling agile to encompass more and more teams. What we must do is improve our ability to figure out what to deliver next. We need to incorporate feedback, learning, experimentation, and rapid delivery into our business and product strategies—without these all we’ve figured out is a faster, better way to deliver the same old results.

What many organizations have discovered in their adoption of agile is that their organizations are rich in policies and controls that were installed to support a process they no longer use. In order to achieve their organizational agility goals, these organizational policies and processes need to be adapted to match the new agile execution, delivery, and strategy models. For example: If existing release management policies require a 3-month conveyor belt to deploy a completed product but the team can deliver completed product monthly (or even weekly), those release management processes and policies must change in order to take advantage of team’s abilities.

To truly pursue organizational agility, we must tackle and transform emerging constraints— things like signoffs, stage gates, metrics, performance plans, risk management, etc. This goes far beyond team-level problems (or even enterprise agile) to the systemic constraints that stand in the way of true agility.

In his 2009 Blog Post (http://bigv.is/xBNZEe) George Schlitz talks about the need to change these rules.  He states:

“Organizations make rules to operate in the presence of limitations…the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations.”

As organizations improve how they operate they must change their organizational policies to deal with new constraints – not treat the existing policies as constraints themselves.

2012 will be the year that organizations start to turn the corner in their agile adoptions. They will recognize that team- or project-level adoption of Scrum, XP, Kanban, Lean (or some combination of agile processes) is only the first step towards achieving organizational goals. They will realize that organizational policies, process, and often, structures, need to change as well. Some will find the challenge too daunting—But those who figure out how to evolve their organizations; those that make it a priority to effect organizational change in order to meet ever-changing markets; and those that realize a sense of urgency and respond to it will find themselves on the path to true organizational agility.

 

Works Cited:

  1. Schlitz, George. “Agile Removes Limitations…You Must Now Change The Rules.” Web log post. BigVisible Blog. BigVisible Solutions Inc., 10 Nov. 2009. Web. <http://www.bigvisible.com/2009/11/change-the-rules>.