Lean Change Part 1 - Combining Kotter and Running Lean

I have been spending the last six months or so enabling a large-scale IT transformation by combining Kanban with some of the principles and methods taken from the lean startup world.

The major problem with the existing method as it exists so far is that our minimum viable changes (MVC) lacked an overarching change lifecycle. We need a better approach to accelerate learning, an obvious one (in retrospect) is to make sure minimum viable changes are designed, socialized, and introduced in order of the highest risk.

Lean Change Iteration Meta-Pattern

I have supplemented the method to include a lifecycle that tries to accelerate learning in the right sequence for organizational change. My inspiration comes from two separate sources.

The 8 Steps of Change from John Kotter's - Heart of Change

The Lean Startup Stack from Ash Maurya's - Running Lean Book and Blog

This is my first attempt at taking some of the principles from Ash’s Running Lean and integrating them with Kotter's 8 Steps. The idea is to run a change program by:

1.  creating an initial change plan , capturing initial change model hypotheses

2.  identifying the riskiest parts of the proposed change, sequencing activities to mitigate resistance to change, validate correctness of the change, then mitigate the sustainability of change, and finally understanding how to optimize the change across the organization

3.  systematically testing the assumptions behind the change, iterating through an adopt, observe, and learn cycle similar to the validated learning cycle recommended by lean startup evangelists. I call this cycle Validated Change.

Stage I -Creating an Initial Change Plan

The Change Canvas facilitates planning a change program in a way that is that is fast, collaborative, and deliberately imprecise. The constraints of the size of the sections in the canvas encourages change agents to distill the plan into a form that is easy to communicate, and more important easy to change and easy to throw away.

Change agents collaborate to  develop an overarching Change Canvas filling up each section as follows:

1.  Urgency - List the top three drivers for change, identifying those most impacted by the change, as well as key decision makers

2.  Change Recipients - note those impacted by change, segmenting by role, level, and team as appropriate. Take a stab at identifying potential change champions, along with their current capability to realize change, and tactics potential champions are using now to mitigate relevant problems

3.  Vision - write down the vision that you believe will resonate with your organization, note key behaviors required to realize his vision. Create a "high concept pitch" that is easily repeatable

4.  Target State - determine a strategic enabler, descriptive metaphor, framework, and any other type of foundational component required to realize your vision. Align each element listed within your target state to one of the top three drivers listed in the urgency section

5.  Action - change tactics guiding teams will use to rollout the change, pay special attention to how your guiding teams will participate in rolling out your first minimum viable change

6.  Required Investments - list known hard constraints in terms of time, budget and people time. Write down known barriers to change.

7.  Benefits - List the expected benefits, both qualitative and qualitative

8.  Success Criteria - put down The key indicators you will use to tell you the same have successfully stuck

9.  Communication - mark down how you plan to communicate change. Note both high touch and push-based methods of communication necessary to collaborate with your guiding teams, and also taken note of other communication channels you plan to use as the change skills across the organization.

Stage II-Identifying the Riskiest Parts of Your Plan

Change agents collaborate to build an overall change canvas, and then create several refinements scoped down to represent the first Minimum Viable Change that would be introduced to the organization. Canvases are evaluated according to their ability to express a MVC that that accelerates learning and mitigates the most severe change risk.

What risks are considered the most severe will change depending on the context of the change program. That being said here are some typical change risks ordered by severity:

1.  Resistance to Change (Urgency) - target the initial change effort on members of the organization who are most able to identify with current pinpoints. The goal is to target your change efforts towards individuals who are feeling the pain stemming from current problems that the changes meant to address.

2.  Ease of Collaboration (Communication)- initial change efforts need to be focused in such a way that problems can be collaboratively solved by guiding teams. Try to choose a plan that allows your guiding team to work in a high touch session, prefer face-to-face over distributed and/or dispersed teams. This won't guarantee your executing the rate change, but it will accelerate your learning.

3.  Sustainability of Change (Investment/Benefits)- the success of the change is largely a factor of the actual commitment to leadership is willing to provide to that change. Securing bottom- Up commitment is equally critical. Choose A plan that gets the most commitment from sponsors, and secures the space necessary for the guiding team to be successful.

4.  Impact of Change (Change Recipients) - choose a segment within the organization (role, team, level, etc.) that will have the most impact on realizing the vision, in relationship to the time and effort spent by the guiding team. However, make sure to avoid falling into the trap of implementing a big bang change, still following minimalist approach

5.  Correctness of Change (Vision/Target State) - revisit your target state to make sure that the suggested change is realistic given the context of the organization, but also that it represents the minimum set of improvements required to demonstrate progress against the vision of your transformation

Key stakeholders and decision-makers are required to evaluation each MVC Canvas and select the one that  tackles the riskiest elements first and provide the maximum value.

Stage III-Systematically Testing the Assumptions behind Your Plan

