Managing Organizational Change as a Result of the Agile Process

The second half of the day, however, was not as smooth and obvious as the CEO expected. He communicated his top three goals for the year confidently. The consultant running the session then recommended that the goals be adapted to user stories in an effort to teach the CEO and his team how to use this agile practice and develop a more specific definition around each goal.

The instruction was simple; a user story template was explained, an example was given and then the group discussed that the final task would be to assign a value currency and effort estimation to the story when it was complete. Everyone seemed positive and prepared to get this done. About 45 minutes into the first story, there was disagreement and confusion about how to define the goal and the acceptance criteria so that the team would accept that the goal had been accomplished.

If you are a current practitioner of agile, then this example may seem a bit extreme but it represents the majority of enterprise organizations across several industries. Agile is industry agnostic. As a methodology and as a change program, it is not influenced by the company’s main business. In most enterprise companies that have dabbled with agile, you’ll hear people say that “we are doing agile” or “we’ve done agile”. But how often do you hear a company tell you “we are being agile”?

The challenge we have with agile is the term itself. As with many terms and phrases, people typically hinge on the term/phrase itself and slowly separate themselves from the practices that make it up. Being agile implies more than change - it also implies disruptive change; the type of change that requires people to do things differently than they are used to.

Trends are positive in showing that agile practices are going well beyond the application development layer, where they have traditionally been used. Many organizations are now experiencing the same sets of practices across their entire organizational stack in IT and to some extent on the business side. In fact, consider that lean programs are reflective of the same sets of practices that you see in good agile programs. Therefore the link between the two is moving at a rapid pace in many enterprise companies that have seen the results that these efforts can bring.

Agile across the enterprise is a topic that has been written about during the last few years but has only recently begun to produce success stories to support it. Within the topic of agile in the enterprise is the emphasis on organizational change.

To get to the state of being agile requires a number of considerations. The two primary considerations are cultural change management and training agile teams.

When we consider introducing agile into the organization, we are speaking about a program level effort vs. a project. This means that it involves people across the organization and not just in an IT team. It infers that management teams at all levels will support the program, use the practices and lead by example.

The most successful agile projects are not the ones where process was followed to the letter, although that is important. They are the projects where the passion and commitment of the people involved exceeded the status quo, the traditional way of thinking and working. The best agile projects always involve people who are willing to disrupt the norm and overcome the barriers that change represents in the minds of many. It is more a mind-shift rather than a set of processes to follow.

Cultural Change Management

As companies plan for agile and for this level of change, the primary emphasis is on something we refer to as cultural change management. To understand this better, we will discuss the main points under this topic. For starters, any time a change program is introduced, it is expected that there will be points of resistance throughout the organization.

For this reason, one of the recommendations often made is to employ a practice called Customer Value Analysis™ (CVA). This process uses well?known business and functional analysis techniques to quickly and reliably derive user stories from business goals in an incremental and iterative way.

The process won’t tell you what the solution is, but will help uncover the questions that need to be answered. Understanding what is needed to make the program a success is the greatest challenge with any program. A complementary set of tried and tested business and functional analysis techniques enable quickly and correctly determining what the different people involved in the program really need to achieve their goals.

Think of CVA as the initial level set to get the organization and its key stakeholders on the same page regarding what “being agile” really means to them. The approach helps the team to reason backwards from the path of least resistance and identify real options for change; options that can be estimated in terms of their value and effort to the company.

From the onset of CVA, a systems thinking approach is used to identify and challenge assumptions that the team has. This is followed by dispelling the assumptions one by one so the logical flow is clear to everyone.

The success of cultural change management is predicated on the ability to do this work upfront. Rather than just gaining consensus, this demonstrates a reality that shows an iterative and incremental path to change, in true agile fashion.

The change path also involves introducing the teams to specific tools and practices that will benefit them. One common mistake organizations make when adopting agile is the assumption that all the known agile practices must be used and understood. While that type of knowledge and know-how is helpful, it is often an impediment to change. Being agile, as you would expect, means adopting only what you need at the moment with visibility into what else may come later.

Some of the key practices used to drive adoption for change include:

• Visual Management
• Business Value Modeling
• User Stories

Visual Management

Agile is very much about visual tools and management. The agile community has rejuvenated the Post-it^® all over again. Perhaps the most well known visual agile tool is the scrum board, or as we referred to it earlier in this article, the Kanban board. This is the visual tool that represents the four columns that allow a team to move the stories, noted on Post-it notes or index cards, from left to right to get them to the “done” or completed column.

Having the scrum or Kanban board is a mandatory tool, however we recommend that organizations using agile to drive a change program also employ some type of visual stream mapping, a more commonly known lean practice.

The idea of visual stream mapping is to visually display the change program, identify desired and undesired effects, understand prerequisites, and begin to develop a view of which people and teams will be impacted and responsible to help drive the change.

While a scrum or Kanban board are great progress tracking tools, visual stream mapping helps shape roles and responsibilities and it allows for risks and impediments to be surfaced.

Business Value Modeling

Organizations put lots of effort into defining their goals and objectives each year and while each of them are critical to the business, not all of them carry the same value.

