Tuesday, September 3, 2013

Success in Today's Economy Requires Supplanting Traditional Management Thinking with Lean and Agile

Traditional IT Management Methods Borrow Much of Their Thinking from the John Taylor School of Thought

In the 1930s, this philosophy was based on the premise that organizations would be much more efficient if resources organized by specialization. This would allow functional oriented departments to focus on efficiency through highly standardized and repetitive activity.


Activities were planned and coordinated through the use of functional managers who ensured that individual employees receive adequate instruction and feedback on performance targets. Managers got their orders from executives who are responsible for determining the objectives of the organization.

In this approach, big ideas came from the executives and owners of the business, who determined what the organization should be doing and how it should be doing it. Managers were responsible for ensuring successful execution of plans. Individual tasks and activities were doled out to employees, and all coordination between functional departments required intervention by the management layer.
clip_image002

The majority of employees were essentially cogs in a well-orchestrated machine; they did the work and were not required to perform any meaningful thinking.
clip_image004

Scaling out an organization simply required the addition of another functional layer. Organizations could successfully increase in size by expanding out horizontally and vertically, creating a more nested hierarchical structure.
One reason this approach works well is that managers and leaders were able to optimize the execution of highly specialized and repetitive tasks. This allowed workers to leverage economies of scale, lowering total cost of ownership for both in process and complete inventory of goods.
clip_image006


 

This Traditional Thinking Is Suited to a Previous Era, One of Economic Scarcity

Traditional management methods were well suited to times of economic scarcity.
clip_image008

Success relied on maximizing efficiency and providing goods and services to customers at the lowest possible cost.
clip_image010

This low cost was achieved through a command -and-control approach, meticulous planning and coordination, and the development of robust standards and procedures that carefully lay out the most efficient way to complete a particular task.
clip_image012

Work was organized to leverage economies of scale; specialists were grouped together into functional
Departments, highly repetitive activities would be completed in large batches, and passed from one specialist group to the next. Customer demand was serviced in large quantities, again using a big batch approach.
clip_image014
 


In a market where customer wealth was low, this approach effectively serviced customer demand. Economies of scale were easy to leverage, as a small number of products could be introduced to a large and undifferentiated customer market. Product lifecycles were also extremely long, taking years or sometimes even decades before one product would be displaced by innovation.

clip_image016


Today's Business Environment Requires a Radically Different Approach

For many organizations today, market success is achieved through offering differentiated products and services to customers who can and are willing to pay a premium for the latest innovation.
clip_image018
 
In this environment, organizations can be incredibly efficient, follow plans to perfection, and be incredibly effective at coordinating thousands of specialists but still fail as a business.
clip_image020
 
In today's challenging business environment, the biggest risk has shifted from building products cheaply to building a product that nobody wants. To borrow a term from the lean startup community, the question becomes not "can I build it, but should I build it?"
clip_image022
 
Successful enterprises no longer provide a one-size-fits-all offering to their customers. Instead differentiated products and services are made available to a variety of well researched customer segments, in some cases products are offered as platforms to be uniquely customized to the individual end-users needs. Product lifecycles are now much shorter, with obsolescence coming in months, weeks, and even days.
clip_image024
 
In situations where organizations are still providing more commoditized goods and services with longer life cycles huge efficiency gains can be leveraged by taking advantage of the latest wave of technology innovation.
clip_image026
 
In this environment speed of execution becomes more important than cost of execution, and processes, organizational design, and management methods need to be designed to support speed.
clip_image028
 
The most fundamental change between traditional management methods and ones that leverage lean and agile methods is the shift from plan driven processes to learning driven processes. In an environment where customer demand as well as the tools used to service the customer demand are constantly shifting long-term plans, static processes, and economies of scale will work against you. Instead, organizations need to be designed to manage feedback, and be able to adapt to constant change.
clip_image030
Agile and Lean Provide a Vision for Success in Today's Complex, Customer Driven World
Lean and agile are concepts that cover a variety of principles, methods, practices and perspectives. Different approaches have unique and sometimes contradictory perspectives. Nonetheless there are some fundamental differences between how an agile or lean organization operates anyone using more traditional management methods.
Perhaps one of the most important characteristics is achieving business agility by creating a frequent feedback loop between the customer and the supplier. Agile methods do this by delivering work in short iterations, where working software is delivered in iterations that last between one week and one month. Organizations following a lean approach achieve this feedback using a just in time, pull-based approach, one that limits work in process to the organization's capacity.
clip_image032
 
