Monday, August 26, 2013

Using the Change Canvas to Illustrate Agile and Lean Change Patterns

Planning and managing changes using a Change Canvas has allowed our team to recognize a reoccurring set of agile change "patterns". Change agents can review these patterns when looking for a source of inspiration on how to structure the different elements of a Minimum Viable Change. We've represented these patterns using the Change Canvas, providing a visual and compact way to articulate and discuss the different aspects of these patterns. This is just an initial list, hopefully others will be able to add to the catalog over time.

The Quick Win

Agile and Lean transformation are at their greatest peril when they first start. Quick and tangible results are a great way to prove the case for larger more ambitious change efforts. Early success helps mitigate resistance from naysayers, and provide the organization with confidence to invest further and deeper.

The Quick Win is typically targeted at a small number of eager adopters such as what could be found in a medium-size team approximately 6-10 FTEs. No more than 1-2 managers and executives should be impacted at direct stakeholders. The idea is to make sure that the Quick Win is targeted at a small number of change recipients, and that those change recipients are capable of acting as a true guiding team and champion for larger change initiative.

The Quick Win should be targeted at solving a few immediate and tactical problems. Obviously, we are not looking at a strategic or long term return on investment, the value here is showing some kind of return within a month or two of effort.

The Quick Win should also be small in scope, adopting agile method, or perhaps a couple of closely related methods. Examples here include helping teams get started with Kanban or Scrum, or some Agile Modeling.

Commitment often comes in the form of some part-time coaching, a couple of days of upfront training, as well as the appropriate amount of time, perhaps no more than 6 to 9 weeks to learn the new techniques. Benefits of this kind of change include change recipients being successful at the new method as well as receiving some reasonable performance benefits in the short term. Success criteria is likewise measured in terms of the number of people who improve in relating capability, and could also be measured in terms of improved velocity, lead time, or quality.

The communication method should largely be in person, we want to support quick feedback, and potentially drastic changes in direction, this is harder to do when engaging with distributed teams.

Again, this type of change is typically considered earlier in the context of a larger agile transformation. We want to tackle resistance to an agile transformation through delivery of early value. This is a good way to validate an isolated component of a larger agile transformation. This type of change is also really good for validating adoption tactics, as well as determining if the relationship between commitments and benefits are remotely correct. Be ready to pivot on this point, as the effort to commitment is extremely hard to determine upfront.

Below is an example, a favorite Quick Win of ours improving business agility through adoption of the Kanban method.

The Kernel Pilot

After a number of Quick Wins have been executed within an organization, there can be enough momentum to execute a more ambitious change, one that more broadly reflects the organization's suggested true North. Previously implemented Quick Wins should have provided some validation on different aspects of the potential target state, adoption actions, and overall effort, reducing risk of attempting something a little larger.

A Minimum Viable Change using the Kernel Adoption pattern is typically targeted at an entire value stream, from intake all the way to support, and all the steps in between. Often this can be represented as one "line of business" of the organization. It is crucial to involve managers and executives, both from the perspective of capability management as well as issue escalation and resolution. The change should be directed against problems that are also drivers for the overall agile transformation, for the change to be truly valid, it should address most of the drivers behind the overall transformation.

The target state for this Minimum Viable Change should serve as a reference point for the desired state of the overall organization. Once this Minimum Viable Change is complete change recipients should be using new methods, possibly in a flatter, more network-based organizational structure, potentially leveraging new, wider role definitions.

Immersive coaching, facilitation, and even embedding experienced experts within delivery teams is often required to successfully help change recipients shift to new methods. As the choice of methods and techniques become stable, some effort can go into developing and socializing a light weight methods library.

The larger scope and scale of this type of Minimum Viable Change means that a bigger commitment is required. Our experience is that it can take anywhere from 3 to 6 months to execute, and may require 1 or even 2 full-time change agents.

Benefits come in the form of improved performance and improved capability, but also in the form of validation; the kernel pilot can be thought of as a beachhead for the larger organizational agile transformation, and is the first cohesive step into this new direction.

