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 Great Wall of China was a program.

The Great Wall of China was a program.

Scaling Agile project management to large, complex endeavors requires an Agile Program Manager to address the big picture coordination of programs.  Program management is the discipline of coordinating and managing large efforts comprised of a number of parallel and related projects. Scrum leverages a concept called the Scrum of Scrums to perform many of the activities need for program management.  Agile Program Management is not just repurposed project management or a part-time job for a Scrum Master.

Agile Program Managers coordinate and track expectations across all projects under the umbrella of the program, whether the projects are using Agile or not. Coordination includes activities like identifying and tracking dependencies, tracking risks and issues and communication. Coordination of the larger program generally requires developing a portfolio of moving parts at the epic or function level across all of the related projects (epics are large user stories that represent large concepts that will be broken down later). Agile Program Managers layer in each project’s release plans on top of the program portfolio to provide a platform for coordinated release planning. Techniques like Kanban can be used for tracking and visualizing the portfolio.  Visualization show how the epics or functions are progressing as they are developed and staged for delivery to the program’s customers.

Facilitating communication is one the roles of an Agile Program Managers. The Scrum of Scrums is the primary vehicle for ensuring communication.  The Scum of Scrums is a meeting of the all of the directly responsible individuals (DRIs) from each team in the program. The DRI has the responsibility to act as the conduit of information for his or his team to the Agile Program Manager and other DRIs. The DRI raises issues, risks, concerns and needs. In short, the DRI communicates to the team and the Scrum of Scrums. The Scrum of Scrums is best as a daily meeting of the DRIs chaired by the Agile Program Manager, however the frequency can be tailored to meet the project needs.  A pattern I have seen used to minimize overhead is varying the frequency of the Scrum of Scrums based on project risk.

Another set of activities that generally fall to the Agile Program Manager is the development and communication of program status information. Chairing high-level status meetings, such as those with sponsor or other guidance groups, is a natural extension of the role. However this requires the Agile Program Manager to act as a conduit of information by transferring knowledge from the Scrum of Scrums to the sponsors and back again. Any problem with information flow can potentially cause bad decisions and will affect the program.

We will explore the role of the Agile Program Manager in detail. For now, it is important to recognize that the Agile Program Management is more than a specialization within the realm of project management or a side job a Scrum Master can do in his or her spare time.  Agile Program Managers need to be well versed in both Agile techniques and in standard program management techniques because the Agile Program Manager is a hybrid from both camps. Agile Program Managers build the big picture view that a portfolio view of all of the related projects will deliver. They also must facilitate communication via the Scrum of Scrums and standard program status vehicles.  The Agile Program Manager many times must straddle the line between both the Agile and waterfall worlds.


Recently my wife and I hiked the Jinshangling portion of the Great Wall of China, which was originally built during early in the Ming Dynasty. It was then later restored into what we now recognize as one of the most iconic portion of the Wall under Ming General Qi Jiquang. While the project to build the great wall was not exactly Agile and probably did not foster participatory management, this section of Wall is said to reflect the vision of Qi Jiquang, its product owner, which was different than other sections of the Great Wall. According to guides in the area, Qi Jiquang was based in the area and used his well-fed troops to build the wall (rather than other forms of staffing/servitude elsewhere). Qi Jiquang lived and interacted with his men on a daily basis in other sections of the Wall absentee product owners prevalent. Absentee product owners can’t provide their vision or motivate the team something that the great general knew.

Looking out at the some of the most iconic views of the Great Wall drives home the point that when IT and business work together to achieve a well-crafted vision, great things can happen.


The role of product owner is critical for ensuring that the rest of the business and the IT team work together effectively. It also requires significant effort on a daily basis. The product owner provides vision, mentors the team, answers questions, makes decisions about the product, communicates with the broader organization, negotiates resource contentions, coordinates business interaction and serves as a liaison to leaders. In short, the role is difficult and complex. So much so that I have suggested on more than one occasion that it is the most challenging role in Scrum. There are many potential pitfalls in Scrum, however potentially the most destructive and easiest to avoid is the overworked product owner. Overworked product owners will tend are less effective.

What happens when someone is overworked?  Sooner or later they will neglect something and cut corners. Some work gets jettisoned as they try to bring their life back to equilibrium. Overworking the product owner may lead to inattention to the team, neglect of grooming the product backlog, and unavailability or missed meetings. It is possible that the product owner will neglect their day job, however I have generally noticed that people tend to focus first on that portion of their job that is most important to their long-term career neglecting their role of the product owner on the  project.

The product owner role is challenging; to perform it in a manner that is effective requires effort and focus. Organizations need to ensure that product owners have enough of their time allocated to the product owner role. Work generally needs to be taken off their plate. The rest of the team needs to support the product owner so that obstacles are minimized. Avoid Overworked-Product-Owner Syndrome and make sure the person that is playing the product owner role has the time needed to focus on the project rather on the work they can avoid.