This feedback loop provided by frequent delivery enables the organization to continually learn based on the success of the last delivery. This feedback allows organizations to delegate the majority of decisions to the team level without fear of the organization slipping into dysfunctional behavior.
Teams are better able to learn, and better able to deal with complexity when they are made up of a diverse set of individuals. Most lean and agile methods recommend that teams are truly cross functional and contain the majority of skill sets that are required to consume customer demand and create a finished product.
clip_image034
This diversity of skills within the team enables it to adapt and learn as necessary to process new and constantly changing customer requirements. In the modern economy no two customer requests are exactly the same; this is especially true for technology related work. A truly cross functional team will ensure that its members are able to maximize the chance of them making the correct decisions required to successfully deliver on diverse customer demand.
This leads to another key principle in both the lean and agile world. In this model workers are responsible for both doing the work and coming up with the good ideas around to complete the work. All team members are encouraged to be thoughtful about what they are doing, and challenge why things are being done a certain way, or why they are even being done in the first place. In this paradigm, workers are self-empowered and the teams are largely self-managed.
clip_image036
Because feedback is critical to enabling this learning system, work is deliberately processed in small batches. The whole notion of economies of scale is discarded in favor of working with the lowest possible level of inventory. What this means is that workers are encouraged to work on only a one or two business value tasks at a time, and work those to completion rather than trying to stay busy by working on many things in parallel.
clip_image038
Frequent client delivery, cross functional teams, empowered workers, and limited work in process all contribute to a system of continual self-correction and learning. Knowledge workers are able to get better insight into what customers want, but also learn how to optimize their internal methods, tools and processes to improve their own internal efficiency, speed and quality.
Another key difference is the way they lean and agile teams look at quality, processes, and standards. Workers in this environment need to be constantly learning, and adapting.
Poor quality interferes with this learning cycle. Both lean and agile methods recommend that quality be built into the process, rather than expected for after-the-fact. Whenever a problem in quality is found, root cause analysis is conducted to get you the source of the problem not only to fix it, but to make sure that it never happens again. Processes and standards are constantly changing and evolving based on the insight gained through discovering quality problems, performing root cause analysis on those problems, and implementing countermeasures to ensure that those quality problems do not happen again.
clip_image040
 
Many agile and lean methods recommend the use of information radiators to share information across the team, with management, and the customer. Information radiators often come in the form of Kanban systems, agile card walls as well as simple low fidelity dashboards and charts
clip_image042
 
The current body of agile and lean thinking has found expression in many forms, including a variety of principles, methods, and specific practices that provide guidance, inspiration, and advice for those wishing to operate successfully in a complex market taking advantage of self-organization, feedback and learning, frequent customer delivery, and excellence.
clip_image044
 
Organizations can scale by organizing teams into a value network. This value network typically employs peer-to-peer communication enabled by specific key members belonging to more than one team. The notion of teams actually being a set of overlapping concentric circles is a good metaphor. For the most part teams within a value network should be cross functional, having workers who possess diverse skill sets and perspectives.







Occasionally teams within a value network will be comprised of a single specialization, similar to the model found in the more traditional management methods. The specialist approach may be chosen when there is no stable demand for a specific skill set in any of the cross functional teams. This approach is also effective when communication requirements between specialists of the same skill set tends to be higher than those across skill sets. Functions like enterprise architecture, security, and infrastructure provisioning often remain in Click publish the specialized teams.

Check out the Rest of Lean Change - Chapter 1
  1. Why Today's Technology Organizations Need to Change
  2. Challenges with Current Organizational Change Methods
  3. Presenting the Lean Change Method

Techniques to Keep in Mind When Building a Change Canvas

Keep the following techniques in mind when using the change canvas to help execute an agile or lean change plan.

Plan Change in a Cocreative Way
Perhaps one of the most important considerations when building a change canvas is to make sure that it's done in a cocreative fashion. You want to ensure that change recipients, and other change stakeholders work closely with change agents to come up with a change solution together. The canvas supports a collaborative environment, but it is up to the facilitator and workshop participants to take advantage of this tool. Below is a great example where we worked with our client to brainstorm a potential change.
clip_image002
Expect Your Change Plan to Be Wrong
The change canvas is easy to build, easy to modify, and easy to tear down if it turns out to be completely wrong. It still takes a combination of courage, introspection, and discipline to take the time to modify elements of a change plan when we discover that they are incorrect. Change planning is really hard to do, and most assumptions behind any initial change model will never be right up front. Expect the change canvas to require revision and require it frequently. Shown below is a minimum viable change canvas annotated for correctness. The change team's latest learnings have been incorporated into the canvas, showing red for incorrect assumptions, and yellow for only partially correct assumptions.
clip_image004