Sequence Your Testing According to the Change Lifecycle

The Change Canvas was designed with Kotter's 8 Steps of Change in mind. The idea is to enhance the 8 steps with a method that de-risks the change through systematic testing. This is done by iterating through the canvas numerous times as necessary to implement a set of incremental changes (our Minimum Viable Changes, or MVCs.)

At a macro level, change agents refine the canvas over time as they learn more about what is required to make the change successful. Change agents revisit the canvas following the 8 steps iteratively,  in order to maximize learning, enabling Validated Change.

Increase Urgency

Create shared understanding for the top reasons that the change is happening. Use interviews and other observation that makes To understand how these drivers for change are perceived by those most impacted by change. Understand how the organization is currently mitigating top pain points as relating to the change, and the current capability in place to successfully execute on the change.

Build the Guiding Team

Truly understand who is impacted by the change, as well as key decision makers. Ensure that change drivers are tied to problems felt by those who will be impacted by the change. Validate shared understanding of key drivers by what people are currently doing, not just by what they're saying.

Hone in on potential change champions, looking at capability, and passion for the problem. Work with potential champions are resolving problems currently, and start building a guiding team.

Get the Vision Right

Create a vision that resonates with all levels of your organization, starting with your guiding team. Synthesize Key Behaviours based on how your guiding team behaves today. Create and share a 'high concept pitch' that is instantly repeatable by all involved.

Communicate for Buy In

Pay particularly close attention to communication channels. Poor communication is one of the top reason change fail. Start with high touch, personal, and push based methods of communication. Evolve to self serve, online, and media in order to scale. Cement a bi- directional flow of communication

Empower Action

Mark down your target state, focusing on designing the simplest, short term solution that addresses the key pain points for your guiding teams. List the change tactics your guiding teams will use to execute the change, paying special attention to your first Minimum Viable Change (MVC). Secure permission to act!

Create Short Term Wins

Roll out the first MVC with the guiding team. Pay close attention to behavior and coach as necessary to get A breathing sample of your vision. Validate that your guiding teams are receiving benefits as appropriate to the constraints (time and effort) involved.

Don't Let Up

As subsequent minimum viable changes are successfully rolled out by guiding teams, focus can switch to overall organizational adoption. The emphasis now is on optimizing Change according to hard constraints in terms of time, budget, and people's time. At first focus on your initial set of Minimum Viable Changes. Continue to test the change for benefits, both qualitative and quantifiable.

Make Change Stick

Continue to follow the validated change process, introducing successive minimum viable changes, until change is now the new reality of the organization. Pay attention to key metrics and indicators that will inform you as to when change is truly stuck in your new organization.

Advice on What Parts of the Canvas to Test First

Once you have chosen the canvas that represents a minimum viable change that will maximize learning, you are in a position to start testing inter-related sections of the canvas. Different sections of the canvas visualize different types of risks.

Change risk can be mitigated by validating portions of the canvas using a combination of customer development style interviews, observation, and measurement of implemented change.

Change agents would typically execute the change by mitigating risk across different categories. An example of the order that canvas segments cold be visited is shown below.

During my next post I will provide an overview of how I plan to further adapt the lean stack to implement individual experiments necessary to roll out an MVC.

Lean Startup for Change is Dead! Long live Lean Change! Long Live the Lean Learning Machine!

About 6 months ago I started experimenting with running IT Agile transformations using a new method dubbed by a few of us as Lean Startup 4 Change. The idea was to incrementally introduce change to an organization as a set of Minimum Viable Changes, taking advantage of validate learning, and preparing the client for pivot and pursue decisions.

As of this time I still don't feel like we have achieved validated learning, ie being able to mitigate risk and accelerate learning while building a sustainable change. 

Lean Startup 4 Change is Dead

A  part of the problem is that our lean startup 4 change method simply has to much stuff on it. (Gamification, Capability Models, etc). As of this point forward we are breaking the method into two distinct pieces that independently can be more faithful to their inspiration.

Long Live Lean Change

First of all IT Organizational Change is not a startup, so the term Lean Startup 4 Change really doesn't make sense. Maximizing validated learning by focusing on what's minimally viable does still resonate as being vital to running a succesful change program.  It seems that the underlying principles behind Lean Startup are applicable to any problem space with high uncertainty. Lots of different problems could be handled better with a pivot or pursue, hypothoesis driven mindset.

With that in mind I have rename the method to Lean Change, and defined it as:

A method that helps change agents to maximize accelerated learning necessary to plan and execute a succesful Agile / Lean organizational change. 

That definition will most likely change :)

I am continuing to build Lean Change by abstracting pieces of the leanstartup framework into an an underlying set of meta components than tailoring those meta component to make them suitable for Agile change inititiatives. 

