Organizational Adoption of Agile

From Craig Larman - Larman's laws of organizational behaviour:

 

1.       Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures

2.       As a corollary to (1), any change initiative will be reduced to overloading the new terminology to mean basically the same as status quo

3.       As a corollary to (1), any significant change initiative will be derided as "purist" and "needing customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo

4.       Culture follows structure.

i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. John Seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behaviour (the culture) is a product of the system; when you change the system peoples' behaviour changes."

 

I think that those who believe Agile and Scrum are the way forward will be at odds with most businesses that have a deep institutionalized Command & Control structures that rests responsibility, but usually not accountability, within groups/committees while diverting responsibility away from individuals. In Scrum we rest most responsibility on the Product Owner and hold this person accountable for the business value delivered at the end of each and every sprint. It is often this simplicity Scrum provides that is in direct conflict with the ‘status quo’. So how to begin changes to the existing structures?

 

First and foremost, you must have an Executive Sponsor. Without Executive Sponsorship your attempt to directly adopt Agile will almost certainly fail. This is more than just having managers that agree to allow you to use Agile; this is a person who has the rank and status in the business structure who can influence the often many groups/committees who collectively and traditionally have controlled projects.  Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ The Executive Sponsor, along with possibly one or more Agile Coach specifically trained and experienced in agile adoption at the executive level, will be handing out the oars.

 

What if you have no Executive Sponsor or the Executive Sponsor’s influence is severely limited? Under these circumstances, full Agile adoption is very unlikely to happen. However, there is a strategy that could overcome the tremendous obstacles that are in the way but it does depend on you finding some in Mid to Upper level Management more interested in results rather than institutionalized processes. The ultimate result is usually a hybrid adoption of Agile where all or some of the institutional controls remain in place but an Agile sanctuary is carved out with fewer of these institutional controls than a traditional waterfall project. This hybrid Agile project is not truly Agile but neither is it true waterfall. The strategy follows a bottom up Agile Adoption approach that will take time, maybe a lot of time, to slowly chip away at the traditional structure and replace it with an Agile structure and Agile mindset.

 

The strategy is twofold:

1.       Target getting support from managers in the organization that are more likely to support Agile; and

2.       Target going around the organizational structure of “over seers”

 

The strategy includes targeting those executives in middle to upper management that are more likely to support an Agile process and have some influence on those in the organization who are stanch supporters of the institutional controls. The idea here is not to change these people completely over to the Agile mindset but rather get these targeted managers enthusiastic enough about Agile so they can see the possibilities and potential of Agile. Targeting managers who don’t have influence over supporters of the processes or targeting managers who are the stanch supporters of the processes is usually a tactical mistake. Targeting a manager who doesn’t directly influence those in control of the processes might be an easy convert but other than a quick burst of satisfaction, the real battles will still lie ahead. The manager who is a supporter of institutionalized processes is very difficult to convert; they probably believe in their familiar processes and controls much like you believe in Scrum, albeit for different reasons. A word of caution, because you’ve gotten some support for your Agile project, you must remember that “success has many fathers, failure is an orphan.” For those in middle to upper management who supported you earlier, to ensure their continued support of Agile and endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If your project fails or succeeds but with only a whimper, some, most, or all middle to upper manages may forget that they ever supported Agile.

 

The second part of your Agile adoption strategy will be to identify all those organizational groups and individuals who traditionally sign-off on projects and find a way to exempt the Scrum project from these. These groups are those who sit on gate committees, steering committees, technology committees, or any one of a dozen other committees that approve, sign-off or use other mechanisms of “over-seeing” a project. These groups are often a source of power and prestige for its members and are traditionally very difficult, if not impossible, to get around without an appropriately positioned Executive Sponsor. The best way to get around these groups is to make your project a separate business unit that answers to the CEO/board. This follows along how IBM built its PC division in order to get out from under the bureaucratic thumb of IBM’s corporate structure.  Another tactic is to chip away at the required process these groups require projects to follow. This can lead to some relief for the project but will probably not succeed at allowing full Agile adoption for quite some time.

 

Is doing a Hybrid Agile Scrum adoption good? The short answer is yes. By simply following the activities defined for Scrum, (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff Sutherland has said that this will increase productivity by 20%-30%. However, the greater benefits of Agile are really attained through following of and embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and Scrum Primer. To become “hyper-product” would require everyone involved in the project (managers and scrum teams) to believe in and live Agile and Scrum. Unless the Mid to Upper level Managers of the business are only interested in results and don’t really care how you achieve them, your best approach to adopting Agile is incrementally, one step at a time.

 

Craig Larman is co-author of:

• Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum
• Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
• Agile and Iterative Development: A Manager's Guide

Tweet