Need for a well formed team grows!

Need for a well formed team grows!

I have suggested that Kanban is team structure neutral.  The same argument can be made for kanban-y Scrumban. However as we move down the continuum towards a scrum-y Scrumban, the argument for having a well-formed team goes from good advice to urgent instance. A well-formed team has several attributes that increase efficiency and effectiveness.  As your Scrumban implementation becomes more scrum-y these team attributes become more important:

  • Bounded,
  • Cross-functional, and
  • Self-organized and Self-managed

A well-formed team will be bounded. In bounded teams, team members belong to the team and the relationships that they develop will be “sticky.” The team membership changes slowly, which allows the individuals to build trust and develop a firm understanding of mutual capabilities. Teams that develop a boundary tend to develop improved communication and cooperation leading to efficiency and effectiveness improvements.

Cross-functional teams improve delivery using Scrumban. Cross-functional teams spend less time negotiating hand-offs and tracking down who can or should do any piece of work, thereby reducing the potential for bottlenecks. Visualizing the flow of work through the use of a Kanban board helps to identify the skills needed and a guide communication and hand-offs. When a team has all of the capabilities they need to deliver, bottlenecks are far less likely to develop and persist for any length of time.

Self-organized and self-managed teams don’t need to wait for permission to make the decisions needed to remove bottlenecks or process constraints. Kanban, and by extension Scrumban, is slightly biased toward the inclusion of line managers in the day-to-day operations of teams. This tends to cause team members to defer decisions and seek permission. As Agile values and principles are inculcated into a Scrumban implementation it becomes easier for the organization to build trust in the team’s ability to make decisions without having to ask for permission, thereby building a better team.

The more Scrumban implementations leverage the Agile focus on bounded, well-formed, self-organized and self-managed teams, the more apt the teams will be to deliver value. The need to adopt Agile team structures becomes more intense as a Scrumban implementation moves closer toward the Scrum-y end of the continuum. In the end the concepts that describe an Agile team make sense in almost any Agile or Lean scenario. However, if you are leveraging a scrum-y Scrumban the need is even stronger.

River locks are a  hybridization.

River locks are a hybridization.

I will freely admit that I am positively biased towards Scrumban.  Scrumban reflects the combination of pull, visualization and Scrum into a powerful mechanism to guide and drive work.  Putting both the lean and Agile values and principals together yields something that is more powerful than either would be separately.  To quote Spiderman’s Uncle Ben, “With great power comes great responsibility.” When we create an implementation of Scrumban, we need to make sure the team understands how we will deal with the nuance in techniques and values that Scrumban requires.  As we combine both frameworks we must smooth the rough edges that the collision of languages can create.  There are four questions we need to understand and answer to create an effective Scrumban implementation. The questions are:

  • Accept interruptions or not?
  • Use times boxes or flow?
  • Include business people with IT?
  • Employ generalists or specialists?

Kanban and kanban-y Scrumban, while not inviting interruptions, at least provide a mechanism for addressing interruptions or changes in priorities while work is inflight. In Kanban: Process Improvement and Bottlenecks, we discussed how Kanban deals with interruptions.  The interruption or new piece of work will be placed on the Kanban board which immediately highlights the event.  An item of equal size currently in progress is put on hold to balance the equation.  Using the Kanban board ensures transparency by making sure that the team and all stakeholders understand the impact of the change in direction. Scrum, on the other hand, precludes interruptions by saying no.  Insistence on changing the work items during the sprint requires the team to top the sprint and begin re-planning. The rational for this behavior in the Scrum framework makes perfect sense. However the real life application of the nuclear options is never as easy.  No one likes to stop a sprint, but also no one likes to say no to important stakeholders.  Using Kanban’s explicit mechanism of addressing how interruptions are to be addressed is a typical component of Scrumban, but the team and the stakeholders need to understand how interruptions will be dealt with.

Scrum is conceptually built on the idea that work will be time boxed, while Kanban embraces continual flow with an explicit release trigger. The two concepts can be at odds, however when a team uses a compact time frame for a release (Kanban) or requires multiple sprints before delivering software to production, there is very little difference in explicit team behavior.  In both frameworks, work is committed to by the team, the team completes the work they have committed and then work gets delivered into production based on that commitment.  The difference in process occurs when the team gathers feedback either before the release (Kanban) or at the end of the sprint (Scrum).  Adopting time boxes within the flow tends to generate formal feedback earlier, while the visualization of flow makes sure everyone knows how work is progressing at a granular level.