Example of these adapted components include creation of a Lean Change Canvas, and altering the meta-iteration life cycle  into a Lean Change Meta- lifecycle. Up next is cataloging  a sequential set of change risks along with some recommended strategies to coming up with Minimum Viable Changes and Minimum Viable Improvements that mitigate those risks. 

I should stress that these techniques are a port of the methods and tools that Ash Maurya has created as part of his Running Lean book and blog posts. His works are second to none when it comes to providing easy to understand advice on how to run a startup using lean methods, and I am finding it a pleasure to map these over the change world.

I am borrowing from classic change methods such as Kotter to come up with how the lifecycle can interact with the Canvas to test hypothesis relating to validating change drivers, getting the target state right, amd validating behaviour of change recipients is actually changing.  I'm also workng with our firm's human capital practice to get their take.

Lean Change will continue to heavily use of David J. Anderson's Kanban to allow change agents to quantifiably verify performance. I don't see Lean Change working without Kanban being a core component. Not to mention that it is a measurable, viral, bottom up continuous improvement framework :)

Lean Learning Machine

The role playing game style character sheets, levels, missions, characters classes, peer based learning, etc has been abstracted away from Lean Change. The Lean Learning Machine is a customizable agile learning engine that allows change agents to create an agile learning path and use game play to promote organizational self learning.  The idea is that true agile change only happens when you no longer have to hire coaches, so we want to promote a coaching network, visualization of skill, and clarity around what to learn while respecting the fact that every change is different, and no two people wil advance the same way. 

Eating My Own Dog Food

I think the most important change is that both of these projects will be developed using lean startup methods. I'll be using Ash Mairya's Running Lean, as a process template. Here are the initial Lean Canvas below.

Lean Change Canvas

Lean Learning Machine Canvas