Again, it is often safer to implement a Minimum Viable Change based on the kernel pilot after one or more Quick Win style changes have been successfully executed, this will reduce the risk of adopting the wrong kernel.

As this change reflects the first time that different components of the target state have been adopted at the same time there will still be significant learning, expect to adjust on all elements of the canvas, and even pivot on the target state.

The relationship between commitments and benefits may seem off at this point in the transformation. This is because a significant amount of learning is still taking place, don't panic if a lot of handholding is still required at this point, optimizing the learning effort across the organization can take place later. Remember that the purpose of the change using this pattern is to try to get a first foothold on the overall target state of the organization.

Below is an example taken from our real world experience, where we helped the knowledge workers within one product delivery group to adopt a cross functional, co-located agile team model supported by a number of management, planning, and modeling methods. This agile "suite" was our suggested stack for the target state of the majority of the organization, and executing this change on a smaller group allowed us to refine the stack as well as the remaining assumptions within the change model.

Kernel Adoption

As one or more Kernel Pilot is implemented within the context of a single agile transformation, the transformation can evolve out of pilot mode and into adoption mode. An MVC following the kernel adoption pattern is less concerned with validating change solutions or change tactics, and more focused with trying to optimize the rate of adoption, converting a transformation from a high touch/high support approach to one that is more based on self-study, peer-to-peer sharing, and evolutionary improvement.

As an agile change is rolled out across the organization more effort can go into refining, publishing, and socializing training guides, methods, and other tools that can help knowledge and learning scale to a larger audience. Change agents should be spending more time training other members of the organization to be true change champions, agile knowledge experts, and owners of any methods or tools. High touch, in person coaching can now start to be graduated with other learning methods that can scale out to the entire organization including self training, online knowledge repositories, and communities of practice.

The target state for an agile transformation is never "done", so some aspects of the change solution will continue to require validation and potentially change in direction.

Self-Starter

a Minimum Viable Change modeled on the Self-Starter pattern attempts to provide an opportunity for change recipients to guide their own adoption. Various improvement methods such as training material, peer working sessions, scheduled times for change recipients to attend "tutor drop ins", and mentorship programs are used to allow employees and management to self select their learning pace.

Both new employees as well as those targeted for later adoption will require the means to educate themselves on how the organization is trying to deliver, sometimes long after an agile transformation is considered "complete".

A Self-Starter can also be useful in that it provides employees with permission to start moving to new approaches in advance of any "scheduled" adoption plan. The Self-Starter is also considered "safe", adoption takes place at the comfort level and pace of change recipients. Sometimes, curriculum and pull-based tutoring needs to be complemented with some kind of organizational incentives to adopt, this can be as simple as recognition for employees who have achieved a certain level of capability.

Supporting self learning can take more effort to set up initially, especially if new training material and/or capability models are not already available. Some internal marketing and finally a change recipients may also be required as the Self-Starter kicks off.

It's often recommended to support this effort with at least some kind of part-time tutoring which can be either scheduled or on an as needed basis. When supported properly, this kind of change scales well, and more than makes up for the initial effort. Besides providing the organization with the improved performance that comes with better capability, heightened morale can lead to better employee retention. A good Self-Starter program will continue long after the agile transformation is considered "over".

As stated previously a Minimum Viable Change following this pattern is better introduced later within the context of an agile organizational transformation. The overall approach and applicability of any particular methods should have already been validated thanks to one or more previous MVC's. Validation for a Self-Starter comes from testing whether employees within the organization can improve independently and "pull" help when and if required. Change agents should also be looking for ways to optimize the benefits gained compared to the commitments required.

The example below is taken from an agile transformation that I was a part of. Midway through the transformation it became clear that we did not have enough coaches to support the demand to assist various teams in adopting agile methods. We had already conducted a number of pilots across the organization and had enough training courseware and other material to support the notion of a self-starter. This will provide an avenue for employees who wanted to get started with agile but did not want to wait for dedicated coaching assistance.

This self-starter consisted of some guidelines and training exercises that would get them familiar with basic agile methods such as iterations, using user stories, and collaborative planning. We published this material to the corporate intranet, and announced a weekly 3 hour drop-in where anyone interested could receive coaching and assistance and have their questions answered relating to any of these techniques.

