Lean Change Management: A Truly Agile Change Management approach

"I've been working in this company for a long time, we've tried everything. We've tried involving the teams, we've tried training senior management, but nothing sticks! We say we want to be agile, but..."

Many people in organizations that try to adopt agile will have said this at some point. Not every company fails to adopt agile, but many do.

Why does this happen, what prevents us from successfully adopting agile practices?

Learning from our mistakes

Actually, this section should be called learning from our experiments. Why? Because every change in an organization is an experiment. It may work, it may not work - but for sure it will help you learn more about the organization you work for.

I learned this approach from reading Jason Little's Lean Change Management. Probably the most important book about Agile adoption to be published this year. I liked his approach to how change can be implemented in an organization.

He describes a framework for change that is cyclical (just like agile methods):

• Generate or gain insights: in this step we - who are involved in the change - do small experiments (like for example asking questions) to generate insights into how the organization works, and what possible things we could use to help people embrace the next steps of change.
• Define options: in this step we list what are the options we have. What experiments could we run that would help us towards our Vision for the change.
• Select and run experiments: each option will, after being selected, be transformed into an experiment. Each experiment will have a step of actions, people to involve, expected outcomes, etc.
• Review, learn and...: After the experiments are concluded (and sometimes right after starting those experiments) we gain even more insights that we can feed right back into what Jason call the Lean Change Management Cycle.

The Mojito method of change

The overall cycle for Lean Change Management is then complemented in the book with concrete practices that Jason used and explains how to use in the book. Jason uses the story of The Commission to describe how to apply the different practices he used. For example, in Chapter 8 he goes into details of how he used the Change Canvas to create alignment in a major change for a large (and slow moving) organization.

Jason also reviews several change frameworks (Kotter's 8 steps, McKinsey's 7S, OCAI, ADKAR, etc.) and how he took the best out of each framework to help him walk through the Lean Change Management cycle.

The most important book about Agile adoption right now

After having worked on this book for almost a year together with Jason, I can say that I am very proud to be part of what I think is a critical knowledge area for any Agile Coach out there. Jason's book describes a very practical approach to changing any organization - which is what Agile adoption is all about.

For this reason I'd say that any Agile Coach out there should read the book and learn the practices and methods that Jason describes. The practices and ideas he describes will be key tools for anyone wanting to change their organization and adopt Agile in the process.

Here's where you can find more details about what the book includes.

On how PMBOK Change management creates variability and reduces predicatbility

