Lean Transformation: A Lean Change Comprehensive Example - Part 1 Agree On the Urgency of Change

In the next several posts I'm going to provide an example of how the Lean Change method can be applied. I'll showcase the various techniques and practices in one integrated case study. This includes using the Change Canvas to represent a Minimum Viable Change, and using the Validated Change Lifecycle to define, validate, and finally re-factor a change plan based on the outcomes of a number of Improvement Experiments. Various methods and techniques that can be used to explore a Change Canvas, such as value stream mapping and value network design are also included in this example.

To begin we will showcase how a Minimum Viable Change passes through the Agree on Urgency state.

Charlie the Change Agent Has a Job to Do

Charlie is an agile coach whose responsibility is to help employees within his organization be more successful through the use of lean and agile methods and values. Charlie has been asked by the CIO of the organization to have a look at the application maintenance team. The maintenance team is responsible for supporting a complex, distributed solution that provides mission-critical functionality for the business. The team is having numerous challenges and business customers are starting to complain. Charlie is tasked with helping the application maintenance group improve their delivery performance.

Charlie marks down Some of His Thoughts on a Change Canvas

Charlie begins by taking a stab at putting together a Change Canvas to represent his first thoughts on what a MVC could look like. Charlie has worked for the organization for several years and has an idea of some of the problems that the application maintenance team is facing.

The application maintenance team is infamous for its reputation for poor collaboration both within the team and with its business customers. There is also a perception across the organization that the delivery is really slow, and leadtimes are incredibly long. Even when things are delivered, customers continue to complain about quality, and the defect rates of this group are amongst the highest within the organization. Charlie marks these challenges within the Urgency section of the canvas.
Charlie knows that both Business Analysts and developers are assigned to the application maintenance team, so quickly notes them in the Change participant section.

Charlie feels that a lack of "team culture" and bad practices are a major source of problems for the application maintenance group. Charlie feels that restructuring the group according to an "agile model", one that is co-located, and comprised of full-time dedicated members, will help to kickstart a more collaborative culture. Charlie also feels that the team will improve their capability to deliver through the adoption of agile style story analysis techniques, along with agile planning methods such as physical card walls. Charlie places these three concepts into the target options section of the Change Canvas. He likewise writes down a vision of an agile team in the Vision section.

Charlie quickly jots down his initial thoughts around Actions and Commitments, some upfront training, along with some occasional coaching, and various meetings. The one big commitment Charlie has placed is the need for a dedicated Product Owner, something that does not exist in this organization.

Charlie Then Validates His Thinking so Far

Charlie places two Improvement Experiments onto the Improvement Kanban system next to the Change Canvas for his MVC. He is hoping to be able to validate that his urgency and change participant sections are correct through a single workshop. He's also hoping to find somebody within either the application maintenance team or the business customer group who would be willing to play the Product Owner role. He doesn't want to spend more than one weeks searching for a candidate. He prepares some workshop material, schedules his workshop, and is ready to run the workshop to go over the Canvas.

Charlie moves his Improvement Experiments through the prepare column, and then into the introduce column. In parallel he also prepares a job description for the Product Owner, and starts scheduling meetings to see if he can find anybody interested in taking on this role. He likewise moves this ticket through prepare and then introduce.

Unfortunately, both of these improvement experiments turn out to have assumptions that are incorrect.

When speaking with the application maintenance team, he gets very little agreement that delivery times are actually slow. He can also only get partial agreement from some team members around the issues of poor quality and lack of collaboration. Workshop attendees also point out that he has not included everyone who is involved in the application maintenance effort.

Since Charlie has gotten both the urgency and change participant sections wrong, the rest of the Change Canvas is basically invalidated. Charlie needs to basically go back to the drawing board.

Charlie Conducts Some Deeper Analysis to Understand How the Application Maintenance Team Functions and What Their Problems Are

Charlie suggests to the application maintenance team that they spend more time understanding the current context of this team. He suggests running a number of value stream mapping sessions with the goal of coming up with a more accurate set of change participant and key problems within a two-week period.

Charlie prepares and schedules the workshop and then moves a new Improvement Experiment through the prepare and introduce states.

Charlie Is Now Ready To Take A Second Crack At The Canvas

After several sessions Charlie is able to come up with a reasonably accurate value stream map, outlining major activities including who is responsible for specific tasks.

He is able to get good agreement on specific challenges relating to each step within the process. The value stream map shows a number of these problems, ranging from:

· a nonexistent prioritization mechanism where diverse stakeholders (known as Line of Business Representatives) basically shout over each other to get resources, causing conflict in demand, and a lot of stop/start work

· a perception of ivory tower analysis causing the Business Analysts to be bypassed by Business LOB Reps.

· Developers are really system specialists, and work largely in silos, severely impacting quality down the road

· a UAT function that was not capturing quality problems, resulting in production bugs being unusually high

· the Business LOB Reps, who are tagged as having business subject matter expertise, have little real knowledge of the inner workings of the solution. The real knowledge is possessed by a diverse group of Operational Experts, the real users of the system. The Business LOB Reps. almost always delegate business-related questions to these Operational Experts.

Charlie is also able to get a good handle on which roles are impacted by these problems, taking time to speak with members from each of these departments to get their input.

Charlie now has a better handle on the makeup of the application maintenance group.

Charlie lists a core set of Change participants which include Business Analysts, developers, and the Operational Experts. He also adds the business representatives but puts them at the bottom of the section to indicate that they are secondary change stakeholders and not core members.

Rather than listing all the problems from the value stream map on the Change Canvas, he summarizes two major points in the Urgency section. First of all, the distributed nature of the team and unclear expectations around responsibilities is contributing to an environment of poor visibility and no understanding of who gets to make what decisions. Secondly, there is a growing demand of production related defects mainly because issues are not getting caught in UAT where they should be caught in the first place.

Charlie updates the Action section to reflect the team's desire to have more support than he initially estimated. He also updates the Commitment section to reflect the need for 1 day of coaching for the duration of this change.

With the Canvas updated, Charlie moved the we do /next value stream improvement experiment into the learn column, marking it as a success.