Capability Modernization

True improvements for many organizations will mean taking an honest look at current capability, methods, and techniques and revitalizing them to support business agility. A Minimum Viable Change following the Capability Modernization pattern is focused on improving delivery and/or management techniques for a functional capability within an organization. In more traditional organizations this often mean a functional department, in more modern agile organizations this will mean a collection of employees who can fit into a particular role. Examples include retooling all of the developers within an organization, or providing training and coaching on agile management techniques for all managers and executives.

A change following this pattern typically targets a larger set of change recipients, i.e. all employees that fit within a similar role (e.g. all testers). Any managers responsible for building capability for that role will also be similarly impacted.

Effort should be focused on building a number of "capability gurus" who can act as knowledge leaders and method owners of the new approaches.

Organizations tend to consider the Capability Modernization pattern when things are truly "broken", expertise across the function is considered to be legacy at best, and the current level of maturity is causing a noticeable and growing impact in performance and is having a visible impact on business outcomes.

The target state for this pattern is a complete refresh in terms of capability for that role, including career path, required skills, training and other tools and accelerators. This considerable investment may involve restructuring the organization from a more traditional specialist model to a more horizontal one, and rethinking how careers within the role can progress based on expertise.

A clear and graduate curriculum is often developed, and then introduced onto projects using a rolling wave approach. An effective approach can be to require that all training homework be conducted on real project work. A combination of hiring externals, as well as mentoring existing employees is used to help build a team of capability gurus. These capability gurus act as senior keepers of the flame, and are responsible for ensuring continued commitment to excellence and quality found in the best of agile organizations.

This type of Minimum Viable Change requires a lot of investment on behalf of the organization. Staff wishing to become gurus, need to commit the time required to master new skills to the point where they can train others. Girls need to be carefully selected, not everyone is cut out for this kind of dedication.

Methods and tools, and the training curriculum to support them need to be adapted to the context of the organization, and the training capability needs to be developed as well. This is also a significant investment.

Finally, deep and meaningful change in terms of adopting new methods will take time, this type of change will typically take months to execute. Several full-time, and senior change agents are often required to support this type of change pattern, and be change agents must have years of experience in the selected methods and techniques.

When this type of change is done correctly, benefits to this type of organization are significant. Improvements in capability lead to higher quality, which lead to significant and sustainable performance increases over time. There are no real shortcuts to improving delivery outcomes. Equally important, is that this type of change shows a willingness to invest in people's careers and in their capability, which improves morale.

In the context of a larger agile transformation, a change following this pattern should be done later, a number of Quick Wins, Kernel Adoptions, and even Self Starters should have already been introduced to the organization, providing feedback on what works and what doesn't. Large portions of the transformation will already been validated, key learnings from this Minimum Viable Change will come in the form of understanding how we can scale out the change to the rest of the organization.

A good example of this kind of change would be trying to achieve a state of "technical excellence" through adoption of methods that can be found within the software craftsmanship movement. This includes techniques such as test driven development, SOLID development techniques, continuous integration and continuous employment, perhaps even to adoption of some DEVOPS techniques.

Read More Lean Change - Chapter 3: Advanced Change Canvas Topics

Sunday, August 25, 2013

The Lean Change Method: 1000 Mile View

Why Lean Change?
There are number of key risks to any change initiative faces, the lean change method is an attempt to provide agile change agent with tools and techniques to help manage those risks.
Perhaps the biggest challenge any significant change faces is one of resistance. A combination of fear, resentment, and simple inertia causes groups of people to defend the status quo. This is especially true when) power, politics, and reputation are in question as is so often the case in large organizations.

Even when discounting resistance, many change initiatives install due to a lack of sustainability. Many change efforts start with a bang and ended with a whimper. This is because too much change is introduced to people too quickly, and becomes impossible to balance regular everyday workload with the demands of learning new techniques, methods, and values.