Up next will be problem interviews where I hope to get my target customers (I think it's Agile Change Agents...) to tell me if this either of these are even a problem worth solving.

Stay tuned...

If it Sucks it Shouldn't Sell

Most Political TV adds go so past the point of pandering, that they insult the uneducated and educated alike. 

Canadians tend to get horrible service from telecommunication companies, bad airline experiences, and unsatisfying medical care. Americans seem to face a similar reality.

Enterprise software seems to universally cause groans of dismay from the people that actually have to use it.

Consultants continue to provide their customers with target states and roadmaps that seem largely divorced from the reality of implementation. Clients continue to ask for more of the same from consultants.

So many aspects of our lives are contrained by a set of choices that are undifferentiated in their lack of ability to cause customer delight. 

Despite the heralded coming of the customer economy, a wealth of products and services are still push based. The provider decides on the thing to be built, and pushes a predetermined experience to the user. Customer feedback is completely mishandled, wether the reason is ignorance or incompetence is anyone's guess.

As consumers, we try to make different choices, but still end up with more of the same. 

Certain organizations, mostly from the tech world, seem to excel at pleasing their customers. These companies focus on the best experience for their customer, and garner political will to chase after the best customer outcome. These companies have faith that profits will come from customer delight, and know that the reverse can never be true.

What is preventing this customer experience revolution from moving faster in the corperate and public sector world?

How do we accelerate the adoption of design thinking, synergistic methods, and the mantra of the modern knowledge worker into places like Health, Banks, Government, and Insurance providers?

If it sucks it shouldn't sell, and we shouldn't buy....

Throughput Planning - Why Project Managers Should Like Lean and Agile

Project managers in IT have a tough job. I've been there myself, and I have also coached a large number of project managers (PM) throughout my travels consulting for a number of organizations around the world. One of the biggest challenges a PM faces is managing the iron triangle of time, cost and scope while wrestling with never ending waves of change and uncertainty as they sheppard the team and project to completion. The typical tool most PMs have been trained on is the work break down structure (WBS) and being schooled by institutions such as PMI, that the best way to manage change and gain predictability is to track at the task and resource level. Unfortunately this approach tends to fail as project complexity increases and most experienced PMs that have the battle scars of large complex projects learn quickly that detailed planning and tracking doesn't help manage change or gain predictability. Trying to keep up with a large rapidly changing project is like playing Tetris on level 20, good luck.

Game Over - Trying to keep up with a complex project plan

At this stage of their career, the tendency is to move from detailed task and resource tracking to focus on milestones and deliverables tracking to reduce the detailed planning that doesn't justify the cost vs value of keeping it up to date. While this lighter weight approach is better as it frees up the PMs time from updating project plans and chasing people for status and allows them to spend more time on managing the client, leading the team and resolving issues, it has also has flaws. At some point in the large hairy project, the client or someone else will launch a large number of changes at the project. Change is inevitable in projects for knowledge work. During this time, the PM is struggling to answer the questions of "what is the impact of these changes?", "will we be on time?", and "what can we do to get on track again?". Tracking milestones and deliverables fails miserably at answering those questions. The PM desperate for answers and in need to "show progress" tends to fall back to detailed plan in an attempt to resume control forgetting why they avoided doing this in the first place. It's a vicious cycle and leaves the project at risk.

Lean and Agile to the Rescue

Lean and agile methods provide an incredibly easy to use technique that provides the visibility into progress without the overhead of managing the details. It's called "Throughput Planning" or "Velocity Planning" depending on what agile circle your part of (Kanban or Scrum). In Throughput Planning, all the PM has to do is make sure that the project is decomposed into a set of business valued increments (features, user stories, agile use cases, etc.) that can be worked on fairly independently of each other, are similar in size and provide business or end user functionality. To simplify this example, I'll call them features. Once the PM has the features, the last piece of information they need is the expected average monthly throughput the team can commit to. Once you have those two pieces of information, number of features and expected throughput you can then forecast the end date with some simple math. 20 features, 5 features / month means you will be done in approximately 4 months.

Benefits of Throughput Planning

With this tracking system, you have an accurate measure progress that doesn't lie easily. 5 features done in this scenario represents ~25% completion rate for the project and is a much more accurate measure of progress than tracking at the task level. It also provides an easy way to assess impact of changes to the timeline. If we add 10 new features we know this pushes the timeline back 2 months. If we want to bring the timeline back on track, the question is now what can we do to increase throughput over 4 months by 10 features (~2.5 features/month)? If we want to know if we are falling behind simply look at how many features have been completed. The final benefit of this approach is it also forces the team to deliver completed work often to prove progress, every month the team should deliver 5 features. Want to de-risk your project? Nothing reduces risk like seeing incremental returns rather than waiting for the big bang return at the end.

If your a project manager that is struggling to manage the chaos and complexity in your projects, I encourage you to take a look at Throughput Planning and look at how to make your project more lean and agile. It reduces your workload in tracking, simplifies impact assessments, and reduces risk.

The Demise of IT Business Analysts

IT departments typically staff themselves with a group of folks known as business analysts.

These folks have the responsibility of talking to folks that work in the business and translating their needs into a format that more technical folks can understand, because for some reason or other, most managers think that developers are unable to speak the same English that everyone else does.

IT is consistently cursed with getting the requirements wrong. Users, it seems, are horrible at actually reading the requirements documents they are given, worse they always seem to hate the great software that IT gives them. IT management typically has two solutions to the problem

1 - put a change management system in place that prevents those customers from actually changing their minds

2 - invest in better capability in requirements facilitation and documentation

None of these assumption address the underlying cause of churn in IT requirements, which is that today's customer economy has created an environment where the benefit  of many IT requirements are based entirely on assumptions. When these assumptions turn out to be wrong (and they often do) the business has no choice but to change direction, and fast.

Faced with this challenge IT either jumps into heroics mode or shuts down into change request mode, or worse some weird mixture of both.

No amount of requirements gathering expertise can fix this problem. 

For the IT Analyst function to be relevant in today's world requires a different set of skills. What is required is an IT Analyst who is well versed in how to reverse engineer a business plan and associated IT solution into a set of testable assumptions that can be implemented, and validated by order of highest risk. 

This analyst needs to be able to combine business knowledge with enough technical savvy to walk business customers along a journey of validated learning, guiding stakeholder through pivot or persue decisions. They need to employ techniques like Business Model Generation, Service Design Thinking, and Customer Development to provide the business with a richer ecosystem of tools to brainstorm what the future should look like.

In short Business Analysts need to become Business Technology Innovation Experts if they want to more than mere order takers.

What Scrum, Kanban, RUP, and ITIL All Have In Common (which causes them to fail)

Putting aside the considerable differences in these methods, RUP, CMMI, Scrum, etc are foremost all products, built using a traditional product development approach. 

This means they have users. Coaches, Managers, Developers, and other knowledge workers who  desparately want to achieve better outcomes delivering business technology solutions. 

These folks read the case studies that accompany these methods and dream of emulating the stories of fantastic accomplishment that come with them.

For the most part these earlyvangelists end up dissapointed.

The real issue with these methods is the product development approach used to build them.

Most of these methods were born out of the personal pain of a particular set knowledge workers. These folks then went on to build a solution to that pain.  This is a good thing, building a solution to your own problem guarantees that you will have at least one customer, and makes it likely that you are addressing a need that someone else has.

For the most part that's where the good news ends. Most delivery methods seem to be developed using traditional product development techniques, and at worst are defended like religions against any forces that might tamper with the "purity" of the product.

It seems to me that methods like RUP suffer from the former, the method is continually extended to support every kind of user and end we up with an incomprehensible mess.

Scrum seems like an example of the former, deliberately avoiding the needs of entire classes of users in an attempt to stay as true to its roots as possible. Users are left to discover the parts that actually matter, often through very expensive trial and error.

Even Kanban, my favorite improvement tool by far, suffers from owner bias, I have yet to personally witness a text book like case study of self directed evolutionary change outside of my own personal team.

Comments that people are not using these methods properly miss the point entirely.

If a product is used incorrectly it is because the product suffers from poor useability. Owners of the method have not put the right amount of effort to ensure that these methods are not only useful (they are) but that they are easily useable (they aren't).

Method owners and evangilist have their work cut out for them. The problem space is complex, the solutions complicated, and the emotional investment is often high. By their nature, improvement methods need to be both open and prescriptive, kind of like the best software language you ever came accross.

Customer Development, a technique invented by Steve Blank provides some insight on how to tread forward. As method designers we need to probe our users a little bit better than we have in the past.

1. What have users done outside our community done solve technology delivery pain, and how can we integrate the work of these earlyvangelists into our own vision of performance improvement?
2. Does our method actually address the problem, and how can we measure the applicability of our solution?
3. Most importantly, what major pain is still not being addressed by the current collection of improvement methods out there, making them vulnerable to next disruptive innovation?

Despite all the work to date, the business of trying to get technology knowledge workers to raise their game is still way more of an art than a science. All of us change agents are operating in a highly uncertain market, time to start thinking like a startup, and collectively be open to pivoting a time or two before settling into our one right approach.

Lean And Standards

 I whipped up something quickly to explain the lean approach to standards to some clients today, and thought I would share...

1) when a team starts work it has a set of standards to use that describe how to complete the work. Often these standards are based on standardized work types, but they can also be based on process, team context, or be global

2) the team has two choices, use the standard, or to suggest an improvement

