Once Some Kanban Successes Are behind You, Step up the Pace of Your Agile Transformation

Having already achieved some quick wins using the Kanban method, the people within your organization may be ready to adopt a more fulsome set of agile methods and techniques. Examples include finding a team or set of teams to adopt some of the practices from scrum, or extreme programming, as well as other method such as behavior driven development, story mapping, custom development, etc.

This more ambitious change can also target a slightly larger group this time around, for example an entire value stream or all of the knowledge workers trying to deliver value from one specific line of business within an organization.

That being said, implementing a more aggressive change exposes us to a number of risks that we have to take care to mitigate.


There is a lot to choose from when it comes to considering what agile methods to consider adopting as part of any kind of change. Some methods are more technical in nature, some promote better collaboration, all of them encourage higher feedback.



We can't just assume that any particular set of methods is going to be the right one for an organization. If we do this, and implement a cookie-cutter set of agile methods, we are very likely going to end up with the wrong change.







Implement More Ambitious Agile Change Using the Kernel Pilot Pattern

Our team has had success executing more ambitious agile change by following this pattern. We are executing larger agile change, but taking care to evaluate different aspects of the change model as we implement the change. We need to be ready to modify, append, and even discard various aspects of the change if they do not match the needs or context of the organization.

The idea here is to implement a change that acts as a miniature version of the overall transformation. A subset of transformation drivers should be addressed by the kernel pilot, as well as a significant portion of transformation target state components. This will allow you to evaluate if change participants receive appropriate benefits based on their commitments. Here is the canvas illustrated below, using a Change Canvas.



This kind of change typically takes longer to execute, several months is normal for change stakeholders to adopt a more fulsome set of agile methods. More coaching time is required, but benefits should also be higher, with both improved capability and resulting improvements in performance. As an outcome, you hopefully will have learned more about what your overall transformation target state is going to look like.

An Agile Requirements and Agile Management Stack Is a Good First Kernel Pilot

While certainly this is not the only option for a kernel pilot, (one focused on technical practices can also make a lot of sense), we see a lot of bang for buck in helping technology knowledge workers adopt a suite of agile practices that help improve communication and collaboration.  Techniques could include a cross functional agile team model, user story centric practices such as planning poker and story mapping, and potentially other agile design methods such as behavior driven development and class responsibility cards.

Change stakeholders getting started with this kind of change usually require more significant assistance from somebody with agile experience, typically some full-time support is required. We have seen significant improvement in the quality, throughput and lead time from teams adopting this suite of practices, or a similar set of practices and tactics simply because they promote better coordination and collaboration.

Of course the exact combination of practices will need to vary based on context, and as the change progresses, some techniques will be discarded, modified, and others added.

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.

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

Lean Startup For Change: Bootstrapping an Enterprise Kanban Transformation with Lean Startup Methods

By now many are familiar with the concept of the LeanStartup, and the methods pioneered by Eric Ries and others. In a nutshell the LeanStartup approach helps human institutions create value in a sustainable way in highly volatile/uncertain environments. This technique has become the de facto standard for young, savvy technically minded entrepreneurs working in innovative new organizations.

But thinking that the LeanStartup method just applies to the folks in Silicon Valley misses the point of how powerful these techniques are.

Increasingly all manner of organizations, institutions and enterprises are being forced to compete in highly uncertain markets. This means that LeanStartup applies to a wide variety of domains. One such domain is large-scale enterprise transformations.

I have spent the last several years of my career dedicated to IT transformations, helping clients to improve the performance of knowledge workers dedicated to building business applications. I have specialized in using agile and lean techniques, lately putting a real focus on capital K. Kanban, invented and made famous by David J Anderson.

Recently, our team has elected to enhance our transformation approach with LeanStartup. While this is still an evolving approach, I’d like to share our current progress.


Breaking down Change into Increments of Learning
Most change management approaches rely on making a huge number of assumptions about the organization, and impact of specific changes. Kanban provides a more incremental approach to these changes, but still contains a number of assumptions around how people react to certain components of the framework.



























The LeanStartup approach recommends breaking product delivery into a set of Minimum Viable Products (MVP). Each MVP is built for purpose to support learning. The really interesting part of the MVP approach, is that you often don’t have to build anything to learn something about the viability of your product.

In our approach we are breaking up all of the assumptions in our transformation into a set of Minimum Viable Changes, in effect we have decomposed our transformation into the smallest possible units, laid out our underlying assumptions, and then backed up each assumption with a hypothesis and a set of graduated metrics to support that hypothesis.