Finally, there is a very real risk that any suggested target state will most likely be wrong. Defining a "correct" target state and implementing it with a "correct" transformation plan often leaves us with a failed change. Running any type of organizational change is often like an act of war, and no plan will survive first contact. Initial assumptions about maturity, commitment, business context, etc. are very likely to be wrong. Following a change plan faithfully could mean that the organization is left with the change that nobody actually wants.

Lean Change Key Themes
The Lean Change method is an agile transformation approach designed to work in the context of these kinds of risks. There are 2 reoccurring themes that are central to all aspects of the method.
1: Negotiated Change
The concept of Negotiated Change is critical to the lean change method. He Negotiated Change approach demands that recipients of any change are co-authors and coal implementers of all aspects of the change or transformation that they are part of. Designated change agents, change stakeholders, and change recipients act as change co-creators, ensuring that suggested changes get the buy-in necessary to ensure that they are successful.

Validated Learning
Because the outcomes of any organizational change initiative is unpredictable, relying exclusively on upfront plans is an exercise in futility. But the caveat here is that any successful initiative requires some sort of planning. The trick here is to balance planning with a feedback rich learning system that can inform all change stakeholders whether a particular change is working or Not. The lean startup method has been a source of inspiration for applying a concept known as Validated Learning.

Validated learning provides an innovative way for knowledge workers to create value in a highly uncertain world. In the lean startup world, product developers are asked to describe features, plans, and other components of a sustainable business as a set of un validated assumptions, they are then scientifically validate those assumptions using a scientific method. Assumptions are described as hypotheses, and then systematically tested to see if those hypotheses, true or false.
Lean Change advocates that any change plan and change target state model also be described as a set of assumptions, and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses. People familiar with the lean startup method will recognize many of the components that we have adapted from this method, making them more suitable for organizational change.
Lean Change Requires Kanban (or Possibly Scrum)
Lean Change provides a method for change agents to execute a planned change initiative, but using a cocreative, collaborative, and learning oriented approach. The Lean Change method does not attempt to replace existing agile improvement techniques, but rather it acts as an overlay to help change stakeholders coordinate and guide suggested improvements.
For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities. This information can be fed from change recipients into the Lean Change method to help navigate the change initiative.

Either scrum or Kanban could be used as this improvement method. Most Lean Change implementations that we are aware of have elected to use Kanban as the improvement method of choice, and then eventually evolved to adopting some elements of scrum that matched their requirements. That being said, it would be very interesting to learn about any case studies that elect to use scrum as the agile improvement method of choice to integrate with Lean Change.

The Lean Change method is a cocreative agile change management and planning approach. Many components of the method had been taken from the lean startup approach, and adapted so that it is suitable for change agents trying to help organizations become more lean and agile.
A Quick Look at the Lean Change Components

Change Canvas
Borrowing a technique made popular by the lean startup community, design and planning is facilitated using a canvas. One of the most foundational pieces of the Lean Change method is the use of a Change Canvas to describe and communicate an agile change plan.

The canvas is an informal "plan on a page", and is a technique that innovators have been using to iteratively design and implement new business models and startups. The lean change method uses the change Canvas in two ways, a MVC canvas describes a small incremental change in data small number of employees, while a transformation canvas describes an organizational transformation initiative. In most cases, when I use the term change canvas, I'm speaking about a smaller change such as an MVC. Often the terms can be used interchangeably, when speaking about canvases used to model larger transformation, you'll see the term transformation canvas being used.

Minimum Viable Changes
The Lean Startup method advocates delivering market facing value in the smallest possible increments that enable learning about whether a particular startup has a sustainable business model. These increments are known as the Minimum Viable Products or MVPs for short.
In the Lean Change method, change agents are encouraged to roll out the smallest possible change that will enable learning whether a particular change will provide sustainable improvement. These increments are known as a Minimum Viable Change, or MVC for short.

Validated Change Lifecycle
Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle. We have defined this lifecycle to maximize the change agents ability to accelerate negotiation and learning necessary to creating a successful change.

