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.

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.

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.

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.

Five Step Illustrated Guide to Setup a Kanban System in an Enterprise Organization

We've been through a significant number of Kanban implementations and our approach has largely been based on the approach outlined in David J. Andersons Kanban book. During our travels, we find that we sometimes need to make certain adjustments to the standard steps and during our recent work with a large-scale organizational transformation where we are applying Kanban across the entire organization of 200+ people we have encountered some situations that you only run into when you are in a larger enterprise setting. I thought it would be useful to others for me to provide a real-world step by step illustration of how we have been approaching the problem. If your about to kick-off a Kanban adoption in an enterprise IT organization or in the midst of one and struggling, you may find this useful. It's a simple 5 step approach that has always produced good outcomes for us while respecting the pace of change a typical IT organization can absorb.

Step 1) Identify the various upstream and downstream groups with a special emphasis on external "support groups" for the group adopting Kanban

In our scenario, we were helping an IT Development Group adopt Kanban. To start, we need to first identify who are upstream parties that give us work, in this it's the clients/business themselves that have a PM/BA function and there are 5 of them. There is one downstream group, the Release Support Group that is responsible for packaging, and pushing code into staging and production. The final group to look at is other support groups which tends to be a key consideration in enterprise settings since most IT organizations have moved towards functional consolidation. For this particular group, they rely on a DBA Support Group, and a Testing Support Group in order for them to complete their work and pass it to the release group.

Step 2) Identify the work types that come in from the upstream provider and work with the IT Development Group to agree on a set of standard work types to setup a "Work Type Filter"


One of the lessons we learned during our work with a number of teams is the importance to treat the work type analysis as a capability and not a one-time event. Work type requests evolve over time and the team needs to develop the capability to conduct this activity and evolve a standard set of work types. I find thinking of this as implementing a Work Type Filter for the team helpful so they understand it's a capability and mechanism they need to operationalize. Work type analysis tends to be always be an interesting conversation with the IT Development Group in enterprise IT settings since the development teams will have other "responsibilities" besides writing code. They are often called upon by the client or other groups to provide two types of non-development services, Consulting, and Vendor Support / Management. Since functional consolidation tends to exist in most IT organizations I have seen, some type of centralized PM/BA function is often responsible for gathering requirements and providing estimates and plans. These groups lack the technical knowledge to complete these activities and as a result seek out the development groups for help. The second type of non-development request is often Vendor Support / Management. Business demand for solutions often tends to be non-stable and peaks near the end of the annual budgeting cycle as they feel the pressure to spend their budget which causes demand to exceed internal development capacity which in turn leads to the organization running to scale up with external vendors to take on the extra work. This will generate some work for the development group as the PMs will often ask the group to provide technical oversight or support to guide design, coding and help with code integration and promotions. I find it extremely helpful to separate these non-development requests from development work types since they often cause noise in the system and impact capacity in a different way. Turning back to our real-world example, here's what we ended up with:

Step 3) Map out the internal value stream, and identify where hand-offs and coordination with support groups occur in the process


Now that we understand the boundaries of our Kanban system we can start digging into the internal workings and understand how everything connects. Value stream mapping is often a useful tool for this, but I find keeping it simple works best. The important part of this step is to explicitly map out where the "interface" to the team is with other support groups and understand what information / value / artifacts is traded (i.e. what the interface contract should look like).

Step 4) Visualize all work in terms of the standard work types, let the system run to understand throughput and then set WIP limits with an emphasis on the input queue and external support group columns


At the end of step 3, we should have a kanban board and we can start onboarding all the work the IT Development Group is currently working on in terms of the standard work types we defined for the Work Type Filter. I find many teams struggle with setting WIP limits right away, and they need to use the Kanban system for 2-4 weeks before they have the right comfort level to have this discussion. At that point, the throughput metric should be tracked as this will provide a helpful frame of reference to set the initial guesstimate for the WIP limits. The key columns I focus on with the group is the input queue and external hand-off columns. The rationale behind focusing on these columns is they are the interfaces to the outside world and we want to start setting some expectations and commitments around these as the IT Development Group needs their help to deliver work. The input queue keeps them fed and the hand-off columns keep them running. I often leverage the throughput metric to orient the team around a WIP limit for the input queue based on the simple guideline of only take in what you can finish.

Step 5) Expose the queues to the clients and help setup and operationalize a prioritization framework as a Prioritization Filter

At this point, we expose the queues to the clients and start pushing prioritization of work to the customer. We also find in enterprise IT settings, providing only a next/this month queue is insufficient for their planning process. As a result we often provide a prioritized backlog mechanism with two replenishment cadences, an annual/quarterly one for strategic/budget planning a monthly one for just-in-time decisions. This is where we often see the most churn and is typically the most challenging part of the Kanban process. Many IT organizations are great at prioritizing within one group, but across organizational groups is a struggle despite attempts at elaborate and agonizing prioritization committees/boards. To help with this problem, the Kanban system arms us with two pieces of information, a common unit of currency (the standard work types) and delivery throughput. Leveraging these two pieces of information, we recommend working with the clients to analyze all their known demand, break it down using the Work Type Filter into our standard work types, and then calculating the gap between demand vs capacity in terms of throughput. Once the gap is known, there are two options, scaling up with more external vendors or prioritizing the work. In this scenario, scaling up was not an option due to the tight deadlines and the ramp up time needed to onboard new resources so we had to go with the prioritization option. To help with the prioritization problem, we recommend holding a workshop to align the requests with strategic priorities for the organization and then applying a FIFO policy to these requests while considering true fixed date items. This provides a workable interim solution as it forces the clients to focus on today with FIFO. The goal is to get to a set of demand channels based on what's ready to go now or soon and set % allocation against these channels. We then provide the client an opportunity to adjust the % allocation during the monthly replenishment meetings.

