The Science of Successful Organizational Change

The Science of Successful Organizational Change

The Science of Successful Organizational Change: Re-read Week 1, Introduction

Today we will begin the next book in the Re-read Saturday Series, The Science of Successful Organizational Change. Steven Adams (SPaMCAST 437, SPaMCAST 412 and nearly every entry in the Re-read Saturday series) will lead this re-read.   Remember to use the link to buy a copy to support the podcast and blog.  In the first installment, Steven will introduce the book, his plan for the re-read, and tackle the introduction.  I will add comments after each installment has been published.  Please share your comments!

The Science of Successful Organizational Change: Re-read led by Steven Adams


I stumbled into Paul Gibbons’ book “The Science of Successful Organizational Change” (get your copy).  I was searching Amazon for “Agile Change Management”.  The book’s sub-title “How Leaders Set Strategy, Change Behavior, and Create an Agile Culture” helped reveal this title to me in the search results. (more…)

Book Cover


Chapter 8 begins the third section of Holacracy, Evolution Installed: Living Holacracy. We have approximately three weeks left in this re-read after today.  The next book is The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.  Steve has been an active participant in many of our previous re-reads and has appeared twice on the Software Process and Measurement Cast to discuss earlier re-reads.  I will provide supplemental comments and highlights to Steve’s insights!  I am looking forward to sitting on the other side of the table during the next re-read!

Chapter 8 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015 is titled Adopting Holacracy.  This chapter begins to draw a number of loose threads together.  Personally, I find this chapter a bit disjointed (although useful). The chapter is formatted as a mixture of questions and answers and then a five-step process to bootstrap the use of Holacracy. (more…)

This week, we tackle chapter 2 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 2 tackles why the consolidation of authority is harmful to the ability to nimble, agile (small a), and productive and secondly, why the distribution of authority supports an organization’s ability to scale.  The argument in Chapter 2 is a central tenant of Holacracy.


Chapter 2: Distributing Authority (more…)

Book Cover


This week, we tackle chapter 1 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Holacracy is an approach to address the shortcomings that have appeared as organizations evolve. Holacracy is not a silver bullet, but rather provides a stable platform for identifying and addressing problems efficiently.

Part One: Evolution at work: Introducing Holacracy

Chapter 1: Evolving Organization (more…)

Fire Alarm


Kaizen is a Japanese word meaning good change. Change in a dynamic business environment has become an accepted norm. Organizations must adapt or lose relevancy. The concept of kaizen has been adopted within the information technology industry as part of core management practices. In business terms, kaizen has been defined as continuous incremental change. You need energy to make change occur, in many cases, a sense of urgency is the mechanism used to generate the energy to drive continuous change. (more…)

A wrapping paper change barbarian

A wrapping-paper-change barbarian

When you begin a change process it is important to remember a few critical points. If you were getting ready for vacation, the checklist might include identifying who is going and who is in charge, deciding on a destination, a map, and hotel reservations. Beginning a process improvement project is not very different. Here is my simple checklist with five of the most critical requirements for preparing to embrace a journey of change. My critical five are:

1. An Identified Goal

2. Proper Sponsorship

3. Sufficient Budget

4. A Communication Strategy and Plan

5. A Tactical Plan

The first item on the checklist is an identified goal. The goal is the definition of where you want to go; the destination in the vacation analogy. A goal provides direction and a filter to understand the potential impact of constraints. Examples of a goal can range from something as simple as, “reduce the cost of projects,” or as complex as “attain CMMI Maturity Level 5.” The goal also sets the table for discussing all of the other items on the checklist, such as the required budget. One piece of advice: make sure your goal can be concisely and simply stated. Simplicity increases the chance the goal will be broadly remembered, which reduces the number of times you will need to explain the goal, which will increase the amount of time available for progress.

Proper sponsorship is next on the list. Sponsorship is important because it is provides the basis for the authority needed to propel change. There are many different types and levels of sponsorship. The word “proper” is used in this line item to remind you that there is no one type of sponsorship that fits all events and organizational culture. One example is the “barbarian.” The barbarian is the type that will lead the charge, but typically is less collaborative and more a command-driven personality. Barbarians tend to be viewed as zealots who harness their belief structure to provide single minded energy towards the goal they are focused on. Having a barbarian as a sponsor can infuse change projects with an enormous amount of power. The bookend to the barbarian type of sponsorship is the “bureaucrat”. Sponsorship from a bureaucrat is very different. Instead of leading the charge, bureaucrats tend to organize and control the charge. They may provide guidance, but they rarely get directly involved in the fray. The examples show two different varieties of sponsorship each that will fit in different organizations. In a life or death situation, I would like to have a barbarian for a sponsor. However if I was affecting incremental changes in a command and control organization, the bureaucrat would make more sense. Remember sponsorship is important because sponsorship give you access to power.

Budget is next on the checklist. The term budget can cover a wide range of ground ranging from money to availably of human resources (effort). The budget will answer the question “how much of the organization’s formal resources can you apply?” The budget that ends up being identified to support change is always less than what seems to be needed. Use this constraint as a tool to motivate your team to find innovations on the way to attaining the goal rather and a reason to rein in your goal.