Often Kanban is perceived as an internal IT process because it is silent on the role of the business, while Scrum explicitly calls out a powerful role for the Product Owner.  Most IT teams actively work to create ways for business stakeholders to participate.  Business participation leads to higher customer satisfaction and less rework (what is really needed gets built with less false starts). Most Scrumban implementations integrate the concept of a Product Owner or primary Stakeholder into the process in order to prioritize work, answer questions and review results.

Finally Kanban can be seen as perpetuating the use of specialists rather than the more Agile behavior of using specializing generalists.  In many cases, by explicitly calling out process steps on the Kanban board organizations can start to leverage Agile and Lean techniques as first steps on a process improvement journey that will ultimately unwind the use of specialization and silos.  The use of a Kanban board will identify bottlenecks. My personal experience with Agile and Kanban suggests that many of the bottlenecks will be caused by specialization.  The lean principle of Kaizen—part of all Scrumban implementations—will help guide the team and organization to break down silos and determine how to blur the lines between specialties.

Kanban, Scrum and the hybrid Scrumban use different techniques that make them look and feel differently. However, all three frameworks are focused on a single common goal, to deliver the greatest value to the organization.  All three pursue that goal by minimizing the level of overhead needed to deliver value.  The frameworks of Scrum and Kanban can be combined because the techniques are complimentary.  Teams only run into trouble if they don’t spend the time needed to understand how the rough edges that any hybridization will create are going to be smoothed over. In the end, creating a Scrumban hybrid is easy to understand, easy to use and a powerful tool to guide work.

Are pizzas and hamburgers in Peru the same?

Are pizzas and hamburgers in Peru the same?

Scrumban is a hybridization that results from a team’s, or organization’s need to address specific process or organizational constraints. We’ve examined a Scrum-y Scrumban instantiation.  Kanban-y Scrumban, on the other hand, is usually a reflection of a high degree of specialization of personnel (e.g. developers, business analyst, testers, DBAs . . .). Work is done by one specialist and then handed to the next specialist.  Kanban-y Scrumban helps improve communication and identify unbalanced processes that constrain the flow of work. A Kanban-y version of Scrumban would include the following features:

  1. Release Cadence: Scrumban that is more Kanban than Scrum will generate a continuous flow of work for some period of time. At some point the software will be released into production (or to the customers).  An explicit release cadence is generally a feature of this version of Scrumban.  It should be noted that a continuous delivery cadence is possible, but is very rare. Monthly, quarterly or semi-annual releases are very common.  There is no requirement for any other time-box.
  2. Pull and Work-in-Progress Limits: Each step in the process will have explicit WIP Limits and work on new items will only started if the step has capacity.   This is a common feature of all forms of Scrumban.  Unlike the Scrum-y version of Scrumban, unless you just beginning a project or completing a project there is no requirement that the Kanban board be cleared of in-progress work.
  3. Stand-up or Scrum Meetings:  The team holds a daily planning meeting in which team members address what has been completed, blockers and what is to be done next and by whom. When using any form of Scrumban, I find it beneficial to have team members move work from column to column on the Kanban board during the stand-up meeting.  Seeing progress reinforces motivation.
  4. Backlog Grooming: Backlog grooming and prioritization occurs as work is pulled onto the active portion of the board. The Product Owner (or proxy) should ensure that the backlog is continually prioritized, as backlog items will be addressed as capacity becomes available.  I recommend sizing backlog items small enough that they can move through tasks on the board in one to two days.  In Kanban-y Scrumban, there is no other requirement for estimation.
  5. Attack Bottlenecks:  If bottlenecks, steps in the process where WIP starts to build up, occur, you need to fix the problem. This might mean making process changes or reallocating team members. If this version of Scrumban is being used, swarming rarely occurs because the organization is highly structured with specialists in each development role.
  6. Release Demonstration/Review:  Prior to release, the team (lead by the Product Owner) will demonstrate and facilitate interaction with the software that has been completed for the release.  Many organizations couple the Demo/Review with a more formal user acceptance test (UAT) step, doing the demonstration then UAT. If you wait until just prior to a release to generate feedback, there is a substantial risk of rework.  One organization I recently observed uses a continuous approach to the review step, demonstrating as each unit of work is complete.