An agile change program is driven by a continuous improvement effort to quantify and validate goals. Teams need to clarify and come to a consensus on the goals to be achieved, how to determine that the goals have been achieved and what value will be added when the goals have been achieved. Organizations that initiate an agile change program will visually map the change program itself, work on a business value model and then develop their user stories around the major initiatives/goals. This ensures that they know that they are working on the right things in the right order according to the value/effort equation and what it brings back to the business.

As with all the other models, these are built up and improved iteratively. As we discover new or better information, we revisit the models. The Business Value Model™ shows the strategy of a project or organisation.

The premise is to identify the business value drivers and then define them. To define them creates a method to measure whether goals are attained. For example, (1) customer satisfaction will be measured with six?monthly customer surveys and (2) revenue will be measured by the monthly Profit amp; Loss statement of each department. Each measurement is a possible business value driver that will drive the project in the right direction to maximize business value generated.

From here we build a Business Value Model from business value drivers and define the relationships between business value drivers and how we’ll use them to steer the project. For instance, keeping existing customers satisfied is more important than short-term income (a trade off) and employee stress levels must not increase (a constraint). It is this type of root cause analysis that is often neglected beyond the definition of high level goals that seem credible at first.

A Business Value Model will provide a level of detail to support the third practice used to drive adoption of change: user stories. The objective is to define the stakeholders that will drive the change program, their respective goals, the tests and measures for each of those goals, necessary capabilities to achieve them and associated constraints or risks for each.

This exercise allows organizations to initiate a culture of transparency and accountability. It also allows for flow in how a change program moves and operates through a lifecycle.

The completed Business Value Model can then be translated directly into user stories to support the change program and the specific things we’ll work on to get it done.

User Stories

The practice of user stories in agile is somewhat controversial. Many practitioners seem to have their own view of how to best write a user story.

While a template has merit, the objective is more important. A user story is an agile practice that forces a clear, succinct expression of goals and success criteria into an index card sized paragraph. While it can be larger, the idea is to articulate what you are trying to get done.

Many organizations use heavy documents and presentations to communicate their change programs and, in many ways, the user story is the business plan in bite-size pieces with the added benefit of having each piece valued.

Change programs can be vast, so the objective is not to try and identify every possible objective, but to focus on what the primary and secondary ones are for the company and then prioritize them by business value, something we’ll discuss next.

In the real life example we used in the beginning, the art of writing a user story is so simple that it becomes enormously difficult for many. The reason is that people are accustomed to saying and writing more than is needed. There is a common need to explain things in painful detail, but when asked to describe what we mean in a concise and straightforward manner, it gives reason for pause to consider how we condense all our thoughts into one or two sentences. This is not easy, yet teaching agile change teams how to do this well has proven that acceleration in adoption is very high.

As an output of Business Value Modeling, you can see how writing user stories can have a common template and how each section would directly tie back to the business value model sections we defined.

• TO:
  • lt;Describe the goal defined in the Business Value Modelgt;
• AS A:
  • lt;List the stakeholder, the person/group accountable for this storygt;
• I NEED:
  • lt;Define the capabilities needed to achieve the goalgt;
• ACCEPTANCE CRITERIA:
  • lt;List the criteria that will communicate the goal is achieved/donegt;

Perhaps this exercise seems simplistic, but well defined stories supported by well defined tasks, visually mapped so the organization can clearly see and understand the path to change, are the fundamental building block to the most successful agile change programs on record.

Training Agile Teams

The other important topic to address regarding managing organizational change programs through agile is training. By training, we mean education or learning doing. We don’t mean just sitting and listening so we can tick the box and say we went to training.

A common misconception with agile is that people can simply be sent to training once or infrequently and still be knowledgeable enough to do the work. The reason that traditional agile training has not had a long term and sustainable impact is that many organizations treat it as a point in time exercise rather than a culture of continuous learning. This approach lends itself to a lack of strategy for how the investment in training is spent and to a fragmented learning path for the team that is not cohesive or coherent.

Historically, some of the challenges with agile training are that it is not context sensitive or always practical and useful.

Change programs predicated on agile need a training curriculum and strategy that helps companies understanding the path to learning and doing. This curriculum would involve:

• Assessing the organization’s overall skill levels
  • Benchmark skills according to roles, knowledge and experience using a framework of proven context-sensitive practices
  • Review competencies based on process, output and quality of work
  • Perform comparison with peer organisations

• Scaling Agile Training beyond the classroom
  • Content
    • Experiential learning
    • Context aware
    • Practical
    • Different approaches that realize the same principle
    • Useful in real situations
    • Good basic understanding of values, principles, practices

• Train people involved in the change program
  • Extended team (partners, vendors)
  • Executive, Senior and Middle management
  • Those in value stream (identified in the visual stream map)
  • Top down AND bottom up

     

We’ve discussed some specific and practical methods to use in order to kick-start and maintain momentum in an agile change program. The one thing we didn’t discuss is the tendency and temptation for people and teams to revert back to the old way of doing things.

My response to this when asked by executives and managers is to simply state that change starts at the top. While we all want to have a flat organization at times to avoid the challenges that come with hierarchy, the truth is that all enterprise companies need hierarchical structure to operate. Therefore, the degree that the leadership is involved is connected to the degree that success will come.

Practically, how can leaders ensure a culture of positive change using agile? They begin with incremental wins; applying these practices to a specific line of business before taking it across the company.

Being agile is more than a journey and a process; it is the behavior of the people that make up the company.