Category Archives: Export

Uncertainty & the Scaled Agile Framework (SAFe™)

Estimated Reading Time: 3 minutes

What is the connection between Uncertainty and the Scaled Agile Framework?

Uncertainty is one of the core reasons we need to be agile. Different modes of Business/Requirements/Technology uncertainties impact our economic costs in product development – especially the potential impact of risk. The first principle of SAFe™ is “Take an economic view”. I frequently use my “uncertainty filter glasses” to take an alternative economic view. I find it helps Scaled Agile/SAFe™ practitioners/leaders understand both the need for Agility as well as examine various work system design considerations. In this article I introduce the Stacey Matrix which is one of my favorite models for understanding the uncertainty landscape as well as implications of uncertainty on various specific SAFe™ design decisions.

Making it Concrete – The Stacey Uncertainty Matrix and its relation to the Scaled Agile Framework


As I wrote about at some length in Risk-Aware Product Development (a.k.a Agile) explaining the concept of Requirement/Business/Technology uncertainty is one of the first things I do with most audiences I meet for the first time. On a Leading SAFe/SPC class this typically takes place in the first module when we go over the need for SAFe. This is not a core part of the materials but I take the time to explain it anyhow and then find myself referring back to it throughout the workshop.

The first layer of realization is that our problem with the classic approaches to product development is that they were built for complicated endeavors but not complex ones.

Then we layer on more interesting realizations like the fact that for some endeavors like those approaching the “Anarchy”/”Chaos” domains probably the best approach would be a “Skunkworks” style cross-functional co-located fully empowered small team. As you grow a bit farther from Anarchy you can scale agility using an approach like the Scaled Agile Framework. At these levels of uncertainty/risk the trade-off of distributed teams, distributed PI Planning, system team, component teams, shared architects/UX MIGHT make sense and are worth considering.

As you approach the simpler domain sometimes even the alignment rationale for “whole train” PI Planning can be reconsidered. Is that SAFe™ heresy? maybe. But I find that telling people “Whole ART PI Planning” is mandatory is less effective than showing them WHEN it has a better economic impact. (BTW as you grow in complexity/uncertainty you also need better people that are more engaged – which the Whole ART PI Planning helps with as well)

In general, this thinking helps leaders at these workshops grasp the various economic levers that go into tailoring a SAFe™ implementation. I find this disarms some of the resistance you get when people feel something is “a must”. Using this approach they typically go out with a stronger conviction to avoid some compromises and a better feeling about the compromises that do make sense.


To take another example of how I use the uncertainty matrix during SAFe™ training/implementation discussions – SAFe™ talks about a hierarchy between ART Product Management and the Product Owners working with the teams. A typical and sensible question people have is “Who should wear the Product Owner hat?”. Using the uncertainty matrix, we realize that in some cases the Product Owner should be a Product Manager (probably the top two quadrants of the matrix) and in some other cases he can also be a more technical leader (Especially on the far right side of the matrix). As the typical organization I work with is struggling to fill those Product Owner roles, this realization helps them deploy their people more effectively in a way that minimizes the risk of ineffective feedback loops due to the wrong individuals being in the tight Product Owner loop.

In summary

Understanding uncertainty and its attributes and implications is in my view and experience a critical step of buying into the need for agile as well as gaining the ability to design an effective agile approach for your context. Presenting the Stacey Matrix and trying to map it to your reality is one technique I used to help people gain this understanding. Using it as a decision filter/design criteria for further SAFe™ tailoring questions complements this initial presentation/exposure and grounds it. If you are teaching Leading SAFe™/SPC classes, explaining the need for agile to leaders/executives, or working with an organization to implement a scaled agile approach, I believe you will see improved results if you add this technique to your toolbox. I know I have.

Risk-aware Product Development (a.k.a. Agile)

Estimated Reading Time: 6 minutes

“There’s no predictability/commitment in Agile”

Over the years I’ve heard my share of these kinds of statements from various levels of executives:

“When my guys run a product development release I really want to know what I will get at the end so I can make business plans accordingly”