The first plan I recommend building is an organizational change management plan (OCMP). The OCMP is frames how your project is going to transform the future state of the organization. It will integrate the project roles and responsibilities with the requirements for communication, training, oversight, reporting and the strategies to address resistance, and reinforcement activities. The OCMP is a mixture of a high-level map and how-to document that is critical to ensure you are as focused on how you are change the organization as to tasks required to define and implement specific processes.

Finally you will need a tactical plan that lays out the tasks you need to accomplish and the order the tasks need to be done. The focus and breadth of the tactical plan you use will be different depending on the project management technique that you use. For example, if you use a time boxed technique like SCRUM your tactical plan will focus on identifying tasks for the current sprint based on the backlog of items required to reach your goal. Regardless of the planning technique used you must have a tactical plan or risk falling into random activity. Use the technique that conforms to your project’s needs and your organization’s culture. The bottom line is that you will you need to understand the activities and order they occur in to get to your goal.

Change is difficult to accomplish in the best of times, and almost impossible if you fail to start properly. This simple checklist for change readiness was developed and compiled to help you focus on a set of topics that need to be considered when beginning any process improvement project. Are there other areas that should be on the list? Can each topic area be deconstructed into finer levels of granularity? I believe the answer is certainly yes, and I would urge you to augment and deconstruct the list and further to share your results. In any case a checklist that focuses you on getting your sponsorship, goals, budget and plans in order can help you start well.

A hybrid

A hybrid

Being Agile is a lot easier than it was even a few years ago. However, there are still roadblocks; including lack of management buy in, not changing the whole development life cycle or and only vaguely considering technical Agile practices. The discussions I have had with colleagues, readers of blog and a professor at Penn State about roadblock have generated a lot passion over the relative value and usefulness of hybrids.

Classic software development techniques are a cascade beginning with requirements definition and ending with implementation. The work moves through that cascade in a manner similar to an auto assembly line. The product is not functional until it rolls off the end of the line. The model uses specialized labor doing specific tasks over and over. Henry Ford changed the automotive market with this technique.  However, applying this model to software development can cause all sorts of bad behaviors. Those bad behaviors are generally caused by a mismatch between linear work like manufacturing and work that is more dynamic and more oriented to research and development. One example of a bad behavior the abuse of stage gates. Often teams continue working even when the method indicates they must wait for a stage gate decision. The problem is that if they wait for a decision they will never complete on time. Managers are ALWAYS aware what is happening, but choose to not ask. It generally is not because anyone in the process is a bad player, but rather that the process is corrupt.

Agile is different. Agile stops the cascade by breaking work into smaller chunks. Those smaller pieces are then designed, developed, tested and delivered using short sprints (known as cadence) in order to generate immediate feedback. The “new” process takes the reason for running stage gate stop signs away.

Hybrid models attempt to harvest the best pieces from the classic and Agile frameworks to fit the current organizational culture or structure. The process of making the Agile (or classic methods for that matter) fit into an organization optimized for classic methods is where issues generally creep in. The compromises required often stray from the assumptions of built into the Agile values and principles.  Examples of the assumptions built into Agile include stable teams, self management and delivering functional software at the end of every sprint. It is easier to wander away from those values and principles than to tackle changing the organization’s culture or structure. One of the most common (and damaging) compromises can be seen in organizations that continue the practice of leveraging dynamically staffed teams (often called matrix organizations). Stable teams often require rearranging organizational boundaries and a closer assessment of capabilities.

Typical organizational problems that if not addressed will lead organizations to generate classic/Agile hybrids include:

  1. Silos: Boundaries between groups require higher levels of planning and coordination to ensure the right people are available at the right time even when there are delays. Historically, large development organizations have included the role of scheduler/expediter in their organization chart to deal with these types of issues.
  2. Overly Lean: Many development organizations have suffered through years of cost cutting and have far fewer people than needed to complete the work they have committed to accomplishing. Personnel actively work on several projects at once to give the appearance of progress across a wide range of enterprises. Switching between tasks is highly inefficient which reduces the overall value delivered, often leading to more cost cutting pressure.
  3. Lack of Focus: Leaders in development organizations often feel the need to accept and start all projects that are presented. Anthony Mersino calls this the “say yes to everything syndrome.” This typically occurs in organizations without strong portfolio management in place. Ultimately, this means that people and teams need to multitask, leading to inefficiency.
  4. Lack of Automation: While I have never met a development practice that couldn’t be done on a small scale using pencil and paper, automation makes scale possible. For example, consider running several thousand regression tests by hand. In order to run the tests you would either need a significant duration or lots of people. Lots of people generally means more teams, more team boundaries, more hierarchy and more overhead – leading to the possibility of just running less tests to meet a date or budget.

The values and principles that underpin Agile really matter. They guide behavior so that it is more focused on delivering value quickly. The four values in the Agile Manifesto are presented as couplets. For example, in the first value: “Individuals and interactions over processes and tools,” the items on left side are valued more than those on the right (even though those on the right still have value). Hybrid models often generate compromises that shift focus from the attributes on the left more toward the center and perhaps back to those attributes on the right. Hybrids are not evil or bad, but they are generally cop-outs if they wander away from basic Agile values and principles rather than addressing tough organizational issues.

Agree or disagree, your thoughts are important to guiding the conversation about what is and isn’t Agile.