Defining Target Behaviors Using Measurable Hypotheses
Components of the transformation have to either lead to improved performance (value hypotheses) or facilitate adoption (growth hypotheses). Again rather than relying on assumptions, the transformation vision is decomposed into specific strategies, and the strategies are further broken up into behavioral hypotheses. These hypotheses are tested through the creation and implementation of various MVCs. This approach is allowing us to gather data around whether to change our tactics, while continuing to pursue our overall strategy, or whether to make a major pivot, and make major changes to our overall strategy.



Measuring Specific Hypotheses
MVCs test specific behavioral hypotheses, in our approach we are using classic cohort testing recommended by the LeanStartup approach. Targeting a single MVC against multiple cohorts, or split testing against different cohorts.


We have structured Kanban, and other lean components into a set of graduated behaviors. And then designed appropriate MVC to test these behaviors. We are also currently in the process of extending this framework to cover other agile process components as well.


Here is a sampling of hypothesis with some ideas on how we plan to measure  the accuracy of our assumptions. These metrics are refined depending on the MVC we design to test the hypothesis.


We are only a couple of months into the process, but some interesting observations have already come to light...

• we are adapting ALOT faster, no pivots necessary yet, but we are incrementally adjusting our tactics every couple of days
• our MVCs are getting much smaller, and we are just getting ready to rip down our transformation Kanban board to better reflect the MVC approach as we get more comfortable with it
• cohort testing is revealing a competitive streak with our coaches, causing us to really maximize client participation (one of our key metrics), we are in effect gamifying the transformation

Stay tuned, we will continue to share our progress...

..

Lean Thinking Tools for Improving Your Portfolio Planning and Prioritization Process

We just started an IT Transformation for a new client that is looking to fundamentally change the way they deliver IT services and application development. As part of the transformation we are helping the organization improve their portfolio planning and prioritization process to provide greater transparency, flexibility and control (yes control and agile does go together). Whenever we work with clients in this area, the first step we take is help them break down their old mental model of portfolio management and take a fresh perspective. To do this we introduce four thinking tools to help them wrap their heads around the new concepts. The goal of the four thinking tools is to help organizations look at planning and prioritization as an economic bargaining system.

Thinking Tool 1: Three level planning approach controlled by cadences

The first tool is to stop looking at portfolio planning and prioritization as a one time annual budgeting process and instead move towards a frequent multi-level planning system for portfolio management. Each level of planning should have well-defined units of work, cadence, and a form of currency (more on that later). The specific goals of each level are:

Strategic Planning:

• Identify ideas to realize strategic business objectives
• Set allocation based on LOB / Program / Work Type
• Longer Cadence, example quarterly

Project Planning: 

• Idea analysis and project planning
• Define projects in terms of business valued features based on a high-level solution
• Medium Cadence, example monthly

Operational Planning:

• Project work intake with frequent work replenishment for solution delivery
• Dedicated intake channel for emergencies, small enhancements and bug fixes
• Short Cadence, example bi-weekly

Thinking Tool 2: Breaking projects into minimal releases and business valued features

Based on Thinking Tool 1, if the organization is able to establish more frequent strategic planning cycles (e.g. quarterly) than this encourages projects to be broken down into smaller chunks that can fit into those cycles. This allows IT to work more frequently with the business to understand what the high value features are and get to quick wins faster. At the same time this also provides greater transparency of progress into budget spent vs budget realized in terms of real value (i.e. a potentially shippable system).

Thinking Tool 3: Planning informed by capacity in terms of throughput to level demand

One of the challenges with traditional planning approaches is that capacity is not used to inform the planning process. To build an effective planning and prioritization process the organization needs to understand capacity in terms of throughput (how much value can I deliver within x amount of time) and level demand based on available capacity. What we often see broken with traditional processes is budget being the only input into the planning process and that is typically not the "bottleneck" or scare resource in the organization. Money is abundant, time is not which leads to the end of year madness many organizations fire fight their way through.

Thinking Tool 4: Establishing currency to represent scarce resources provides a mechanism to facilitate exchange of value to promote liquidity and flexibility

The final piece to the puzzle is establishing a common unit of currency based on scarcity. Instead of throwing money at the problem, the organization starts looking at their delivery capabilities as system of work that has real constraints (i.e. time). The unit of currency we alluded to earlier in Thinking Tool 3, is throughput which represents work/value in terms of time. The currency is then limited based on scarcity which is represented as work-in-progress (WIP) limit that controls the backlog and queues that work fits into.

By understanding these four thinking tools they provide an organization with the foundations for establishing a fast feedback portfolio system managed by multi-level planning with cadences, defining projects into smaller increments of value, balancing demand based on throughput, and planning and prioritizing based on a common unit of currency that represents scarcity.