Use the Change Canvas As an Information Radiator
Where possible, try to favor representing the change canvas using physical, low fidelity artifacts that can be placed in a highly visible place, frequently trafficked by members of the organization. We want to encourage maximum exposure to our change model and plan, and receive the maximum amount of feedback from as many sources as possible.
clip_image006


Keep the Content of the Canvas Light Weight and Informal
While the change canvas contains all the components of a complete change model, content within the canvas should be succinct. We want to avoid getting lost in the details, providing key information at a glance. Things need to be lightweight if we want to be able to make changes as we incorporate new learnings over time. The canvas shown below may look chaotic and unfinished at first glance, but in reality a wealth of information is conveyed, and can be collaborated on in real time.
clip_image008


Limit How Much Change You Introduce at Any One Time
When decomposing a minimum viable change into a number of improvements experiments, it is important to limit how many of these improvements experiments you introduce to the organization. It is very easy for change recipients to become overwhelmed with change. Negotiate a reasonable work in progress limit that balances the need for improvement with actual capacity for change within the organization. The minimum viable change on the canvas below has an agreed-upon change in process limit to 3 experiments every two weeks.
clip_image009

Place the Change Canvas As Close As Possible to Where Change Recipients Work
As soon as a change canvas is started, place it as close as you can to wear most of the change recipients work. This encourages change recipients to look at the model in their own time. We also want to encourage ownership of the change model by these change recipients.
clip_image012



Think Visually, Use Pictures to Enhance Communication
Because the canvas is compact there isn't room to write a lot of detail. But a simple picture can convey a lot of meaning. Artistic excellence is not required, simply the willingness to put things down in picture form using whatever skills are available! Below is a real-world example where our client used some visual thinking to help articulate the vision for their department.

clip_image013



 Read More of Lean Change - Chapter 2: Getting Started with the Change Canvas 
  1. a Short History of the Canvas 
  2. the Change Canvas in Action-a Story of Danny the Developer
  3. Using a Canvas to Represent a Minimum Viable Change 
  4. Guidelines and Practices When Using the Change Canvas

Saturday, August 31, 2013

Modeling an Enterprise Agile Transformation With a Transformation Canvas

In previous posts I've talked about how to complete a change model as expressed by a Change Canvas. The focus of these posts have been on using the canvas to define Minimum Viable Changes, and also how validate those changes using the Validated Change Lifecycle; first through discussion, then by checking behavior, and finally by checking performance.

I've also discussed how to use the Validated Change Lifecycle to order the kind of actions and experiments we want to execute in order to de-risk our change program.

The type of change that we have been talking about so far, has been at the team or department level. However, we can also use the Change Canvas on a very different scale, to support planning for large-scale organizational transformations. When using a Change Canvas this way, we call it a Transformation Canvas. The Transformation Canvas can help senior executives who are looking to rewrite the Cultural DNA be any of their entire organization, and want to execute large-scale change across the enterprise.

Why Do We Need a Transformation Canvas?
as a quick review of how lean change work so far, change agent can work with a group or cohort of change recipients to execute a set of improvements experiments as a Minimum Viable Change.
clip_image002

A Change Canvas is used to reflect all the components of the minimum viable change, and that canvas is then validated first through discussion, then by checking behavior, and finally by checking performance.
 clip_image004