Capability and Performance Metrics
Lean Change also provides a number of ways to measure the impact of specific changes. This impact is looked up from a couple of perspectives. The first perspective is the ability of change recipients to adopt, and ultimately excel at new agile and lean methods and techniques. The second perspective is the impact of these techniques on actual delivery performance and value.

Cadence Model of Suggested Meetings and Workshops to Facilitate Large-Scale Agile and Lean Transformations
Managing a large-scale agile transformation can be challenging, so the lean change method provides a model that suggests different meetings and workshops to handle prioritization, communication, status, and overall communication.

The Lean Change Method Is Modular, Components Are Usable In Isolation
The Lean Change method is designed to be modular, change agents can elect to use some of these components and ignore the others, For instance using a canvas to co-create a suggested change with change recipients without using the lifecycle or measurement components is a great way to get started with the Lean Change method. Likewise, we have seen change agents create minimum viable changes and follow the Lean Change lifecycle, without using the canvas or using a modified version of the canvas.

I'm hoping that the Lean Change method can be useful to other change agents whether they be consultants, managers, or staff. I will continue to provide details on each one of these components in future posts.

Check out the Rest of Lean Change - Chapter 1

Wednesday, August 21, 2013

Exploring Different Method Plug-Ins for Completing A Change Canvas - Part 5 Communication

One of the most overlooked aspects of any change initiative is the need to communicate with all members involved. This includes people directly affected by the change, as well as sponsors and other stakeholders who may be directly impacted.

Poor communication is often cited as one of the biggest reasons that change initiatives fail.
A good way to start is by understanding how you want to vacation to flow to your direct change recipients as well as the other affected sponsors and stakeholders. Simply tracing how the information should be passed using a simple notation should be sufficient.

Different communication channels can be bidirectional meaning that feedback and response is expected from the receiver of the condition.

As well as unidirectional meaning that up to vacation will be broadcast out to a larger audience.

when completing our change canvases we have often expressed the various communications that will be processed using a cadence model. Using this approach we can express the time interval that various communications will be sent out during the lifetime of the change initiative.

communication channels that we've used in the past include

status meetings where we review progress of the change initiative often with stakeholders, sponsors, and folks were not necessarily directly impacted by the change

intranet/Web communications that are sent out both the change recipients as well as the rest of the organization. Another alternative to this is an internal blog and or wiki which makes this a bidirectional channel.

as well as the use of information radiators, such as posters, dashboards, and other highly physical artifacts that are placed in such a way as to attract maximum attention from both change recipients as well as other members within the organization.

It should be noted that agile visualization systems such as Kanban and agile card walls are themselves great communication channels for a change initiative. We probably can't count the number of times that somebody has walked by Kanban style visualization system and in suitably impressed enough to want to become a change recipient for the next change within the organization.

Read More Lean Change - Chapter 3: Advanced Change Canvas Topics

Monday, August 19, 2013

Lean Change at Agile 2013

Recently I did a presentation at Agile 2013 based on an experience report of our experiences in running large-scale agile transformations and the solutions we have developed to become more successful at them. Over the years, our clients have gotten good successes with their agile transformations but we always felt that the approach could be improved. The key challenges we commonly encountered were that taking a plan driven approach to agile change is hard if not impossible due to the unknowns, complexity and variability inherent in organizational change. Instead of choosing to take a predictive approach we decided to be more "agile" for how we do "agile transformations" and borrowed a page out of Lean Startup. Jeff Anderson has been busy building out a set of blog posts on our approach called Lean Change. To help others understand the thinking behind it and the framework at a high-level, here is the presentation from Agile 2013:

http://www.slideshare.net/AlexisHui/agile-2013-lean-change-for-enabling-agile-transformations

Tuesday, August 13, 2013

Exploring Different Method Plug-Ins for Completing A Change Canvas - Part 4 Benefits & Commitments

The main sections of the change canvas are meaningless unless all stakeholders involved in the change can successfully make the commitments required to achieve potential benefits. These two sections can be thought of as being balanced with each other, and supporting the remaining sections within the change canvas.

Commitments

Use the commitment portion of the canvas to track what is required from all involved to make a change successful.

Change recipients and change agents are required to meet the commitments specified within the canvas in order to realize the benefits that will be achieved from getting to the target state.

