Bimodal IT and two-speed IT miss the point

We can't trade-off reliability for speed in the medium term. Models that make this assumption are inherently flawed. If you really want to think in terms of a two-pronged approach, think strategic and utility as I describe in my post on business-capability centric orgs. Martin Fowler seconds it.

Three principles of Agile IT Org Design

I wrote an article for InformIT where I describe three principles of Agile IT Org Design that the book recommends and elaborates:

• Govern for value over predictability
• Organize for responsiveness over cost-efficiency
• Design for intrinsic motivation and unscripted collaboration

Essentials of scale-out management

I have previously stated that Agile scales by scaling-out rather than scaling-up. I expand on this in a presentation at an event in London. (slides)

Org Chart Debt - A Risky, Off-Balance Sheet Liability

Recently, Steve Blank, a luminary who developed the Customer Development methodology, a precursor to the Lean Startup movement, said that organizational debt is like technical debt in software but worse: “Organizational debt is all the people/culture compromises made to 'just get it done' in the early stages of a start-up.”

“Just when things should be going great, organizational debt can turn a growing company into a chaotic nightmare. Growing companies need to understand how to recognize and “refactor” organizational debt.”

He was talking about organizational debt incurred by startups at the time of hiring lots of people as it prepares to grow. On the other hand, Enterprise IT incurs organizational debt throughout the course of its existence.

“IT organization design is rarely thought out from a baseline of principles. The prevailing design is mostly a product of happenstance, mergers or acquisitions, people-retention compulsions, and the ideas of whoever is in charge at various levels in the organization. It resembles how software accumulates technical debt over time unless we periodically step back and reassess the design.” Agile IT Organization Design

And as with all debt that isn’t repaid on time, unaddressed organizational debt creates more problems. It results in silos, politics, unclear accountability, slow decision making and poor responsiveness to the market in general. Read further.

Do you scale Agile vertically or horizontally?

Most attempts to scale Agile struggle because the IT leadership attempts to scale up (vertical) rather than scale out (horizontal). Scale-up is old school management. It involves context-free management by numbers, standardized metrics, reports and dashboards and workforce motivation by targets and incentives. Inside IT, this approach usually ends up scaling supervision (not management) without improving IT performance. This is why we find managers functioning as supervisors and Scrum masters functioning as taskmasters in self-proclaimed Agile enterprise IT.

“Individuals and interactions” is not a marketing buzz phrase. It has to be taken seriously in the pursuit of agility. The organization has to be designed for intrinsic motivation and unscripted collaboration. Chapter three of Agile IT Org Design elaborates on this. Individuals respond to an environment of autonomy, mastery and purpose. Leadership balks at autonomy because it worries about loss of alignment with strategy and weakening of accountability. Chapters six and seven of the book explain how to allow autonomy and yet preserve alignment and accountability (using decision records, for example). This is the basis of scale-out management.

A “definition of done” for Agile at scale

It seems everyone wants to scale Agile. Many say they have done so already. But there are different views on what the end state looks like. What does it mean to have scaled Agile? For many, it simply means replicating certain practices across all development teams. Although this may improve the internal quality of software, it won’t help improve overall IT performance as perceived by the business.

Agilists advocate that every story must have acceptance criteria. What are the acceptance criteria for having scaled Agile? More broadly, what is the “definition of done”? Here’s one:

• Responsive IT: Achievement of continuous delivery for the entire value stream (not just development team) from feature concept to cash or user adoption.
• Valuable IT: Innovation occurs relatively unimpeded by artificial organizational constraints.
• One team: Business and IT are able to work as one team even if they are separate on the org chart.
• Scaled performance, not just supervision: Don’t say you have scaled Agile when all you have managed is to scale supervision of Agile. Has it made a difference to business outcomes? That’s the litmus test.

In my upcoming book, I explain that this target state cannot be attained without improvements to the design of the IT organization.

What really hinders Agile at scale

Update: 10-June-2015
Article in ThoughtWorks Insights

Update: 27-May-2015
Here's the full video of my talk:

Older post:
Organizational agility is required in order to scale Agile. It requires changes to IT structure, operations and governance. This is different from engineering and process agility that development teams focus on. I’ll cover this using real examples in my talk at Agile India 2015 tomorrow (25^th March) at 3:30pm.