“In the old days when we ran projects we knew the timeline, we knew the scope, there were no surprises. These days it seems like the inmates are running the asylum. Product Management keeps telling me in this Agile way of doing things there is no committed scope, no plan, only ‘Responding to change’. I can’t help but think they are using it as an excuse for thinking short-term”

“When an important new/existing customer asks for a feature I really want to know whether I can commit to him that it will be delivered in the next release so I can get him to commit to a purchase”

“When you talk to people here, I want you to be very clear on the fact that agile will not take away the predictability they have so that they will not oppose the agile initiative we are trying to kick off”

This post is dedicated to you guys out there trying to make sense of the confusion surrounding predictability and Agile (Or as I often refer to it these days Risk-aware Product Development), whether you consider yourself one of the people quoted above or one of the people working for them trying to bridge the desire to work in an agile nirvana-like flow and dealing with those pesky executives stakeholders and customers bent on interrupting that flow.

Back to the roots

Let’s make it clear up front. I totally empathize with these executives. They are either already victims of “Bad Agile” or are basing their concerns off of a lot of “Bad Agile” going on out there. It is such a shame though because in reality agile product development actually maximizes the predictability you can have in your environment. Wait, That was a complex sentence. Why didn’t I just say “Agile provides great predictability” and get it over with? Because that won’t actually be true…

Let’s start from the beginning. Let’s talk about the contexts where agile approaches are required. One of the first things I discuss with executives is the concept of uncertainty and specifically Stacey’s Uncertainty Matrix.


Types of Uncertainty in Product Development

I explain the concept of Requirement/Business uncertainty as the chance that you are aiming at the wrong target and Technology uncertainty as the chance that you’ll have execution problems getting there. I then ask the people in the room to classify the projects they are currently working on and typically get a picture somewhat like the one above with different projects having different uncertainty profiles. At this point it is typically easy to get to the understanding that when you have low uncertainty predictability and success is a matter of careful and disciplined execution of greatly crafted plans.

Dealing with Technology Uncertainty – The Waterfall Passive/Buffered Risk Management Style

When uncertainty starts to mount, it is a different ballgame. Teams facing technology uncertainty with big batch waterfallish approaches only get REAL predictability (meaning the one that stays valid all the way through release of high quality product with the committed scope) through huge buffers.These buffers serve to hide those horrible big bang integration hells that are the source of statements like “We are totally on track all the way through development but when we reach the code freeze period all hell breaks loose and we don’t trust a word we’re told about when the product will be released”.

Dealing with Technology Uncertainty – The Agile Active Risk Management Style

Agile teams in this context should be able to provide predictability by weighing the amount of effort required to achieve the business expected outcome, taking into account the amount of uncertainty, and make some buffered plans at the high level before going into low-level iterative product development aimed towards achieving those high-level commitments. You not only get predictability of “If we said we will deliver this feature in this release then that is what we will do” you also get visibility of progress towards meeting that commitment by seeing working product frequently and getting reports based on real integrated progress.


Dealing with Requirements/Business Uncertainty

Here, definition of success is actually a bit different than what executives are used to. Success doesn’t necessarily mean delivering according to commitments. It means hitting the target if it is indeed a real target and alternatively learning as quickly and cheaply as possible if we are aiming at the wrong target. This is not some theory we’re talking about. Data from more than 50,000 projects suggests 50% of features developed are actually not used. (See Chaos Report 2013).

Is Predictability what we want?

So aiming at the right target is not a trivial task in Product Development, especially if you are in a more innovative space where it is not even clear that there is a market need for your product, but also when you are working on internal IT projects where this kind of uncertainty seems irrelevant… In the Lean Startup movement we typically talk about the “Build it and they will come” fallacy. Actually we are NOT sure they will come, so we want to be very careful with what we build without knowing. Predictability might be a dangerous thing to wish for in this environment.

The Risk Burndown Exercise