In a later post, I'll share a set of planning and prioritization patterns we use to implement these concepts.

Comparing Kanban and Scrum

Is pointless.

Yes everyone has an opinion, and a strong opinion at that.

Including me, especially me.

Everyone has an opinion except the people that really matter. I'm talking about the executives in charge of those multi hundred million dollar IT transformations going on right now. The ones responsible for integrating all those legacy systems to support that latest M and A.

The folks responsible for determining the who, the what, and the how for the technology landscape that will support corporate America (and in my case Canada) into the next century are almost all completely ignorant of what agile is, and what agile means. They still think waterfall is the way to go. They think agile is a toy to be used by post graduates to create cute applications that play on teenagers' iPhones.

I see this every day where I work, and I see a lot of big IT programs here. I have have seen some very large scale IT transformations started recently based entirely on more command and control, more governance, and more standardization.

This is the big killer whale that we all need to face. A prevalence of a mindset that is hostile to agile principles, and sees self organization as a threat.

Yes, the tide is slowly turning, but its also going backwards in lots of places. There is a ton of work for us to do. Best we do it together.

Advice on Successful Organizational Transformation

Every transformation has a unique set of challenges based on its particular context. We have noted the following top issues below, along with remediation activities. All issues noted below are based on our real experience on similar transformation engagements:

Leveraging a One-Size-Fits-All Solution

Many leaders within our client organizations are challenged by the fact that there is no commonality in the way that different teams and programs deliver and maintain software application systems. They justifiably see this lack of standardization as a symptom of an ad hoc organization that lacks the maturity to perform similar work in a similar manner. This lack of standardization increases risk, raises cost, slows down delivery, and makes it impossible to get to a higher state of performance. 

A natural reaction to this state of affairs is to create a process framework that covers all possible circumstances, often using a standardization approach based on a one size fits all process. Customization is typically done at the project size/cost level, if done at all. Elaborate processes are drawn up to cover the SDLC, along with detailed templates. Staff is then trained on the new method. Feedback is gained on the new method, and (eventually) that method is updated.

Unfortunately all too often this approach results in a delivery process that looks good on paper, but does not meet the diverse requirements of different teams, different programs, and different levels of delivery risk within the organization. The process is often adapted to the group of knowledge professionals that have the most influence, with the requirements of other staff and managers having less impact on the framework. Typical reactions from project staff range from ignoring the process framework to following it to the minimum level possible to avoid punishment from compliance watchdogs. In neither case is the desired behavior accomplished, knowledge workers leveraging the process framework to add value and reduce risk. 

Our approach is to take a different perspective on standardization. While it is critical is to define a common process architecture required for an organization to be successful, it is equally critical to ensure that those processes have unique policies based on the type of work being processed for particular types of work. A fundamental difference to our perspective is that we believe that standardization efforts should focus on the work itself, and that processes can only be a standardized to the extent that the problem domain and associated work can be standardized. 

We recommend starting the standardization effort with gaining an understanding of the different work types the organization must process. Work types can be thought of as a definition profile identifying delivery risk, size, technical skills required, and effort for particular category of work. Work types can then be associated with the exact policies required to facilitate maximum quality and better throughput/leadtime. This approach facilitates the development of a policy framework that is right sized to the work, and is flexible enough to change to meet the requirements of different categories of work.

Following a Big Design Upfront Approach

Stakeholders and managers tasked with running large-scale transformations face a great deal of risk. ROI might not be as high as anticipated, processes may not support certain scenarios, staff may resist change, and process components may be too lightweight or too heavyweight. A natural reaction to managing this risk is to try to come up with the perfect design. There is a desire to try to take into account every possible scenario, and develop the perfect target state solution. There's often a tendency totry to design any anticipated risks out of the solution. 

Unfortunately, the impact of locking down decisions before the right kind of information is available is just as risky as making a decision too late in the process. When a decision is made to early, it is largely based on assumptions. When the assumption proves to be false, it can be very challenging for a program to admit the error, and it can take many months to reverse the design decision. A program that has to much upfront design will be weighed down by unvalidated assumptions, these unfounded assumptions can cause the program to go completely off track. While it is important to do some upfront design, the key is to focus upfront design on decisions that are very expensive to reverse. Examples include overall organizational structure, process architecture, tool technology platform, and executive level processes. Even for these components, it is important to examine the underlying strategy, and separate fact from assumption.

Big Design up Front (BDUF) is also the antithesis of a Lean approach. Fundamental to Lean thinking is the notion that large amounts of inventory (unfinished work) causes waste. This waste materializes in the form of quality problems, unpredictable delivery lead times, and lowered throughput. When thinking about knowledge work, there is no physical inventory to remind us of how much unfinished work we have. In this case our unfinished work are all the requirements, plans, strategies, and design artifacts that represent a unit of change that has not yet materialized.

