- Your Starting Condition
- The Kickstart Process
- The Kickstart Event
- Some Final Thoughts
- Tying It All Together
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Kickstart Event
Coaching Tip!
This overview was prepared for initiative leaders, and covers broad, general guidelines. Adjust to your context as warranted.
As with any initiative, adoption of Scrumban should start with some type of “formal” event. Though simpler to launch than a direct transformation to Scrum, some elements of “education” and setting expectations are still necessary to ensure a smooth start. All team members should be physically present for any kick-off meeting. This is obviously more of a challenge with distributed teams, so some consideration must be given to communications and visualization. The topics that the agenda for a good kick-off event should, at a minimum, address are covered in the following sections.
Introductory Remarks
The kick-off event is an opportunity to set the stage for what follows. Remarks should reinforce at least two key concepts.
First, you want to underscore that this effort is solely about introducing and employing Scrumban in the context of your current ways of working, and represents little to no change in existing work roles or responsibilities. It’s important to address this point up front to minimize the potential barriers to effective learning caused by fear or resistance to change.
Second, you should reinforce the fact that this event has just one achievable outcome—each team walking away with a clear visualization of how it works. As with threatened change, epic objectives create unnecessary psychological barriers. Communicating an achievable outcome up front will help engage participants early on and make the kickstart process considerably more meaningful. We define our “definition of done” for this step as follows:
- Each team member has a clear understanding of his or her team’s purpose.
- Each team has created a visual representation of its ongoing work and current workflow.
- All team members agree on their most important and relevant work policies.
Current Concerns
Service orientation lies at the core of the Scrumban framework, so it’s critical for teams to begin with a clear identification of their stakeholders and any dissatisfaction they might have. Getting stakeholders to work with you, instead of against you, is one of your greatest tools for achieving continuous improvement.
Though adjustments should always be made based on the context of your environment, Klaus Leopold recently articulated one approach for visualizing stakeholder relationships that seems particularly informative and useful for introducing Scrumban to an organization.6 Among the suggestions he offers are the following:
- Visualizing the power and influence of each stakeholder using different size cards.
- Visualizing the degree to which stakeholders support your initiative through a spatial reference point: The closer to the point they’re positioned, the stronger their level of support. Although Leopold’s article specifically speaks to stakeholder relationships relative to undertaking a change initiative in general, there’s no reason this approach can’t be undertaken for any initiative.
- Visualizing the frequency of the relationships among stakeholders with different style lines (e.g., dotted for infrequent or tenuous connections, other styles for different grades).
- Visualizing the quality of the relationship with special symbols (e.g., friendly or adversarial, healthy and strong or tenuous and weak).
Why engage in this evaluation of stakeholders? Because you need to understand your stakeholders’ sources of dissatisfaction, and find the most effective ways to work with them toward resolving those issues. In fact, teams should change their work policies and work visualizations only if doing so will help resolve areas of dissatisfaction.
Visualizing the dynamics associated with key relationships also creates a clear view of who holds the most power, the current state of each relationship, and the steps that must be taken to move closer to a solution. It helps prioritize an approach to resolving dissatisfaction.
Next-Level Learning
Evolving to More Advanced Practices
If you’re looking to apply an even greater level of calibration to the process, this arena is ripe for applying a model like the Cynefin framework to provide information on how best to manage a given relationship.
In most circumstances, it is appropriate to facilitate discussions around current issues. Simply invite members to identify the top three to five issues that represent irritants or impediments to their work. Any issues that relate to how work is done or how the team interacts with other groups can be set aside for possible discussion, as these represent way-of-working or policy matters the team will be addressing during the kickstart. Any others should be tabled, as they don’t relate to issues relevant to the workshop.
Defining Purpose and Success Criteria
Teams and organizations that lack a common purpose typically cannot achieve or sustain high levels of performance. Any exercise that moves them toward a common understanding of purpose and criteria for success is all that matters. I like to have teams answer the question, “Why does our team exist?”
You should skip this step only when you’re sure everyone agrees they’re on a common journey to pursue incremental change toward working more effectively.
Identifying How Work Is Done
The goal for this segment is to have teams gain a realistic understanding of their current situation—in other words, how they actually perform work versus how they think they perform work. We get to this point by introducing a systems perspective—by asking the team to visualize itself as a closed system having several basic components (Figure 5.8). This exercise may be the first time many teams acquire a realistic sense of the complexity of how work flows in and out of their domain, plus the full scope of what they’re responsible for producing on an ongoing basis.
)
Figure 5.8 Visualizing a closed system.
The team’s articulation of upstream demand represents which work they’re asked to perform, who makes those demands (internal customers, external customers, or a combination of both), how those demands are communicated, and what their relative frequency and quantity are. These understandings are used to categorize work types later in the workshop.
Defining the downstream end reinforces the notion of recipients as consumers or partners in a process, thereby reinforcing Kanban’s concept of knowledge work as service delivery. These initial definitions of system boundaries clarify the scope of the team’s responsibility—where their work begins and ends.
Articulating how the team performs its work should command most of the team’s attention. Teams should be guided to creating a simple, high-level visualization of the stages that each type of work must pass through before completion; this will be the foundation upon which their working board is built. Simple and abstract is the key—no more than 2–3 different kinds of workflows and no more than 7–10 stages in each.
Focusing on Work Types
A good kickstart process will incorporate activities that ensure team members acquire a common understanding of work types and their significance. It may be relevant to your organizational context to have teams identify and manage their work using predefined types, but in any case it’s important for the team to understand the nature of the demands placed upon them. Naturally, this is an ongoing process. Common modes of approaching this include assessing which work types meet the following criteria:
- Have the most value for their customers or partners
- Are demanded the most and the least (in terms of quantity)
- Are usually more urgent than others
- Are best aligned with the team’s purpose (the kind of work the team should do to a greater extent)
- Are least aligned with the team’s purpose (the kind of work the team should do to a lesser extent)
It may be relevant to your organizational context to have teams identify and manage their work using predefined types. Nevertheless, regardless of how you elect to proceed, it’s ultimately most important that they understand the nature of the demands being placed upon them. Naturally, this is an ongoing process. Common categorizations include the following:
- By source (e.g., retail banking, product X, maintenance items)
- By size (e.g., in terms of effort)
- By outcome (e.g., production release, analysis report)
- By type of flow (e.g., development, maintenance, analysis)
- By risk profile (e.g., standard work, urgent work, regulatory compliance)
- By relevance (how closely the work is aligned with team purpose)
Whatever scheme you choose, categorization provides a frame of reference against which an appropriate balance of work in progress can be created and managed.
Basic Management
It’s one thing to have teams begin visualizing how they work; it’s another thing to provide them with a framework for using these visualizations to discover better ways of managing it. I recommend using the GetScrumban game (Figure 5.9) to introduce teams to the basic principles behind managing their workflow. (Full disclosure: I designed this game.) It’s usually employed in tandem with other “classroom” exercises to illustrate and emphasize key principles and practices.
)
Figure 5.9 The GetScrumban game lets players experience the typical evolution of Scrum teams after introducing the Scrumban framework into their way of working.
Source: GetScrumban.com.
The GetScrumban game simulates how a software development team that employs Scrum as its chosen framework can use Scrumban’s core principles and practices to amplify its current capabilities, overcome common challenges, or forge new paths to improved agility. The game allows players to experiment with and experience the impact of these principles and practices:
Expanded visualizations
- Value streams
- Types of work
- Risk profiles
- Pulling work versus assigning work
- Evolutionary adjustments versus radical change
- Cost of delay versus subjective prioritization
- Distinct classes of service versus a single workflow
- Continuous flow versus time-boxed iterations
- Value of options
Whether you use an interactive tool like GetScrumban or employ some other mode of instruction, your teams should walk away with an understanding of the following:
Concepts Already Familiar to Scrum Teams
- Work items/cards (user stories): These are typically visualized on physical boards in the form of a sticky.
- Work size estimate (story points): As most Scrum teams already engage in some form of estimation, the concept of estimating (and the notion of breaking larger stories down into more manageable sizes) should be very familiar.
- Definition of done: A short checklist of standards that must be present for a work item to move from one column to another.
- Daily stand-ups: Scrumban stand-ups tend to eliminate declarations of status (what each team member completed, what the team member is committing to complete, and the identification of impediments) because all of that information is already visualized on the board. Instead, stand-ups evolve to focus on how well work is flowing and which actions the team can take to improve overall flow and delivery of value.
New Concepts
- Work type: Often represented by the color of a work card; reflects the mix of work in progress. Visualizing and actively managing the mix of work (i.e., standard user story, bug fix, maintenance item, estimations) is usually a novel concept for Scrum teams.
- Workflow: Columns on a work board represent the value-adding stages work passes through to completion. These usually start with “Ready” and conclude with “Done,” “Ready to Deploy,” or some similar terminology. Scrum teams often welcome this change because story progress and individual contributions toward it are made more visible.
- Pull: Though some Scrum teams may be familiar with pull-based systems, many others are new to this mechanism. Pull mechanisms avoid clogging the system with too much work. Rather than work being “pushed” onto a team by those with a demand, the team selects work to pull into their work stream when they have the capacity to handle it.
- Ready for pull: These “holding” areas are visualized as columns within a column. Typically used when a handover occurs (such as from a development phase to a test phase), they help manage bottlenecks.
- Definition of ready: A short checklist at the bottom of a “Ready” column that visualizes the relationship a team has with those requesting work. The definition should specify the information or resources a team needs to effectively begin working on an item. Though many Scrum teams may employ definitions of ready in their work, they are rarely explicitly defined and visualized within a working framework.
- Blockers: Flags that indicate when work on an item is suspended because of dependencies on others. Blockers are usually visualized as an additional sticky or magnet (pink or red) on a work item. The purpose is to call attention to such items so the team attends to removing the impediment. Some Scrum teams may already visualize blockers on their task boards.
- Classes of service: Different “swim lanes” used to call out different risk profiles associated with given work items. We can choose to visualize separate classes of service to reflect and manage risk better (e.g., helping to ensure higher risk profiles attract more attention from the team than lower risk profiles. Similarly, you may want to help the team recognize it’s okay to take longer to complete lower-risk items.
- Explicit WIP limits: Teams should limit the amount of work in progress at any given time. We can do this by establishing explicit WIP limits across the board, within each column (preferred), within each swim lane/class of service, by work type, by team member, or any combination. Limiting WIP improves flow efficiency (by reducing or eliminating the cost of context-switching, among other things).
Common Language (Optional)
If you’re looking to align Scrumban practices across a large number of teams, it’s usually beneficial to establish a “common language” around common concepts. It’s possible to borrow some terms from Scrum (for example, teams might all carry a “backlog” or items that are ready to be worked on). Similarly, it may make sense for teams working on different aspects of the same program to use the same visualization scheme and share common policies.
Visualization Policies
One of Scrumban’s core practices is to ensure that all work policies are explicit. We do so to ensure that everyone is on the same page, and that the work policies can be easily remembered and shared with others. Common practices include the following:
Work items: Most practices will be natural carry-overs from Scrum:
- Due date (if any).
- External reference (e.g., from a management/tracking tool).
- Size of work (e.g., story points or person-hour estimates).
- Start date (important to track for measurement purposes).
- End date (date work was fully completed—some metrics can be impacted by how you measure this, but any agreed-upon policy is sufficient when starting out).
Workflow: The basic elements should already be incorporated in the systems diagram the team developed earlier. Some columns may be adjusted and rows added, however, as the team’s understanding develops.
- Pull Criteria: Scrum practitioners familiar with Definition of Done can optionally break it up into more granular lightweight “Pull criteria” visualized as a combination of mandatory and optional conditions before which a pull can be made.
What not to visualize: Cluttering up your visualization with unnecessary items defeats the objective of bringing greater clarity and understanding to how you work. Although teams should capture as much of their work as possible, there can be legitimate omissions, as in the following examples:
- Administrative activities (such as meetings unrelated to ongoing work). However, there may be great value to capturing how much time meetings are taking away from actual work, or whether certain resources are more encumbered than others.
- Short, ad hoc work (5- to 10-minute requests or incidents). As with administrative activities, there can be value in capturing these items. Measuring the number of such work items in the course of a day or week could reveal a significant and ongoing demand that would otherwise fly beneath the radar.
Frequency of Synchronization
Daily meetings are as much a ceremony with Scrumban as they are with Scrum. Unlike in Scrum, however, teams can move beyond sharing status and making commitments to collaborating on impediments to workflow and recognizing opportunities for improvement. This requires the team’s visual board to be in sync with reality. Some development teams may be able to get by with once-a-day synchronization, whereas others will need real-time updates. Decisions made in this context can impact tool choices and other related factors.
Create a Working Board
The kickstart session is an ideal time to assist teams with setting up their working boards. The sooner a team starts to see and work with actual items, the more relevant the process becomes. This effort typically involves the following steps:
- Drawing the workflow: Creating columns that represent the value stream of the team’s work process.
- Creating the board: I recommend that the teams create the board together, whether it’s an electronic tool or physical board. This accelerates team learning and ownership.
- Ticket design: The information to incorporate on a work ticket will vary from team to team. We discuss these considerations in more detail in Chapter 7.
- Adding current work (self-explanatory).
This is also an ideal time for teams to establish their definition of ready and definition of done for work items and lanes. Ready definitions can be easy to neglect, but they help avoid potential blockages once work begins. Teams might also discuss prioritization, but in a Scrum context this issue should have been already addressed by product owners.
Way of Working Policies
It’s critical that all team members agree how work will be handled in their visual boards so that it is done in a consistent manner. Areas to address include the following:
- Which individual(s) will be responsible for managing the ready buffer (placing new work items in the buffer and prioritizing them for the team to address as capacity allows). This topic is not relevant for teams that continue to use time-boxed sprints.
- When and how the ready buffer will be replenished. For teams that continue practicing Scrum, this usually coincides with the sprint planning process. In complex environments, developing policies could become quite involved. The immediate objective is simply to have a workable starting point.
- Which individual(s) will be responsible for managing completed work (especially important when work is to be forwarded to downstream partners).
- How ad hoc work or requests from outside normal channels should be managed. Consideration must be given to the needs of the system making the request.
- When work should be pulled from the ready buffer (typically whenever a team member has capacity and can’t contribute to any ongoing work). Consideration should be included for managing WIP limits and what should occur if exceptions are to be made.
Most of these considerations involve assessing risk (addressed further in Chapter 6). Having teams explicitly address risk as part of the kickstart process is the best way of ensuring more considered management as they mature. At a minimum, teams should be encouraged to explicitly articulate how work will be prioritized and which considerations are expected to be addressed as part of this process (i.e., is prioritization based exclusively on market/business risks, or should the decision incorporate an assessment of risks associated with the underlying technology, the complexity of the work, the team’s familiarity with the domain, and other factors).
Limiting WIP
Coaching Tip!
This is an especially important topic.
Setting explicit limits on work in progress will be a new concept for Scrum teams, and the science behind this mandate can be counterintuitive. For teams already practicing Scrum, it may be beneficial to point out how the Sprint ceremony is an implicit WIP-limiting mechanic. The idea is not to dive into detail, but rather to provide enough of an overview so the team understands why limiting work in progress matters.
“Stop starting and start finishing” should become every team’s mantra. Pull mechanisms are one way to ensure new work items are started only when a team member has capacity to do the work, thereby enabling the team to eventually attain a stable WIP level that matches its total capacity. Explicit WIP limits are another strategy (but should really be reserved for more mature teams, as they require a more complete understanding and practice of many core concepts).
To help ensure system agility, it’s essential to maximize your options. The more tightly work is packed within a system, the less agile you become (tightly packed work reduces your available options to respond to changes in circumstances). Limiting WIP is one mechanism for maintaining a sufficient amount of slack to ensure a smoother flow through the system.
A commonly used approach when introducing teams to the concept of explicit WIP limits is to establish them based on available resources or some other factor that’s not associated with actual demand and capacity. As with most things, the best approach will be dictated by the team’s specific context.
As the team performs work, circumstances may call for violating WIP limits. These are learning opportunities, and should always trigger a discussion. Perhaps current limits are too low and should be raised. Or perhaps circumstances are such that the need constitutes a one-time exception. Regardless of the context, WIP limits represent an essential constraint that forces teams to improve their process and way of working.
Teams will confront some common challenges with regard to establishing and abiding by WIP limits (we address these in greater detail in Chapter 7). These include the following issues:
- Variability: In the form of demand, the work, the risks, and numerous other factors.
- Constraints: Constraints ultimately determine system capacity. In knowledge work, they tend to move around, making them difficult to identify and manage. This makes discovering and establishing the right WIP limits very challenging.
- Human nature: People are funny. They often mask their true desires and intentions in less than obvious ways.
Planning and Feedback Loops
Scrum practitioners are already used to daily check-ins. Employing Scrumban, however, presents the opportunity to shift the meeting’s focus from status and commitment to more proactive planning. The kanban board already provides status information and should detail who is working on what. Impediments should also be visualized. Consequently, the focus of the team’s discussion can shift to a collaborative effort geared toward identifying potential impediments, dealing with requested exceptions to policies, and otherwise addressing discoveries about how work is being performed.
If your Scrum teams are made up of inexperienced practitioners, it’s possible they don’t know whether their existing stand-ups are even effective. If the teams to which you’re about to introduce Scrumban fall into this category, the kickstart is an opportunity to help them improve.
Jason Yip, a principal consultant at the firm Thoughtworks, has effectively summarized patterns to establish for a good stand-up (easily remembered using the mnemonic GIFTS):
- Good start: Good stand-ups should be energizing, not demotivating.
- Improvement: The primary purpose of the meeting is to support improvement, not to discuss status.7
- Focus: Stay focused on the right things, which should be to move work through the system (rather than dwelling on pointless activities).
- Team: Good stand-ups foster effective communication and collaboration. If people aren’t helping one another during stand-ups, something is awry.
- Status: Stand-ups should communicate a basic sense of what’s going on. As previously noted, the actual conversations move away from this information in Scrumban (i.e., this information should be communicated through the kanban board).
Scrum’s time-boxed Sprint remains the main vehicle for coordinating the delivery of completed work and replenishing the team with new work. Over time, teams can opt to modify the process for replenishment and commitment to delivery (and even de-couple these cadences) to adopt approaches more focused on actual demand and capacity.
Sprint Reviews and Retrospectives are existing feedback loops within the Scrum framework that we tweak in some measure when practicing Scrumban. For example, whereas Sprint Reviews are focused on soliciting customer feedback on the delivery of completed product, in Scrumban we incorporate the concept of reviewing overall service delivery (borrowing from the Kanban Method’s Service Delivery and Risk Review cadences). Similarly, the Sprint Retrospective takes on more of the flavor of the Kanban Method’s Operations Review.
It is also important to mention the importance of conducting organizational level feedback loops, such as the Strategy Review cadence integrated within the Kanban Method.
Individual Flow (Optional)
Some of the concepts and techniques Scrumban employs to give teams greater control over their collective focus and workflow are not obvious and are sometimes counterintuitive. Devoting a portion of your kickstart program to techniques for managing personal workflow is one way to enhance appreciation of their effectiveness. Topics of particular relevance include the following:
- Managing energy and not time (introduced via the Pomodoro technique, for example)
- The power of habits in knowledge work (by way of a brief introduction to disciplined approaches in problem solving such as A3 Thinking, for example)
Wrapping Up
Kickstart workshops should always be closed with a summary of what the teams achieved and the next steps that will be taken moving forward. In all instances, some degree of continued coaching and guidance is necessary for teams to optimize their understanding and practice.