3) if the teams suggests an improvement they must make a prediction of improved performance 

4) the team then completes the work, and measures performance 

5) if performance is improved than the suggested improvement becomes the new standard forthat team

6)Team standards can be spread to other teams, becoming standards that apply to processes, standard work types, and even globally. This is facilitated by various improvement events such as operational reviews, retrospectives, etc with the assistance of managers and the QMO

7) Managers can help teams by recommending optional practices and suggestions for improvements. Again a prediction should be made, work should executed for a period of time, and the results should be measured. 

This approach largely holds regardless of the "kind" of standard we are talking about. Technical, coding, process, architecture etc are at there most effective when they are measurable, and when they can changed through safe-to-fail experimentation. Managers govern the process, and make sure that standards are not just ignored, changes must go through a scientific process. 

Managers can also suggest sweeping, global rules, but again we need to measure. With Kanban our measures are based on features. Specifically throughput, lead time, failure to value ratio, and failure intake at the feature level.

Client Reviews: From Waterfall to Agile

We are currently transforming a large organization with 200+ people to adopt new agile behaviors. The transformation started off with identifying 3 pilot projects to be the first adopters of agile skills and techniques.

The 3 projects started their agile journey with creating a story map to organize and visualize their business requirements. The story mapping technique enabled the project teams to decompose their projects into features that can be managed independently. As a start, they used their current business requirements document and transformed it into a story map. The story map was then used as visual tool to drive discussions with business on feature creation and prioritization.

After decomposing the project into features, the teams created their Kanban boards with policies to manage the flow of work through the system. The teams’ set up regular cadence for standup meetings to provide updates on tickets, raise and resolve risks, issues, and blockers.

The new approach received positive feedback from business as a result of engaging them in more frequent discussions. Business is now working closely with project teams to get acquainted with the new tools and processes. Currently they have setup regular meetings with business to address business and IT perspectives on features and how they will be grouped into MMFs. The new processes and Kanban have provided project teams and business a collaborative and transparent approach to manage their projects.

Below are pictures from project Kanban boards and the team’s feedback on the new process and Kanban.

Pilot Project 1

• “The story board has been instrumental in identifying gaps between the requirements and potential solution.”
• "Although our project is still very early in the Kanban process we have found definite value in the visual and collaborative aspects of the model.”
• “Having standups helps to ensure everyone on the team is familiar with the state of the project, what issues are currently open and also creates an opportunity for everyone to brainstorm and provide input when required.”
• "Main challenges that I have seen are firstly trying to learn and pilot the model in a medium/high complexity project (learning curve) as well as adjusting everyone's views to how the project would be approached compared to a standard waterfall model.”
• "Trying to retrofit a project that started as waterfall is challenging e.g. high level requirements doc (updated, revised) in progress when Kanban training started; developing project plan with business partner who had not yet been exposed to Kanban, and moving forward adapting to Kanban technique.”
• "Learning and application happening at the same time (don't feel there is sufficient time allowed in the project timeline to 'practice' techniques/adjust our processes before putting it in front of the client; making mistakes as part of our learning can affect our credibility, especially in a culture that traditionally is not failure/mistake-tolerant.”

Pilot Project 2