After this step, you should have a fully operational Kanban system. Now the hard but fun part remains which is evolving it and optimizing it for performance.

Applying Lean Startup techniques to Kanban (or any other) Organizational Transformations

Eric Ries definition of a startup is as follows:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

By this definition the enterprise wide Kanban transformation that I am helping a client with can be deemed a startup initiative.One that could be optimized by lean startup standards.

Eric talks about how Lean startup techniques like innovative accounting, validated learning, analyzing engines of growth, etc can be applied to organizational change initiatives. These kinds of change initiatives are by definition wrought with extreme uncertainty. So I've decided to apply a couple of concepts from the LeanStartup toolkit to see of the model applies.

The notion of wether to pursue or pivot on a strategy is one of my favorites coming from Eric's great book The Lean Startup. Startups are constantly evaluating their progress using useful metrics such as cohort analysis to determine wether to continue with a strategy (pursue), or keep one aspect of the strategy the same, and fundamentally shift another aspect (pivot). In this case our objective was to grow Kanban usage, and maximize growth of active users for Kanban enterprise wide.

I ve mapped out our Kanban transformation, including all it's twists and turns below, and it looks like we have been following aspects of the pursuit or pivot model without realizing that is what it was.

• We also made many of the mistakes that many startups make according to Eric.
• We spent way to much time designing a solution, we actually knew this would be a problem, but are hands were a little tied by the client, That being said I was unprepared for how unhelpful the upfront design activities actually were
• We took a long time to make our first pivot, had we been armed with the model, we probably would have pivoted as soon as we saw the transformation was not going at the pace it needed to
• We could have been tracking the relationship between specific activities and Kanban adoption,and set up all activites using validate learning, this would have accelerated validated learning, and identified the need to pivot faster
• That being said our ability to pivot did increase dramatically over time. Our first pivot took 5 months, and then 3 months, then less than 2.

I think the Lean Startup model has huge application inside the enterprise, managing the many aspects of IT that contains a high degree of uncertainty.

Our next steps are to start tracking our initiatives and mapping them to non vanity metrics. We think tracking cohort users, and their usage of specific Kanban features is the way to go. We can do this thanks to the fact that all Kanban adopters are sing an electronic tools, LeankitKanban, as the tool of choice

Managing Your IT Portfolio Through Capacity Allocation

One of the interesting things about a delivery system enabled by Kanban is that you can think about how to prioritize work in a fundamentally different way than is traditionally done for software delivery.
In several IT organizations I’ve worked prioritizing IT work often takes some of the following characteristics. Capacity is completely consumed by large-scale transformation initiatives. Other work is often prioritized by whoever has the right connections with the CIO, or is able to yell the loudest. Maintenance, business as usual, and other business and technology related operational issues are either completely ignored/delayed, or completed under the radar with as little oversight as possible. Investment and training is either completely off the books, or rarely done. Sometimes, leadership tries to put a better system in place to help them prioritize these various internal/external demands. Often these systems comprise of complex prioritization mechanisms/frameworks where various attributes of a project (e.g. business impact, complexity, etc.) are used to force rank different projects against each other to come up with what the next piece of work should be. Clever customers quickly learn how to game the system, and pretty soon every project comes through as the one needing to be done next.
Kanban offers an alternative to the above scenario. When an organization is delivering software in a way that provides stable performance it becomes to possible to allocate portions of that performance to different profiles of demands. In other words, A Kanban system allows an organization to get out of the prioritization game, and get into the allocation game. An organization using kanban will have a number of teams/departments delivering a limited number of work according to the capacity limit (wip limit). This capacity limit may be expressed in user stories, features, use case scenarios, enhancements or whatever those teams recognize to be meaningful units of work. Regardless of what these capacity limits represent the inventory limits can be further allocated according to the overall objectives of the organization.

Having these preset capacity allocations make it much easier for various factions and competing needs to make decisions around what work should be completed next. As an example, a blue chip organization should probably be spending at least 30% of its capacity on business optimization activities, and perhaps 20% of its capacity on large-scale IT transformation projects. Imagine now that introducing a new large-scale business transformation initiative would cause the organization to be unable to reserve 30% of its capacity for these operational activities, and cause its capacity for transformation projects to bump up to 40%. In this case the new large-scale business transformation initiative would be deferred until an in-flight one had completed. Another option would be to allow the various transformation projects to start could sharing the capacity allocation to each other. Of course capacity allocations are not meant to be set in stone, but would require a higher authority/escalation to reset. In this way the question "what kind of business should I be in?" Is separated from the question "what should I do next with my available capacity?".
Some sort of governance mechanism should be in place to periodically reset capacity allocations amongst different business channels, different programs/projects.
..