Change agents can de risk and maximize learning for a change by moving Minimum Viable Changes through the validated change lifecycle.
clip_image006
As a change program scales out, multiple change agents may work on multiple Minimum Viable Changes can in parallel, effecting numerous changes on an organization.
clip_image008
Different change agents will come up with different solutions to the unique problems of the change recipients they are working with. This can be considered a good thing, different groups of change recipients will often require different solutions that match their context.
clip_image010
However, taken to the extreme, executing different changes in different parts of the organization can result in a solution that doesn't make sense or work very well as a whole.
clip_image012
Different lean and agile methods place emphasis on different things, and even may contradict each other in the advice they give. Without care change recipients and other chain stakeholders can become confused.
clip_image014
Change Agents working on an organizational transformation, one where a larger number of Minimum Viable Changes will be introduced to the organization, should spend some time on planning and modeling what a transformation can look like from the perspective of the entire organization. Just like a Minimum Viable Change, elements that make up the model for a transformation level change can be thought of as assumptions that can validated through experimentation.
clip_image016
An organizational transformation model can be used to ground and otherwise constrain the various minimum viable changes that pass through an organization. When a change agent begins work on a new minimum viable change the first point of reference is the organization organizational transformation model. Does the minimum viable change fit within the overall objectives of the organizational transformation?
clip_image017

A Transformation Canvas Models the Elements of an Enterprise/Organizational Transformation
Just like a Change Canvas can be used to model the elements of a Minimum Viable Change, a change canvas can also be used to model the elements of an organizational transformation. We call this type of Change Canvas a Transformation Canvas.

The main difference between a Transformation Canvas and our previously discussed Change Canvas is one of scope, a Change Canvas used to model an MVC is concerned with improving the lives of a particular segment of change recipients within an organization.

A Transformation Canvas is used to model the concerns of either the entire organization or very large subset of an organization undergoing a transformation.

A Transformation Canvas can be validated through the implementation of one or more Minimum Viable Changes.
clip_image019
When using the Transformation Canvas this way, you're asking change agents to take part in a two tier, hierarchical planning process.
At the top layer an organizational Transformation Canvas is designed, and a suggested set of Minimum Viable Changes are prioritized using a Kanban style backlog.
As change agents become ready to work on new Minimum Viable Changes, Change Canvases are defined and validated through improvements experiments.

Using this approach feedback trickles from the lowest level, learning from Improvements Experiments impact the validity of elements on the MVC Change Canvas, and changes to various MVC Change Canvases impact the Transformation Canvas, and thus cause change to the transformation.
clip_image021
Shown below is an example of the transformation canvas. It's very similar to a regular change Canvas only larger, content is also geared towards discussing an entire transformation.
clip_image023 .



Read More Lean Change - Chapter 5: Using a Transformation Canvas for Enterprise Change
  1. Understanding Why We Need an Organizational Transformation Canvas
  2. Applying the Change Canvas to Transformations
  3. Mitigating Change Risk through Traversing the Canvas
  4. Prioritizing Different Minimum Viable Changes Based on Risks on the Organizational Transformation Canvas

Validated Change Lifecycle State 3: Validate Adoption

When entering the Validate Adoption State of the Validated Change Lifecycle, we are now ready to validate the change by measuring what people actually do, and how they actually behave. During the previous two states of the validated change lifecycle, validation occurred through discussion. Change agents would test the change canvas by measuring how change recipients reacted to different sections of the canvas.
clip_image002

It's important to note that during this state, measurement and validation is still largely qualitative. While we can use numbers to measure how well people are improving in new methods and techniques, experience and judgment will still play the largest role in validating any assumptions behind the change model.


clip_image004


The primary purpose of the validate adoption state is to determine if change recipients are able to adopt new behaviors, techniques, and working culture related to lean and agile technics. It's important to focus on adoption first, and give people chances to get used to new methods before focusing on looking at performance or other business outcomes.
clip_image006

One of the first things a change agent should do during this state is to work with change recipients to come up with a backlog of improvement experiments. These improvement experiments should be designed to validate that specific actions taken by the change agent will result in improved capability and adoption of specific agile techniques.

Good improvement experiments will also be validated against a specific success criteria listed on the change canvas.
clip_image008

Our team has had good success using simple agile and lean capability models, tracking a number of capability dimensions for particular set of change recipients. Improvement experiments can be designed by creating a hypothesis that Outlines how a set of change activities will result in improvement on some dimension of the capability model.
clip_image010
It is extremely important that change recipients take an ownership role in measuring the effectiveness of a particular improvement experiments, change agents should act as facilitators, and almost never interfere with the teams self-evaluation.
clip_image012

It is also crucial to make sure that teams do not feel like they are being judged or evaluated by any type of external authority, the use of capability models is especially prone to misuse by management. Teams need to feel safe to learn at their own pace, and not get into capability competition with other teams. The point is to make sure that we can validate assumptions behind how much effort is required to help teams adopt new techniques, and to collaboratively adjust any of these expectations if they turn out to be false.
clip_image014