• “One could easily understand the work flow and identify the bottleneck to re-distribute the work load.”
• "It makes work more interesting and more transparent.”
• “It also helps me to find where is my position in this project and the relation between my tasks and others, and who will be affected if the task cannot be delivered on time.”
• “The most challenging part is defining meaningful tasks (fine-grained) or feature sets and reduce the coupling (dependency) between tasks, which is the key part to make the whole workflow goes smoothly.”
• “Switching to Kanban in mid project hasn't been easy. some overhead was encountered  getting everyone up to speed but project timelines weren't changed”

Pilot Project 3

• “The daily standups promote communication between my peers.”
• “Helpful to identify road blocks and the opportunity to resolve more quickly.”
• “Using Kanban, we can trace the project activities, and find the bottleneck (blocker) in the different phases.”
• “Business stakeholders wanting to drive Kanban activities before they are fully understood. Often the business PM is not clear and causes confusion.”
• “Clarify the role and responsibilities of the Kanban Champion in relation to the Project, how they interact with business - this is not clear and is causing confusion.”
• “I feel that we have a challenge to get blocker removed quickly and efficiently, and define the delivery timeline/milestone for each MMF.”

Integrating Story Mapping with Kanban

Piloting projects on Kanban requires projects team to re-think the old way of consuming requirements and move towards a more structured approach. As a start, large scale projects must be decomposed into features that can be managed independently. In a lot of organizations we find requirements in the form of a business requirements document. Usually:

•        The requirements are not organized to show the value provided from a user perspective
•       There is no priority assigned to the requirements with respect to the other requirements
•       Endless discussions with business to finalize and “lock” the scope of the project

We have had great experience using story mapping to help teams address the challenges that often find in a typical business requirement document. We have been integrating story mapping with Kanban to enable teams to start thinking in an agile approach from day 1.

1- Creating features is a collaborative exercise where the project team and business stakeholders list and organize the features in a sequence of events that deliver value from a user perspective.

2- For each of the activities, the features are prioritized with respect to each other.

After the features are prioritized, the team can now start creating MMFs by slicing the map horizontally.

3-     The prioritized features and MMFs from the story map can then be used to populate the Kanban board. 

 

The story mapping techniques enables teams to see the bigger picture and the scope of the project. As a result, this technique helps project teams to think about features and releases from a holistic project perspective.

My Definition of a Minimum Viable Change - Lean Startup For Change

I've submitted numerous posts on Lean Startup 4 change. Time to put a stake in the ground and define exactly what I mean by a Minimum Viable Change.

To properly understand how to define a Minimum Viable Change we need to understand what we are trying to measure...

yes you...

Therefore I define a Minimum Viable Change as follows...

Please note that this post does not endorse the use of heroics on projects of any kind...

The Gamification of A Kanban IT Transformation

My last post discussed how I and my team were using a transformation participation engine to provide our change team with metrics necessary to support validated learning for our change effort.  Aside from enabling a Lean Startup approach for our change effort, we also plan to use the data set captured  within our engine to Gamify our transformation.

Different transformation  campaigns (eg Kanban, Agile, Dedicated Quality Office, etc)  have been broken into explicit learning tracks. Each learning track has been further refined into specific skills that we hope our clients acquire as part of the transformation. We are tracking our progress (note NOT progress of folks who are learning) as the number of staff and managers who acquire specific skills.

In order to add an element of Gamification to the transformation, we plan to introduce the notion of behavior / change points. Skills are acquired through completion of explicit behaviors. Each behavior when exhibited provides a specified amount of points. 

The gamification aspect comes in because behaviors can only be acquired from folks who have 

A) already acquired the skill that the behavior belongs to

B) have a point reservoir equal to the behaviour being acquired.

Behaviors are acquired by "transferring points" from on person to another. This has some interesting implications.

1) you must find a mentor to acquire a skill, it's not up to the change team or managers to validate your progress, it's a pure peer system

2) you can only give your points away once, after that the pupil must become a teacher or the system dies

3) giving someone credit prematurely is limited because both you and your mentor will look foolish if you are called out.

Our first Minimum Viable Change using this approach will be to setup a manual Leaderboard outside of a Kanban based standup, and measure wether there is desired change in behavior. Or wether people throw eggs at us...

Depending on success, we also plan to prototype some character sheets, periodically updated manually by our team.

If Gamification proves to be a hit than we will figure out how to automate all this stuff ...

Implementing Minimum Viable Changes As Part of a Lean Startup For Change Approach

In my last post I described how we measured Minimum Viable Changes (MVC) for our Lean Startup Enabled Kanban change initiative. In this post I will describe the exact process we used define, implement and measure those MVCs.




In order for our approach to provide learning at the pace we required we needed to be able to define Minimum Viable Changes that we could complete in a matter of weeks or days. We did this by breaking up our strategies into one or more transformation adoption "campaigns". Each campaign was differentiated in terms of underlying adoption approach used, a strategy it supported, or any the content being adopted.