A Kanban-y version of Scrumban differs from a pure Kanban process predominately thought use of the daily stand-up meetings, backlog grooming and demonstrations.  The focus on flow will tend, over time, to put pressure on the organization to align the people into teams, and blur the lines of around specialties due to improved visualization of hand-offs and bottlenecks.  The use of teams will make tactics like swarming to problems easier to accomplish and will lead to increased flow.

Hamburgers and hotdogs in China are they the same?

Hamburgers and hotdogs in China are they the same?

Not all instantiations of Scrumban look alike.  Scrumban reflects the team and time box philosophies of Scrum and the flow philosophy of Kanban, combined. Teams hybridize Kanban and Scrum in various ways to address specific needs. A more Scrum-y version of Scrumban will have more of the team philosophies and techniques of Scrum and would include the following features:

  • An Abridged Planning Session: The team will need to select the appropriate number of stories that can be completed during the sprint.  The selection process will require some form of story-level sizing and estimation.  As in Scrum, the team’s goal is to clear the board by the end of the sprint.  Generally the team generally will not need to plan the stories at a granular level (tasks) because the Kanban board will reflect the steps required to perform the work.
  • Pull and Work-in-Progress Limits: Each step in the process will have explicit WIP limits and work on new items will only started if the step has capacity.   The Kanban board would begin looking approximately like the example below:

Kanban board when you begin scrum-y Scrumban.

Kanban board when you begin scrum-y Scrumban.

  • Stand-up or Scrum Meetings:  The team holds a daily planning meeting in which team members address what has been completed, blockers and what is to be done next and by whom.  When using Scrumban I find it beneficial to have team members move work from column to column on the board during the stand-up meeting.  Seeing progress reinforces motivation.
  • Swarm!: As noted in step one, the team’s goal is to clear the board.  Swarming behavior occurs when more than one team member gets involved in a piece of work or task so that it can be completed. If you have ever seen a bunch of ants take care of grasshopper, you have seen nature’s version of swarming.  What one ant can’t accomplish quickly, a coordinated swarm certainly can.  Swarming behavior reflects true team behavior rather than a group of unrelated individuals.
  • Attack Bottlenecks:  If bottlenecks, steps in the process where WIP starts to build up, occur as work flows through the process, the process must be fixed. This might mean making process changes or reallocating team members during the sprint. Swarming (above) is used if the problem is a temporary constraint and does not require a permanent process change.
  • Demonstrations/Reviews:  At the end of the sprint or time-box, the team (lead by the Product Owner) will demonstrate and facilitate interaction with the software that has been completed during the iteration.  The resulting feedback provides the team and organization with the information needed to make sure they stay on track. At the completion of the sprint the Kanban board should look approximately like the following example:
Kanban board when you end scrum-y Scrumban.

Kanban board when you end scrum-y Scrumban.

  • Retrospectives: At the completion of the sprint, the team should reflect on their performance and make adjustments to improve.  This is in addition to any process changes that were made to address bottlenecks.  A retrospective provides time for the team to reflect without an impending deadline.

A Scrum-y version of Scrumban may be confused with a visualized version of Scrum.  The primary differences from pure Scrum are 1) abridged sprint planning (less granular), 2) explicit WIP limits for each step in the process, and 3) a kaizen philosophy in which all bottlenecks are attacked and resolved as discovered.  The goal of Scrum-y Scrumban is that all the work that begins on the left hand side of the Kanban board will flow to the completed column by the end of the iteration, which is not necessarily the goal of kanban-y version of Scrumban.

The same, even though they're different.

The same, even though they’re different.

I got into a discussion recently about what make Scrumban, Scrumban.  I was discussing the concept with two other Scrum Masters whose teams were using Scrumban.  The problem?  The two implementations looked nothing like each other.  One had two week sprints and the other had no sprints, but rather featured continuous delivery.  Both of my friends are convinced they are doing Scrumban.  And they both are correct.

Scrumban is a hybrid creation that combines Scrum and Kanban.  There are very few rules that say that which attributes of each technique must be present to be one or the other.  Any combination of the two techniques can be called Scrumban.

Kanban to Scrum
Kanban to Scrum

Here are some the of similarities and differences between Scrum and Kanban:




Partial Visualization (Input, Output and In Process)