The more we try to create the perfect design the more we increase our inventory of unfinished work. Larger inventory delay potential downstream business benefits. More importantly, they reduce the feedback into the transformation process. Transformations are inherently variable, many things will not proceed according to plan. When dealing with something as ambiguous as the way people work, it is inevitable that designs will contain a large amount of assumptions. Our experience has shown that assumptions are only correct a small portion of the time. It essential that we test our assumptions as quickly as we can. This will tell us when we need to pursue a strategy, and when we need to pivot.

We recommend building the transformation vision and strategy in such a way that known facts are separated from ( well-intentioned) assumptions. A good transformation plan will contain explicit activities to validate each assumption through incremental adoption of specific process components using the piloting process. This approach forces working in smaller batches, allowing completion of smaller units of change more frequently. After each unit of change is completed, progress can be assessed, feedback can be gathered, and the overall approach and plan can be adjusted based on the latest information. We recommend running the transformation using a Just Good Enough Design approach. This implies implementing the design in small units using a testable approach, validating the results of specific tests, and then finally determining if any adjustments to the design needs to be made.

Centralizing All Design Decisions

Creating the perfect, standardized solution using a big upfront design approach is typically accompanied by the desire to centralize design decisions for the transformation program. In an understandable desire to gain the highest possible quality, many transformations assemble a dedicated group of very experienced experts, tasked with creating the perfect design. All design decisions are passed through a centralized stakeholder committee, where design elements are carefully reviewed, and the future target state is built.

Unfortunately, this approach does not scale to meet the diverse requirements of different groups. Centralizing design decision-making doesn't work for the same reason that a one-size-fits-all solution doesn't work, IT work is inherently variable, a unique mixture of technology, consumers, internal experience, and delivery risk exist across different IT departments, and even within different projects. Furthermore, IT work is not manufacturing, something slightly new is always being built. The above has two implications, for processes to be effective, they need to vary by context, and they need to continually adapt to changes in those contexts.

We have had great success following an approach that organizes processes and other design components as a hierarchical set of design elements. Centralized design decision-making focuses on the top of the hierarchy, on areas that truly need to be standardized across the organization. This includes the overall process architecture, overall organizational structure, role descriptions, and performance metrics. Lower levels of the hierarchy contain design elements that have a smaller span of scope. An example of the next level may be decisions and policies that affect individual departments. The next level down our elements that affect individual programs, and the bottom are elements that affect individual teams.

Policies and processes that only impact the individual teams can be designed, and followed by those individual teams. This also means that those teams are free to adjust those policies when they are nao longer supporting a high quality approach to delivery. Policies and processes that are project or departmental wide requirements appropriate manager intervention to modify, likewise design decisions at the top of the hierarchy require executive oversight to change. This approach, supported by a measurable and testable framework, insures that the organization is able to successfully adopt a continuous improvement approach while still providing a stable framework for the enterprise..

 

Transformation Demand Outstripping Organizational Capacity to process change

We have seen clients commit to transformation roadmaps without adequately considering the level of engagement required to successfully complete the plan. While a roadmap can look good on paper, it is important to assess the order and sequence of all activities against the capacity of internal staff to complete those activities and absorbed the change being asked of them..

Starting too many things at once will also lead to too much work in progress, which as stated previously is a primary source of waste for knowledge workers. We recommend putting a hard limit around the number of transformation activities that go on in parallel, and reducing that number if there is evidence that activities are not being completed in A timely fashion.

One solution is to operationalize the transformation engagement using Lean & Kanban techniques. This approach ensures that the organization will not start more work than they can finish, ensuring that the transformation team stops starting, and starts finishing.

Not Providing Adequate Support for Staff to Adapt to Big C Change Elements

Not all changes will be done in an incremental fashion. The targets may call for some larger, big bang structural changes to the organization and the way people work. This kind of change must take into account impacts to affected staff. This includes the time required for staff to acquire new skills, create new capabilities, bond with new departments, and otherwise absorb the change. Major changes to organizational capability, changes in job descriptions, and movements to new departments are tough on all involved. Is important to properly assess the impact of any of these changes on all staff and management before starting.

Focused, full-time expertise is required to provide communication and change management support to pull off these kinds of change. This includes appropriate communication, skills assessments, training, and organizational readiness. Dedicated professionals are required to take the time to ensure that the vision is communicated to all levels of the organization, areas of resistance are understood, enabling teams are identified, and that the change management approach follows a deliberate change management strategy.