MVCs were then designed to validate assumptions contained within a particular campaign. We needed to quickly validate if the approach behind a particular campaign could change people's behavior, and help them acquire new and useful skills at the rate required for success.

Each MVC was labeled according to a descriptive name along with one specific assumption that it was designed to validate. Each MVC contained an explicit hypothesis, along with details on how to measure the accuracy of that hypothesis.

 


Every MVC followed a similar measurement approach. Each MVC targeted a specific set of skills taken from the Transformation Participation Engine mentioned in the previous section. The value of each MVC was determined in terms of increased number of individuals acquiring new skills. Assumptions could then be validated by measuring actual changes in behavior, and determining if the adoption approach underlying the campaign with sound.

An example of this approach is the Kanban strategy, which was categorized into a number of campaigns. The Visualize As Is Work campaign was dedicated to visualizing current state processes, and gradually implementing WIP limits, policies and other components. There was no inclusion of other agile practices. An example of a MVC implemented for the Visualize As Is Work campaign was the setup of Functional Department Kanban Boards.

On the other hand, the Kanban/Agile Pilots campaign used a much more aggressive approach, mixing Kanban and Agile practices, such as story based development, cross functional teams, planning poker, etc. An example of the MVC implemented for this campaign was dedicated coaching and training of story mapping.

Other campaigns included a Kanban self-starter program allowing everyday staff to run their own Kanban initiatives, a hiring campaign to recruit dedicated Lean/Agile coaches, and a gamification framework that would render individuals progress in skills and behavior in a role-playing game style character sheet and leaderboard.

Using Kanban to track validated learning, while supporting a Kanban transformation

Of course to track the progress of our organizational transformation the change team used a Kanban system.  During the first 3 months of this engagement our Lean Startup Kanban system changed 5 times. Our end product was much simpler than previous incarnations, and has provided us excellent support for a validated learning change approach.

The backlog consisted of numerous campaigns, each campaign being associated with a set of MVCs that could validate the assumptions contained within each campaign. The priority of a particular MVC was represented by placing these MVCs from left to right on the backlog. 

MVCs were sized so that lead time would be between 1 and 3 weeks. During the preparation phase, metrics used to measure a specific hypothesis was defined, and the exact impact/commitment from the targeted set of clients was also specified and communicated. 

MVCs were then introduced to a subset of the organization known as a cohort. The introduction state involved initial coaching and training, hands-on workshop facilitation and other activities. Once the client was deemed to be somewhat independently operating with the new skills introduced, we moved the MVC to the watch state. 

Watching consisted of observing the behavior of our customers, and measuring specific behavior according to the Transformation Participation Engine. Once our customers had been observed for a suitable amount of time, we then measured the MVC, and determined if our outcomes matched our hypothesis. 

At first it was difficult to determine when to move a MVC from watch to measure.  We soon came up with a simple rule. A MVC could be moved as soon as someone from our team felt that a campaign required a change in tactics. This called for immediate action to measure the MVC that was currently in-flight, and introduce a new MVC to validate the modified approach. Often these observations preceded our measurements, we were measuring people's behavior, behavior that we had to manually observe. As a result our observation and measurement operated in tandem with each other.

Once a week we held team retrospectives, at that point we we reviewed all measured MVCs, discussed the outcomes and moved the MVC to the appropriate pivot or pursue lane depending on the results of the discussion.  The decision to pivot or pursue was also typically made at these retrospectives, once we had an opportunity to review a batch of MVCs.

Introducing the Transformation Participation Engine

Update: This part of the method is no longer being practiced by our team. We still feel that having a clear learning path for individuals is important, but it must be voluntary, transparent, and based on self assessment. It must also be pull based, where participant actually ask to be part of the system. Stay tuned for future updates.I am currently knee-deep in another large-scale IT organizational transformation. Again Kanban is a critical enabler, as are a mixture of agile methods. What makes this transformation different is our team's decision to manage the change initiative using a modified form of lean startup methods.
The following definition of a startup from Eric Ries Lean Startup book particularly inspired us...

a human institution designed to deliver a new product or service under conditions of extreme uncertainty

By this definition, an enterprise change initiative could be deemed a startup, one that could take advantage of Lean Startup techniques.



We quickly came up with an approach to guide our change initiative based on the Lean Startup method. We called it the Lean Startup Change Approach :-). What became quickly obvious to us, is that it was not apparent on what we were supposed to be measuring.

Measuring the things that matter for a change initiative

This turned outTo be more challenging than expected.  At first we tried to be overly be clever, and come up with experiments that would validate the performance benefits of Agile and Kanban practices. This exercise realistically would take many months, if not years, to complete.  Our team did not have the benefit to dedicate that much time.

After a significant amount of thinking we we focused our efforts on figuringOut how to measure behavioral change and capability of the organization to adopt different methods, as opposed to measuring the methods themselves.