Full visualization

Full Visualization (Granular Process)




Time boxed Iterations

Depends on Iteration Decision

Continuous Flow

Sprint Planning

Depends on Iteration Decision

Dynamic Planning

Work Sized To Sprint

Depends on Iteration Decision

Work Minimally Size
(Sized for Flow)

Board Reset After Sprint

Depends on Iteration Decision

Board Persistent

Burn-down (Burn-up) Charts

Depends on Iteration Decision

Cumulative Flow

Management As Outsiders

Depends on Iteration Decision

Management As Insiders

The one (huge) requirement for any Scrumban implementation is the need to fully visualize the steps in the workflow.  The biggest hybridization decision is reflected in the decision of whether to leverage sprints or continuous flow as the central mechanism to control work.  A decision to use iterations will cause the team to leverage a number of other techniques from Scrum – making the version of Scrumban more Scrum like.  For example, if you choose iterations, then some form of sprint planning will be required and work will need to be sized so that it can be completed within the sprint. On the other hand, focusing on a continuous flow of sprints will require the team plan dynamically so that work can be added as capacity dictates and to use cumulative flow diagrams to monitor progress rather than burn-down charts.  The choice of sprints or continuous flow becomes a decision of how you are using process to influence behavior.

Scrum has an expectation of bounded, well-formed teams.  Scrum teams are cross-functional with members playing many roles depending on the need.  Teams are also expected to be self-organizing and self-managing.  Some organizations either can’t commit to this this type of structure or need time to transition.  Hybridizing Scrum by de-empathizing use of well-formed, cross-functional teams for specialists may make it easier to begin the transition towards a more Agile structure.  Is this an optimal solution? No. However it isn’t an equilibrium solution; left to its own devices no organization be able to hold this solution for long. In my experience, as teams learn how to interact within an Agile environment they will find innovative ways to embrace the Agile values and principles. Embracing these ALWAYS leads to an environment with stronger teams.


Mixing cultures provides a broader perspective

Scrumban is the combination of Kanban (lean) with Scrum (Agile) techniques. Each contributes different things to the hybrid framework. Kanban contributes a focus on flow, while Scrum contributes a focus on people and timeframe. Together, both focuses bring value to process improvement.

The flow focus describes how work moves through the development process.  The techniques that Kanban contributes include:

  • Visualization of Flow
  • Pulling Work Forward
  • Work-in-Progress Limits
  • Explicit Policies

Scrum describes how people interact and the timeframes for that interaction.  The techniques that Scrum contributes include:

  • Iterations
  • Bounded Teams
  • Retrospectives
  • Demonstrations

Both Kanban and Scrum have some similarities, such as:

  • Small units of work
  • Backlogs
  • Stand-up Meetings/Daily Interactions

In many organizations the differences between the two frameworks have been blurred already.  I observed a team that was using Kanban and wanted a mechanism to enforce the discipline of periodic feedback with their internal product team.  The product they produce has one primary release per year.  The development team negotiated with the product team to implement three week sprints bounded by a planning session and a hands-on demonstration.  In implementing sprints, sprint planning and demonstrations the team had veered from Kanban to Scrumban.  The team could have solved the feedback problem by implementing an internal release schedule, but the product team found the Scrum-based solution easier to understand and implement.

A second example I observed was a pure Scrum team that was struggling to identify the reason they were not completing user stories during every sprint. The team had identified the issue in multiple retrospectives, but had not had luck in determining a solution.  In the third retrospective they decided to use visualization of flow. They created a value chain map of their process.  During the next sprint they began tracking the flow of work on a paper Kanban board. This process made the problem very apparent. The team would begin a fairly large number of stories, and then late in the sprint, begin to have testers “test” the new code.  A bottleneck was created between testing and development.  The team solved the bottleneck by breaking stories into smaller parts, implementing WIP limits on development and then switching a developer to the testing role when the bottleneck began to appear.  This team veered away from pure Scrum to Scrumban to address a flow problem.

Combining Scrum and Kanban requires the team to take a broader process focus.  Kanban focuses on the flow of work.  The process of visualizing work helps to identify bottlenecks that slow the delivery of value.  Scrum focuses on how people interact.  Scrum puts people together in formal meetings and workspaces where interaction occurs.  Scrumban breaks the focus either on flow or on people to get the best of both frameworks.