An exercise I often use to get this point across is to ask people in the room to draw a chart of the amount of risk/uncertainty in their projects from initiation all the way to the moment all risk/uncertainty has been exposed. the X axis reflects time or stages in their “Stage-gate process”. The Y axis is “remaining risk/uncertainty” in either the Business/Requirements/Technology domains. One answer I typically get is a line curving up at some point only to go down later on. That is impossible. Risk is there. If the line curves up what you mean is that you actually just become aware of the risk at that point. I guess this is the best indication of the fallacy of “predictability” people have. Others start with the maximum risk and then go down quite quickly – telling me that they learn everything they need to learn at the point of “Requirements/PRD/Design” and from then on it is a matter of execution. I then typically ask whether they find surprises/defects later on in the cycle and whether they actually know all of their features are in use. This typically gets them closer to the epiphany… Others get it by this point and draw a chart where a lot of the risk is there active until you finally get to have your software/product in the hands of real users. At this point the discussion very quickly gets to the main way to reduce the time of active risk – cutting projects/products into smaller pieces so they can get to be “Working product in the hands of users” faster. (Which is by the way one of the key differentiating factors of successful projects regardless of methodology according to the Chaos Report)

A reverse correlation between Business uncertainty and the need for Predictability?

Luckily enough it seems like Predictability is typically required when there is a strong business need on the other end of the line (if there is a partner/customer adamant on having that feature it kind of reduces the business uncertainty of whether it is a real need…). So effective classification of projects into the right uncertainty/predictability profiles will typically help satisfy the business executives without creating unrealistic expectations from the product development group. There’s still the need to understand you are sometimes running small “startups” or “venture capital” inside your product development portfolio, which might be tough for an execution-oriented IT/product development executive to fathom. Geoffrey Moore talks a lot about these kinds of struggles in “Escape Velocity”. Which is highly recommended reading by the way.


So, with all this in mind, what can you do?

My advice to executives is to make sure they and their teams understand the uncertainty profile of each of their projects and act accordingly:

  • When uncertainty is low, use whatever kind of process to deliver the desired outcomes with high predictability.
  • When dealing with technology uncertainty and medium/low requirements uncertainty (Sustaining Innovation) and it is desirable to be predictable, use effective agile release planning approaches to setup a reasonable plan with maneuvering space to account for some requirements/execution uncertainty using either a time or scope buffer (a set of features that are considered stretch / weight to be jettisoned in case of problems).
  • When dealing with serious business uncertainty (Disruptive Product Innovation space?) make sure that a fast iterative approach is used to minimize “building it before knowing whether they will come”. Learning needs to be  emphasized over predictability in these environments.



Guest Post – Is starting with Kanban really easier than with Scrum?

Estimated Reading Time: 4 minutes

Today I’m proud to host a guest post by another AgileSparks coach – Yael Rabinovitz. Yael has been working with several clients on Scrum implementations and has recently started using the Kanban Method (I wonder who gave her that crazy idea…) and is sharing her thoughts about the first steps into both approaches. Without further ado, here’s Yael:


Is starting with Kanban really easier than with Scrum?

Kanban is often described as a way to achieve evolutionary change in an organization, creating less fear and resistance than more “revolutionary” approaches such as Scrum. Kanban indeed respects current processes. For example, in its first steps it does not impose role and responsibility changes, but encourages continuous small incremental and evolutionary improvements to your current system. But is it really an easier way to launch a change process? Always? The last few Agile implementations I was involved with that used Kanban as a starting point made me contemplate this topic. Here are some of my thoughts.


Implementing Kanban seems to be simple technically. Just visualize your current process, build the Kanban board and describe your process as a pull system. Kanban does not prescribe specific practices, but the team is expected to apply lean thinking tools such as limit the WIP, focus on flow, optimize the whole, stop the line and fix (focus on quality), find bottlenecks, protect the team from external interruptions, etc. This requires high maturity from the team. Unfortunately, in many cases, teams find themselves struggling at the starting point, especially when attempting to apply the “limit the WIP” step. This can be extremely difficult and requires good collaboration and shared responsibility between the development team
and the PO in order to allow balancing demand and
throughput. When this collaboration is not mature, teams tend to get stuck and find it hard to move forward, which leads to frustration and increases resistance to the change.


Shape the path – Script the way