Any validated learning effort should focus on assessing the areas of highest risk first. In our case we needed to be able to effectively change the working habits and thinking culture of our clients before our involvement in the change effort came to an end. Our job was to make sure that our clients were positioned for success once we left.

The Transformation Participation Engine

With this in mind we created a "Transformation Participation Engine" framework. The objective was to track and visualize the progress of adoption for individual staff on the journey towards lean thinking. Minimum viable changes (MVC) could then be developed specifically to target measurable changes in a subset of the organization.

We defined such a system by deconstructing the objectives of our change initiative into a set of fine-grained target behaviors. We then grouped those behaviors into specific skills, grouped those skills into tracks, and finally grouped those skills into strategies. Below is a simple diagram showing the components of the Transformation Participation Engine, along with a sample of each component in brackets.



Once we had a robust repository of behavior and skills, we associated each skill with an achievement rating. The Achievement ratings for skills were then used to calculate an individual's overall progress in terms of participation in the transformation. In our first iteration of the transformation participation framework we followed a very simple calculation algorithm. Achieving a rating from a single skill would be enough to promote an individual's overall progress to that rating. We anticipate using a more complex algorithm as we continue to use this framework.




Example: the Kanban category is divided into various tracks including Operate, Invent, Manage and Own. The Invent track contains a number of skills, including the Design skill. In order for someone to successfully achieve this skill, he or she would need to demonstrate evidence of a specific set of behaviors, one of which is building a Kanban system from scratch.
Bob completes the Design skill, which has an achievement level of Prowess, his overall progress is therefore Prowess

Using Kanban to visualize transformation participation

We defined a Kanban system to visualize and measure the learning/participation progress of individual staff, managers and executives using this framework. Each individual was represented as a set of work tickets within a Transformation Participation Kanban system.
A separate swim lane was used to track each FTEs overall progress. Each employee with the organization would have exactly one ticket on the “overall progress” swim lane



A separate area of the Kanban system was used to visualize an individual’s progress in various skills. An employee ticket was cloned for each skill that he/she was trying to complete. These "skill" tickets would progress through the skills track according to skills completed. As skills were completed, they would provide the employee with an "achievement rating".

The employee work ticket within the “overall progress” swim lane would move to the appropriate state according to the achievement rating received by completing particular skills.
With this system in place we were able to both track and project the rate that the organization would be able to adopt new methods. This became our primary method of communicating status throughout the transformation.




Once we had this measurement system in place, our work turned towards determining as quickly as possible whether any of our transformation methods would support the projected velocity of change. We then needed to design MVCs to specifically evaluate these assumptions. In essence, we elected to focus exclusively on "growth assumptions" for the immediate time being.

I'll talk about how we designed our various MVCs, and providing examples in future posts.

Technorati Tags: LeanStartup,Kanban,lean,agile

The Futility of Tracking Individuals Time

An inordinate amount of economic resources are spent on managing people's time. Professional Services, IT, Design Agencies are typical examples of organizations that ask their staff to track every task they do, the type of the ask, the client the task was for, etc., all down to the hour, or minute, depending on where you work.

The rational for doing this seem perfectly reasonable, even if the outcomes do not.

Chiefly, business owners want to know if they are charging the right price for services rendered to clients. The need to track effort is a primary objective. Supposedly this helps managers optimize efficiency.

Tracking time is also cited as a way to prevent abuse at work. Time management is supposed to protect workers from being forced to work unreasonable hours. It is also is touted as a way to keep workers honest, preventing them from spending to much time googling, or facebooking, or other kinds of goofing off.

While the objectives are rational, the ability of management to ignore the obvious dysfunctions of time management is not.

Whenever time tracking is used to prevent abuse, falsification of data is the result.

Project Managers will prevent workers from tracking after hours work if it affects their budget, regardless of exhortations from senior leadership. This is especially true in professional service and consulting firms.

Workers will also enter time according to the expectations of their management, implicit or otherwise. No one wants to be flagged as a bad performer.

Even when discounting abuse, time entry is notoriously inaccurate, most workers have trouble remembering exactly what they did down to the hour for an entire week. Again, time gets entered according to management expectation, rather than reality.

The really insidious aspect of time management is that it is measuring the wrong thing. It emphasizes an inward perspective where cost is king.

Success in a customer experience economy requires an external perspective, one focused on getting a handle on the creation of customer value.

On first look, this is a more involved exercise than tracking individuals time.

Measuring customer value requires a deeper understanding of the types of goods and services you offer to your customer. This allows you to look at metrics like throughput, the time it takes to create customer value, and how often you deliver value without incurring customer complaints.

These are the metrics that matter to your customer, not the exact time spent by every FTE. Cost can still be measured, but by approximation, which is more than good enough for most situations.

Simply take the total burn rate to produce a product or service and divide it by the throughput. Effort across multiple services gets amortized across the portfolio.









- Posted using BlogPress from my iPad