Interestingly the commitment section of the canvas is often the most important one to change recipients. One of the most focal point of resistance to any agile or Lean Change initiative is that change recipients are too busy to take the time to think about improving the way they work. The best way to tackle this concern is to hit it head-on, defining what commitments change recipients can actually make, and then tweaking the rest of the canvas to take into account the available resources.

Commitments come in the way of locating spaces for agile teams or dedicated meeting rooms at specific times to run workshops and classrooms.

commitment can also come in the form of hardware, software and other tools that change recipients may not currently have access to.

Often the most contentious form of commitment comes in the form of time required to learn, practice and accelerate in new methods.

At a minimum is critical to capture an estimate of how much time is required for each change recipients of a particular change. have noticed the change recipients are more willing to give more of their time if this commitment can be tied to specific benefits that will make their lives easier.

On occasion we have found it necessary to provide a more elaborate picture of how particular change will affect people's schedules. The calendar type view can be used to show when all meetings are taking place, how long they will be, and who is required to attend. While this might seem overkill, we have found that this type of illustration helps reduce churn when negotiating a change model with change recipients.

Continuing our previous example, we've illustrated our initial assessment around the time commitment required to help this team gain proficiency in agile modeling and requirements.

Benefits

A successful change initiative will result in benefits received by change recipients

Use the benefits section of the canvas to articulate what benefits change recipients will receive as a result of committing to the actions required to make the team successful.

Benefits listed in the canvas can be both qualitative, as well as quantitative.

Types of benefits that could be listed on the change canvas include improved customer perception. Listing this benefit takes some courage on about half of change recipients, they are signing up to definitively improve the way their customers feel about the way they work. We think this is an ideal outcome for trying to pilot new methods, it makes a bold statement that no success is meaningful unless the customer experience is improvement.
Borrowing another page from the mean startup method and metric known as net promoter score could be used to track both current and expected customer perception.

Team performance is also something we have commonly used on our campuses. Change recipients who are using more classic agile methods such as from scrum and extreme programming can try to quantify benefits in terms of velocity using burn down charts, and other metrics such as how often teams are able to meet their commitments.
Change recipients using more lean inspired methods such as Kanban can try to quantify performance improvements in terms of throughput and leadtime, leveraging cumulative flow and fiscal process control charts, as well as other metrics such as how often a team is able to meet its service delivery performance promises.

Trying to articulate the exact impact on performance they change initiative will have is a highly subjective art at best. We have seen teams using Kanban report drastically different throughput performance improvement outcomes ranging from 30% to a whopping 200%!

Our team has also seen teams improve their performance up to six times over the lifecycle of a project in A large part because they had the chance to gel, and collaborate effectively.

our team has also noticed that the unit of measure, whether it be user stories or features, tends to change in size and effort once it's been measured. Teams that measure their performance often start trying to shrink their user stories to a small they can be while still delivering business value, this alone has a dramatic impact on performance.
What this means is that implementing a change on anything but a very stable team any quantifiable perform improved you suggest will be a guess.

We still think that specifying performance improvements is a good thing to Do for many change canvases, especially when trying to adopt a method on the team. Without this business valued promise of improvement, it can be hard to get the buy-in necessary to make any type of reasonable change to the way people are working.
We think the best number to specify is on the aggressive side of conservative. Specifying a number close to 80% improvement in either defect density, leadtime, or throughput/velocity is achievable for most change recipients that we have encountered, and is also large enough of a number to generate interest in the change itself.

Benefits can also be described in terms of improved capability of the change recipients. While this can be expressed in numbers, this is really a qualitative benefit. One way to do this is to simply express the number of change recipients who have achieved capability in a certain skill.

Capability could be expressed in terms of a graduated ladder, or if desired more complex capability model could be designed to support the change. In this case, capability benefits could be described as the number of folks reaching a certain level within the capability model.

Looking at our previous example, we can see our assumptions around benefits both from a performance as well as capability perspective as a result of executing this change.

Read More Lean Change - Chapter 3: Advanced Change Canvas Topics