In the last post I tried to point out how the analytical approach of any standard (and specifically PMBOK's) will create problems for those actually having to implement those standards.
Change management in PMBOK is a particularly large problem in this respect. Scope Control (PMBOK's process for change management in scope) comes at 19 different activities. This will leave the most experienced project manager grasping for air when it comes to implementing these activities (they are not implemented in a vaccum obviously, but that does not make it easier...)

Contrast that with the approach that Scrum uses: Re-plan every sprint based on the improved knowledge you have of the product and the market.

Now, that's simple! Simple, but not easy.

For Scrum's change management to work properly the people in charge need to understand the stakeholders needs, the market needs and the current state of development. None of these is easy to achieve, but -- and this is the point -- they are easy to explain.

In Scrum, every Sprint will have a small number of ceremonies:

• The Sprint planning: where the previous sprint's result as well as the changes in environment (stakeholders, market, etc.) are input for the planning process
  
• The Daily meeting: where the progress is reviewed and plans quickly adjusted to meet the Sprint goals
  
• The Sprint review + demonstration: where the status of development is analyzed as well as the reasons for possible problems
  
• The Retrospective: where we analyze what went well/wrong and take actions based on that to improve for the next Sprint, i.e. change our process.
  

That's it. That's how Scrum addresses change in scope: by being prepared for it at the very core of the process. Every sprint change is reviewed and handled. Plans are adjusted.

Interestingly this has an important (yet often forgotten side-effect). Because the stakeholders know that their needs will be taken into account in the next Sprint at the latest, they don't feel the need to disturb the teams during the Sprint. This allows the team to focus on the ongoing work and meet their Sprint goals while at the same time not avoiding change, rather embracing it!

Implementing a process based on PMBOK will not take this aspect into account. It is my experience that in practice, a PMBOK based approach will lead to a separate change management process (often through Change Management Boards), which will regularly but at unpredictable intervals submit changes to the teams. Teams, then need to react "immediately" to those changes: reviewing, commenting and sometimes even accepting them. Anyone familiar with Queuing Theory recognizes this problem immediately: adding more work to a team will make them late and reduce predictability because of the added variability inherent in the "change" related tasks.

This is why PMBOK fails when it separates processes like change management into their own "process" within a larger process which is a software development process.

I should however emphasize: there is value in PMBOK. Read it if you can, but you should not follow PMBOK when defining your processes. Rather you should look at Scrum, Kanban or other processes for inspiration on how to run your software development processes. This is because PMBOK is useful, but not enough!

Photo credit: Will Lion @ Flickr

Why PMBOK fails to embrace change

Yesterday we talked about the Project Management Plan process and how it is not adjusted to many software organizations. Today we will talk about the Project Scope Management knowledge area in the PMBOK.

PMBOK defines that within this Knowledge Area there are five processes[1]

1. Scope Planning: plan on how the scope will be defined [plus other activities]
   
2. Scope Definition: a detailed project scope statement as a basis for future [scope related] project decisions.
   
3. Create Work-Breakdown-Structure: dividing [large] project deliverables and project work into smaller, more manageable components [but this particular component is also used for "cost accounting" of the project]
   
4. Scope Verification: formalizing acceptance of the completed project deliverables
   
5. Scope Control: controlling [unwanted] changes to the project scope
   

NOTE: the []'s above are my own additions.

According to PMBOK each of these 5 processes has at least 8 activities and some up to 19 separate activities (Scope Control specifically)[1].

Having so many separately defined, yet inter-dependent activities in a book like the PMBOK points to a key failure in much of the PMI focus. In the drive to standardize the project management process (PMBOK is ANSI standard 99-001-2004) the description of the activities is exhaustive and detailed. It is analytical. In Agile, many of the major breakthroughs have been in not being analytical, but rather synthesizing knowledge into practices. Take the example of Scope Control, one of the processes in the Project Scope Management knowledge area.

According to PMBOK:

Project scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. (...) Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process.

As you can understand from the quote above there's an emphasis on activities related to change control (you have to love their choice of words), because "change is inevitable".

In Agile project management approaches we try to avoid having explicitly separating change control by incorporating it into the core process being used to develop software. This is a HUGE (I'd like to use even bigger letters) difference between what PMBOK and Agile are about.

In Agile we really take seriously the fact that "change is inevitable", and that's why we don't build an extra process for change management. Why? Because often these change control processes are the very reason why projects fail. See for example government fixed-price & fixed-scope projects.

The counter-intuitive insight here is that by isolating change control as a separate process we make change management stiff and slow, rendering it an obstacle rather than an enabler to success.

Now, it still is useful to talk explicitly about how we intend to manage change. That is useful, but ultimately not enough.

If I was advising a new project manager, I certainly would ask them to read about change management in projects. Not just from PMBOK, but also from other books like Mary Poppendieck's Implementing Lean Software Development or any of the many Agile Project management books for example.

On the other hand, I would never, ever suggest that we should have a separate change management process in a software project, and that is, for all intents and purposes what the PMBOK suggests by taking it's heavily analytical approach.

Again we see that PMBOK is indeed useful, but certainly not enough!

In the next post I'll look at some specific ways in which Agile processes explicitly take into account change management without creating an extra process but rather building change management into the everyday activities: synthesizing one of the most important processes into "how we run the day-to-day activities in projects".

[1], PMBOK 3rd edition, 2004

Photo credit: David Reece @ Flickr