Again our experience tells us that understanding the relationship between the commitment required for change recipients to truly adopt new techniques is extremely hard. This effort is often vastly underestimated, and is usually the source of the first pivot required to realign an agile change program.



clip_image016 

Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle
  1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
  2. State 1: Agree on the Urgency of Change
  3. State 2: Negotiate the Change
  4. State 3: Validate Adoption
  5. State 4: Verify Performance
  6. Realizing a Change Canvas through the Validated Change Lifecycle
  7. Instantiating the Lifecycle Effectively Using Information Radiators

 

Friday, August 30, 2013

Presenting the Complete Lean Change Method

Transforming your organization to agile is hard. Too many lean and agile change initiatives fail

Many traditional "Big C Consulting" change management methods rely on upfront design, fixed plans, and disruptive overhauls that result in change resistance and can decrease organizational performance. Many organizations have challenges in getting existing agile improvement methods, such as Kanban and Scrum, to work as prescribed.

A Startup Is a Really Good Metaphor for Agile Change Initiatives

Lean Change is a change management method that provides change agents with a dynamic planning and execution framework. Lean Change is based on the metaphor that any agile change initiative can be thought of as a startup. Borrowing many principles and techniques from the Lean Startup method, change agents are able to keep the change plan and model relevant by incorporating the latest learnings obtained from on the ground adoption.














Lean Change integrates the "Kotter 8 steps of change" with validated learning to provide change agents with a systematic approach to mitigating common risks encountered during agile/lean transformation; including resistance to change, correctness of change, and sustainability of change.










All aspects of the Lean Change method are designed to be cocreative, enabling change agents, change recipients and other change stakeholders to negotiate their way through a communally owned solution. All change participants learn their way to a successful change outcome.

Lean Change Is Now Ready As a Consumable Method

I have posted a large number of articles around Lean Change,  all of these articles tie together in an overall story that I hope to publish one-day. I have put together a quick table of contents, hyperlinking to the relevant articles where they exist. As always please feel free to provide some feedback.

Chapter 1: the Case for Lean Change
  1. Why Today's Technology Organizations Need to Change
  2. Challenges with Current Organizational Change Methods
  3. Presenting the Lean Change Method

Chapter 2: Getting Started with the Change Canvas 
  1. a Short History of the Canvas 
  2. the Change Canvas in Action-a Story of Danny the Developer
  3. Using a Canvas to Represent a Minimum Viable Change 
  4. Guidelines and Practices When Using the Change Canvas

    Chapter 3: Advanced Change Canvas Topics
    1. Using Plug-Ins to Explore the Urgency and Change Recipient Sections
    2. Using Plug-Ins to Explore the Vision and Target State Sections
    3. Using Plug-Ins to Explore the Actions and Success Criteria Sections
    4. Using Plug-Ins to Explore the Benefits and Commitment Sections
    5. Using Plug-Ins to Explore the Communications Section
    6. a Catalog of Reusable Agile Change Patterns

    Chapter 4: the Validated Change Lifecycle
    1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
    2. State 1: Agree on the Urgency of Change
    3. State 2: Negotiate the Change
    4. State 3: Validate Adoption
    5. State 4: Verify Performance
    6. Realizing a Change Canvas through the Validated Change Lifecycle
    7. Instantiating the Lifecycle Effectively Using Information Radiators

    Chapter 5: Walking through the Validated Change Lifecycle with a Comprehensive Example
    1. State 1: Agree on the Urgency of Change
    2. State 2: Negotiate the Change
    3. State 3: Validated Adoption
    4. State 4: Verify Performance

    Chapter 6: Using a Transformation Canvas for Enterprise Change
    1. Understanding Why We Need an Organizational Transformation Canvas
    2. Applying the Change Canvas to Transformations
    3. Mitigating Change Risk through Traversing the Canvas
    4. Prioritizing Different Minimum Viable Changes Based on Risks on the Organizational Transformation Canvas

    Chapter 7: a Cadence Model for Workshops, Meetings and Review Sessions When Running Lean Change at Scale
    1. Overall Cadence Model
    2. Change Agent Daily Standup
    3. Change Recipients Improvement Update
    4. Stakeholder/Sponsor Update
    5. Change Agent Planning
    6. MVC Canvas Refresh
    7. Transformation Canvas Refresh
    8. MVC Backlog Replenishment
    9. Metrics Update