Scrum’s prescriptive nature is more suitable for such immature teams as it “scripts the way” (from “Switch” by Chip Heath & Dan Heath) and provides best practices and definitions of the processes to be followed (daily standup, planning, demo, retrospective, clear definition of the PO/team responsibilities). Scrum provides a practical framework that makes the mindset shift easier, as teams can rely on the framework in this “SHU” phase (“Shu-Ha=Ri see: The clear definition of the PO role vis-a-vis the team provides the needed collaboration and WIP is limited implicitly by defining the sprint’s backlog, which I believe teams find more natural to grasp.

Small work units

Another point to consider is the need to break features into small pieces or user stories. This is a huge challenge that teams usually struggle with from day 1 in both Kanban and Scrum. This is fundamental to improving the flow in the system, thus reducing cycle time in Kanban, and creates the building blocks of the product backlog and sprint backlog in Scrum. I find that Scrum guides you more safely and clearly in this task than Kanban, as the framework and practices for creating stories are explicitly built into the Scrum process. Questions like: who is the owner of the stories? When should the stories be ready? What is a good story? Who approves the results and when? The team has built–in answers when it uses Scrum as a starting point.

The energy for change

It is also very important to consider the “energy” that the organization needs to have in order to change. Agile practically requires the organization to “reinvent” itself and, in many cases, the beginning of the process is an excellent opportunity to do just that. At that time, the right levels of energy exist, with the “buzz” created by training and management’s attention, as well as the willingness and courage to make a dramatic move. Scrum suits this “let’s make a revolution” mindset much more than Kanban, which requires stamina, patience and long term thinking. Most teams don’t have the time and patience for ongoing improvement cycles – they want results now. They are willing to risk, speculate and go along with revolutionary ideas rather than patiently wait for evolution.

Early success

Being able to achieve small wins early in the process provides a lot of “back wind” to the process. Scrum’s sweeping nature allows identifying these small wins quicker, thus injecting positive energy into the process at a much needed stage. The adoption of cross functional teams and creation of a rhythm in the organization, with demos and retrospectives quickly gives a sense of progress. It is important to pick low hanging fruits and produce results quickly.

I found that in many cases, if a momentum for revolution exists both in management and teams, Scrum’s constraints are much better for keeping the teams focused and accountable. Once you reach a point where you have a backlog with well defined stories and you are mature enough to go to the next leap, it is time to implement Kanban in order to optimize the whole and focus on the flow of value across the system, improving your cycle time from start to end.

So, should we start with Kanban or Scrum?

The only right answer is: it depends. It depends on the organization’s state, the scale of necessary changes, the desired outcomes and the problems and pains that triggered the Agile initiative.

What I attempt to do in this post is challenge the widespread myth that Kanban is always the easiest way to start. I have found that, when management is on board with the right mindset, starting with Scrum can be safer and easier. The Retrospectives in Scrum provide the evolutionary mechanism Kanban advocates that allow the organization to continue and make small incremental changes and continuously improve beneficial aspects and weed out harmful attributes

Start with Kanban or Scrum but, since you are interested in this journey, it is important to start! Begin, keeping in mind why you started and what you are trying to achieve .We don’t want to waste our time with too much upfront planning anyway, after we begin the journey, the steps we should take to move forward will unfold.

“The Road goes ever on and on

Down from the door where it began.

Now far ahead the Road has gone,

And I must follow, if I can,

Pursuing it with eager feet,

Until it joins some larger way

Where many paths and errands meet.

And whither then? I cannot say.“…


Hobbits walking song, “The Fellowship of the Rings”,J.R.R Tolkien


Lean/Kanban approach to Teams

Estimated Reading Time: 6 minutes

To Team or not to Team?

If you look at the definition of Kanban or Lean, you wouldn’t find teams anywhere there.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs
emerge from self-organizing teams”

Scrum is quite clear about the topic (Quoting the Scrum Guide 2011)

"Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to 
accomplish their work, rather than being directed by others outside the team. Cross-functional 
teams have all competencies needed to accomplish the work without depending on others not 
part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and 

So, if you are a manager of an organization on the Kanban train of evolutionary improvement, what does it mean for team structure? Should you keep the current structure? Adopt the Scrum Feature Teams concept? Do something else altogether? How should you organize your people to be as effective as possible in delivering value for the stakeholders?

Teams as an emerging property?

I personally believe that even if kanban the tool doesn’t talk about teams (obviously since it’s just a visualization and process-driving tool), despite the fact that the Kanban Method for evolutionary change doesn’t talk about teams (obviously since it starts from where you are, respecting your current structure, letting changes be pulled from actual need), more effective patterns for team formation will emerge when Kanban is really used.

At their core, Teams affect communication bandwidth. They partition the organization to enable increased communication bandwidth among people in a team, while counting on the fact that communication bandwidth to people outside the teams is not that important. Since we are talking about people, not network nodes, teams also allow the communication bandwidth to increase, the longer the team is working together, due to the team formation model. I recently read “The Talent Code” where the behaviour of our brain around learning new skills using myelin to wrap neurons to increase bandwidth reminded me of how teams behave.

So it seems like teams can really increase our effectiveness, and everyone in a reasonably sized organization cannot even bear to think about getting rid of the partitioning, right?

Well some of the Kanban thinking says that since Kanban massively reduces coordination costs via hyper-visualization and the pull system, the size of teams can increase significantly. Since we advocate using classes of service to allocate capacity to demand, thereby maintaining flexibility, we shouldn’t allocate people to demand.

The main reason not to go to teams is that teams might be local optimization. If our workload/demand was certain, and the uncertainty as to what effort/speciality is needed to deliver it was low, we could build the teams that optimize our performance. If that workload/demand didn’t vary over time, we could maintain the same teams and still have optimal effectiveness. But since in most environments we are facing a complex system with uncertainty/variability in the workload/demand, as well as the implementation effort/speciality required, it seems like sustaining stable teams will cost us in some optimization.

Team Modes

In my recent conference talks (GOTOCPH, LKBE11, LKCE11) I provided my view on this question of team formation and Kanban. I described the following progression:

  1. Functional/Component Teams based on specialization
  2. Teams On-Demand – whenever pulling a new Feature for work, associate the relevant people with it. They will deliver that feature, and after a few weeks return to their home teams. This approach provides lots of flexibility, but typically has relatively high coordination costs. It also doesn’t really benefit from the improved communication bandwidth among the team members that you get from persistent teams. This is very similar to the Feature Driven Development team mode by the way.
  3. Project/Initiative Teams – whenever pulling a new Project/Initiative for work, associate the relevant people with it. They will work together as a virtual team for the duration of that project/initiative, and after a few months, return to their home teams. The benefits of this approach is lower coordination costs as the teams don’t change that often. In addition the people working towards the same business goal are working together. The communication bandwidth increases as well over time, as well as the feeling of purpose and alignment. On the other hand, flexibility goes down. It is harder to shift people into projects/initiatives. It is harder to shift people out. If there is significant variability in the specialization required along the life-cycle of the project, selecting the right team becomes hard. If you work on versatility of your people, or already have a great group of generalizing specialists, this will be less of a problem. It can also be addressed by keeping a slack of several people working outside of project/initiative teams, that can be easily shifted in and out of activities on demand. It makes even more sense if those people are your experts/heroes. I’m seeing this mode in action in several organizations.
  4. Teams pull work – The next mode is where you create stable work cells that are able to handle almost everything you throw at them. These work cells stay together as the main organizational unit, and pull work based on the next business option the organization wants to exercise, regardless whether it is to accelerate an existing initiative or start something new. Here the communication bandwidth grows stronger and stronger. The flexibility and agility to shift business priorities and help swarm to work in process remains quite high, but the internal team flexibility remains an issue. The same slack of people not associated to teams can help here as well. I’ve seen this specific mode in action in several organization, and it works great, assuming you are ready for the change.
  5. On demand teams – Wait, didn’t I mention this one? Yes, I did. The difference here is that assuming you somehow have a tightly knit group which already managed to create lots of communication bandwidths among the WHOLE group, you can have a win-win. Total flexibility and global optimization. This should be the holy grail of any manager of about 20-40 people I would imagine. A force to reckon with…

Mixing it up

You don’t have to decide on one model. Not all work is created equal, so not all teams should follow the same structure. Some interesting examples:

  1. 80% on-demand, 20% focused on an initiative
  2. 80% on-demand, 20% cross-functional work cell (A-Team)
  3. 80% project teams, 20% on-demand able to swarm to a team in distress and help, or join a team to teach them some new skill as appropriate.

Evolutionary Change

Some organizations will jump in, create work cell teams, and start working. I’ve seen it in action, and when you REALLY have enough energy in the organization to make this maneuver, by all means go for it.

Other cases you will not have enough energy. Or you will THINK you have enough energy, but reality will hit you in the face when all the middle managers / team leads that led you to believe they are on-board are not that supportive once it is time for action and for supporting the actual new structure.

So think hard about what is your case. And if you want to go for a more evolutionary change mode, consider the following:

  • Start with on-demand teams
  • Pilot one initiative/project team – especially useful when you have a risky initiative with a lot of uncertainty and dependencies, that is mission critical. Assign the success of this team structure to one of your best and most trusted people, if not yourself. Whether he is the Coach, the actual Lead, or something else is secondary. The important thing is that he will be in charge of making the team structure work, and together with the team make the learning from that available to the rest of the organization
  • Move to more and more initiative teams as necessary
  • When a project/initiative finishes consider turning the team to a work cell to pull more features in that area, or more features in general
  • Ideally, teams will have the capabilities to take almost all work on. If not, use a talent matrix showing what teams can do what and gaps to invest in. As well as talent matrix inside a team that will help teams grow some internal versatility (note not everyone on a team needs to know everything at the same level)

Cautionary Notes:

When creating teams be careful not to spread yourself too thin. If you have too many small teams it might be an indication you are not managing flow effectively at the Initiatives/activities level. I love teams of 4-5 people by the way.

If you find many people need to be on many teams, you have a real problem. It is ok for a minority of the people, especially specialists, to be needed by many teams. Maybe they should stay as auxiliary on-demand, while spending some of their capacity offloading knowledge to the teams. But if it’s not a minority, then you really need to work on versatility, or the on-demand might be a better fit. The whole point of the teams is to create the communication bandwidth. Without that, they’re just overhead.


I presented a couple of team modes here, as well as one way you can use them. This is really context-specific stuff, so I cannot tell what will work for your case. But I hope the modes help you relate the Lean/Kanban effectiveness principles to the options of team formation. In upcoming posts I will try to relate this to a couple of thinking frameworks I grew fond of lately (RightShifting? Cynefin?)

My thoughts on how Kanban and TOC Critical Chain relate

Estimated Reading Time: 5 minutes


I recently had a short twitter chat with Catherine Swetel and Steven Holt about the relation between TOC Critical Chain and Kanban. This post will try to sum up my thoughts in a way that is a little bit more persistent, as well as add a bit more color and depth that is not possible in 140 characters. To start with, lets just make clear – I’m no expert at TOC or Critical Chain. I’ve done my share of reading over the years and have seen organizations using CC and helped them explore the Agile/Kanban world. I’ve read Critical Chain for the first time back in 1996 or so and also familiarized myself with the MPCC S&T tree in the last couple of years. With that disclaimer, here are my thoughts, for what they’re worth:

Multi-Project / Program Level

If you start at the project/portfolio level, I see the Multi-Project Critical-Chain and especially its Strategy and Tactics tree as very similar to the Kanban System for driving improvement. Both approaches start with Limiting Work in Progress at the Projects level as key to reducing unhealthy multi-tasking and improving predictability and effectiveness. With time, excess capacity can be used to shape demand and create new exciting business models. I think the CC world is more advanced in its view on this aspect, but the Kanban world is certainly going there. We would be wise to learn from Viable Vision and other great thinking in the TOC world.

The Feature Design Factory

Once inside a project, kanban advocates a feature driven approach to development. The understanding that product development is a knowledge discovery process where units of inventory start as options and end up being working tested validated features is at the core of the Agile approach. The assumption is that we are operating in an uncertain environment. Both the requirements/problem as well as the technology/solution has considerable elements of uncertainty. We welcome this uncertainty as it comes together with the opportunity for great returns. We also recognize that Integration activities hide a lot of the risk in our projects, and so we drive for early and continuous integration to minimize that risk.

The way to operate effectively in this environment is to have a continuous process of focusing on a few features, seeking feedback along the development process all the way to customer/field feedback, orienting ourselves based on it iterating thru the same or earlier stage of the process depending on the feedback, and at the end having a marketable/viable feature that doesn’t hid any more work behind it. Only then do we pull another option/feature and drive it thru the process.
Kanban realizes that we have a certain capacity of features we can effectively process at any point in time. Overburdening this capacity will mean the knowledge discovery for each feature will take longer and the feedback will be handled later at a higher cost. I’m guessing this will resonate with any TOC practitioner. And indeed, the realization that features can be handled as inventory opens the door to applying a lot of the pure TOC thinking.

This approach can be used for handling an ongoing product development context where there is always plenty of options that can provide business value, and we are a factory/studio choosing the best option to develop and deliver.

Managing Projects with Kanban

When the context is a major project comprised of many different capabilities/features, this approach works as well. There might be a stronger need to manage the overall project health, but the basic principles still apply. There was an interesting discussion about this lately in the kanbandev user group. I also covered this in my recent talk about Commitments in a Kanban world. In this area, I believe CC provides us with good practices and tools – Release Burnup/CFD charts can evolve to Fever charts for each project, and an overall Fever chart managing the overall projects portfolio.

Typically, breaking projects to features will result in quite a simple dependency graph/pert chart. This is because the network is comprised of self-sufficient features. Sometimes though, Features do have dependencies on each other, or dependencies on external groups, as well as need to be delivered independently before the major delivery. When this list of dependencies grows larger and larger, maintaining a Critical-Chain view of the project/program together with relevant feeding buffers might make more and more sense. This view should only care about Features with dependencies, so it is typically quite simple, ideally managed as a Big Visible Chart on a project wall, a Look-Ahead plan, etc.

Kanban’s view of Specialists

Kanban and Lean/Agile in general recognize specialization as a root cause for lack of flexibility and an impediment on the way to business-driven agility. We advocate generalizing specialists and the use of healthy engineering practices to make sure more of the work can be done by more of our people. While this is a worthy vision / desired state, many organizations cannot economically achieve that goal, not in the near term, maybe not ever.

So we need to optimize how we involve our Specialists while we are aiming to reduce our dependency on them, where it makes economic sense.

We start by recognizing that each person, including Specialists has a certain capacity for spreading his attention as well as for actual delivery. Once we overburden this capacity we are abusing our scarcest resource. When we limit the work in the workflow we align the workload with the capacity in the line. But specialists that hover above the work like busy bees flying between flowers require a separate approach. One way is to limit the number of cards a specialist can be involved in. Once that limit is reached, he cannot be asked to be involved in a new card. So either manage without him, or wait with starting that work. Visualizing this involvement will already drive some realizations and maybe some investment in reducing the dependency somehow by knowledge sharing, offloading, etc.

Another approach I touch on elsewhere (including the commitment talk mentioned above) is to classify the work based on need for shared resource and affecting routing decisions based on that. So if a specialist or any other type of shared resource is currently congested, consider pulling work that doesn’t require much of his involvement. Or even better, pull work that will reduce your dependency on him in the future.


Well, These are just some thoughts, an invitation for future discussion. I believe there is potential for a lot of synergy between Kanban and CC, especially in the world of complex programs/portfolios. I especially urge the TOC/CC practitioners out there to explore the “Feedback Oriented” view of Agile. What we all need to remember is that the main thing about the Kanban method is that it is aimed at catalyzing evolutionary improvement. It is similar to the aim of the TOC S&T trees trying to drive towards a Viable Vision. Don’t get confused by the mechanics. The key is to use the conversations that happen when it is painful to follow an explicit process policy, like maintaining a WIP limit, to learn something and improve.

And if you are currently using Critical Chain and would like to explore what Kanban or Agile might mean or how they can help you, I’d love to help.