When it comes to Sprint Planning in the Scrum framework, precision and predictability are paramount. Yet Sprint Planning based on story points and average velocity, while popular, has inherent flaws.
I recently had the opportunity to listen in during a LinkedIn/YouTube Live conversation between my fellow AV Transformation Coach Colleen Johnson and Roger Turnau, both seasoned Lean-Agile practitioners. Their discussion touched on various facets of Lean-Agile coaching methodologies, including visualizing working on Kanban boards and the challenges of scaling Agile in larger organizations.
As they discussed the frameworks and their respective principles, one intriguing question emerged in my mind: “Could Kanban and SAFe® actually be BFFs?”
We have developed a Kanban Excel reporting template for you to use when measuring Cycle Time.
This template is for a team to generate a cycle time and spectral analysis charts. The Cycle Time Chart shows the trend over time for cycle time. The Spectral Analysis Chart shows the frequency in which we are meeting certain cycle times.
Send us feedback: info@agilevelocity.com
Editor’s Note: This post was originally published in Oct 2012 and has been updated for accuracy for 2023.
STATIK (Systems Thinking Approach To Implementing Kanban1 2) can be a great technique to help teams get up and running quickly, even teams that are using Scrum.
Applying the STATIK approach leverages the first principle of the Kanban method, “Start with what you do, or know, now”, in order to help avoid over-thinking how existing work, structures, and/or roles “fit” within Scrum. To be clear, I am not talking about what is commonly referred to as “Scrum-ban”. Applying this approach designed for Kanban can dramatically accelerate the forming and improvements of a Scrum team.
As a long time practitioner and coach of Scrum, I’ve observed many teams struggle getting started with the framework. Change is hard for most people and we often get resistance at first. Even though the level of change is relatively low with Scrum, it can be a challenge for some teams to get started in certain environments.
A couple of anti-patterns I see repeatedly include:
Over the years I’ve tried a few different approaches to help teams get started. I learned about STATIK from a colleague several years ago and began applying it as a model for my Team Chartering workshops. I have used this approach to help teams form and establish norms for them to work toward–including how they will norm around Scrum.
The STATIK method helps answer the following questions:
For the purposes of this topic, I will be referring to the “kanban system” (lower-case ‘k’) rather than the Kanban (upper-case ‘K’) method, since I’m not limiting the use of STATIK to teams implementing Kanban. The kanban system represents the elements and boundaries of the team’s work. For a Scrum team, that may include from the point an item enters their backlog until the point they declare it “done”.
At a high level, STATIK involves the following steps:
Setting up the workshop: To make it relatable, I provide a “Story” card for each of the steps and set up a simple kanban board to visualize the activities as we progress through the workshop. For each Story, there are Acceptance Criteria that represent the activities that we will work through together and enable the team to agree on what is ‘good enough’ for the team to move forward.
As with any team activity or workshop, it’s important to properly set the stage and get everyone connected. A simple connection exercise could be to ask the participants to consider and discuss the following:
This gets them thinking beyond just “We do ‘X’” and opens up the door for the Systems Thinking aspect of this. *NOTE: Depending on the knowledge and experience of the team, you may need to provide a brief overview of Systems Thinking3. I’ve generally found it’s not a critical barrier to running this workshop, but a little overview never hurts.
The intent of this step is to explore the criteria that define customer satisfaction and define the “fitness criteria” such as lead time or quality. These determine how the customer evaluates whether the service or product delivery is acceptable, or “fit for purpose.”
When working with teams that are applying Scrum, I will adapt this step (since Scrum addresses these differently than Kanban) by discussing fitness criteria, as well as conditions for success and the norms that they will need to agree on in order to fulfill their purpose. The team will create their Definition of Done in steps 5 and 6 and establish appropriate mechanisms to measure and enable customer satisfaction.
This step can be facilitated as a single story, but I tend to break it into two separate stories so that the team has a full appreciation of their current state before moving on to the next steps.
Story 1: As team members, we want to define and validate our Purpose and our ability to fulfill that purpose, including conditions of success, so that we have a strong sense of our team identity.
Acceptance Criteria
Story 2: As team members, we want to discover areas for improvement, what our customers and stakeholders are saying, and delivery or quality challenges we are facing, so that we can be more customer-focused and start building a backlog for continuous improvement.
Acceptance Criteria
When forming new teams, Story 1 is a great way to get teams started and centered on their team identity. Prompting questions can be something like–“Why are we being formed as a team?”, “What do we stand for”, “How do we want the rest of the organization to view us?”.
At this first level, I try to emphasize fun and safety, keeping it light and even a little idealistic. Things get much more detailed and analytical later, so providing engaging and uplifting conversations right off the bat sets a positive tone. During this step, I typically encourage brainstorming, but will also work in some form of diverge-converge activity to get ideas generated and shared.
A few things that quickly emerge here–introverts & extroverts, visual thinkers & critical thinkers, as well as those who “just want to start doing the work” & those who “want to feel like we’re a real team”. Don’t try to solve or fix any of that. It is, in part, what will define their norms as a team.
When working with existing teams, Story 2 may be a bit more impactful. Hopefully, there is data/feedback available from a prior Retro and directly from customers and stakeholders to leverage. If so, we will pull in the relevant data and/or feedback and go through some sort of a “reconnection” activity, asking everyone to write a few stickies (physical or virtual) for each item from the past Retro, relating to how it impacts them or their thinking. We may do some dot-voting on items to see what people view as most important or impactful. If there is no prior feedback or data to reference, this presents an opportunity to do a Retro and seek feedback from others.
Before deciding what format would best serve the team, I probe into their norms and experiences. For example, if they’re not doing regular Retros–why is that? Or, maybe they’ve been doing them, but they don’t seem valuable or meaningful to everyone.
From here, I can then choose the approach that would be most impactful, rather than just repeating a technique they’ve seen before. One technique I find works well, in this case, is using the Sailboat/Speedboat format4. This is a great visual, metaphorical way of exploring how well, and under what conditions, a team is performing. We can glean insights and specific, practical ideas that will be used on upcoming steps.
If there is no recent customer or stakeholder feedback available, we will craft a simple survey or questionnaire that can be sent out. In this case, keep it simple, but try to create a sense of urgency so the team can get feedback quickly that they can use right away.
Story: As team members, we need to analyze sources of Demand, so that we have a shared understanding of who is requesting services/product from us and the characteristics of the items in our backlog.
Acceptance Criteria
Here we explore Demand. What are the characteristics and origins of our work? For a Scrum team, some may simply say, “we pull work from the backlog that our Product Owner has prioritized”. While this may be technically correct, we need to go beyond that to understand all of the sources of demand, as well as answering questions like:
I find it valuable to start with Stakeholder mapping. There are a myriad of formats, but I tend to start with a basic context diagram to visualize the team’s key stakeholders. Are they consumers or contributors, internal or external? Understanding these first two dimensions can help answer questions about how we communicate or interact, how frequently we interact, and where they fit in our overall workflow.
Once we understand Demand, we can then analyze the team’s capacity, or capabilities, to serve that demand.
Story: As team members, we need to analyze sources of Demand and our Capacity to respond, including the skills and capabilities we need, so that we have confidence in our ability to deliver effectively and optimize our work.
Acceptance Criteria
This is another step that I will adapt for Scrum teams. I will use one of two techniques: a) Market of Skills activity or b) Skills Matrix creation. My choice of technique depends on how I interpret the teams’ level of creativity or analytical preference.
The Market of Skills approach tends to suit teams that are more playful, open to exploration, or may have more of a “Clan/Collaborative” or “Adhocracy/Creative” cultural orientation.
Market of Skills is gamification that uses the metaphor of a market where you may sell goods. In this exercise, you are selling your skills and unique capabilities to your team members. When using this technique we may include a variety of skills beyond just the technical skills needed for the job. Someone may include musical skills or that they’re good at puzzles–this makes it fun and helps team members connect with each other on a personal level.
The Skills Matrix modeling may fit better with teams that are “all business”, very serious about their work and/or more of a Hierarchy/Controlling or Market/Competing cultural orientation.
A Skills, or Competency, Matrix activity is more direct and analytical. Step 1 is focused on identifying the technical and soft skills needed to do the work. Step 2 is to have each team member self-assess their competency level with each skill. Teams may choose how they want to reflect this–using a numeric scale (0-5), shading a quartile (see example), using symbols, etc. The key here is to encourage safety and honesty without judgment.
After each team member has self-scored, the entire team can then review the matrix and discuss the patterns they see. Where are the gaps or weaknesses? The team can then discuss how they will deal with that.
The bonus benefit of this technique is that the team can also use the Skills Matrix to identify knowledge sharing and cross-training opportunities. If a team member is an “expert” in a specific area where others may be novices, they may agree to form mentor-mentee relationships.
While these techniques are most commonly associated with forming new teams, I have worked with many existing teams that have never done this sort of analysis and benefit from it as well.
Story: As team members, we need to model how work, information, and decisions flow through our team/system so that we have visibility to where we will need to define explicit policies and potential bottlenecks as we design our kanban system
Acceptance Criteria
I often find this activity to be the most interesting and impactful, particularly for existing teams. When I ask “Does everyone know what our process is for getting things done?” everyone usually nods and says “yes, of course.” However, once they start visualizing it, it’s not uncommon to see multiple versions emerge. It’s not that people don’t know their process or how work and decisions flow through the team. But, until they start mapping it out, they hold a bunch of assumptions and interpretations that may or may not be valid. That’s the power of collaboratively modeling the workflow.
David Anderson1 recommends asking the question, “What activity gives us the most knowledge?” I love this question. It helps the team think beyond the tasks they perform and gets into the meat of their learning and decision making. Building “why” and “how” into the system is just as important to the “what”. I encourage teams to map this into their workflow/kanban system and to incorporate it into future retrospectives.
Depending on the size of the team, we may break out into multiple, small groups (diverge), then re-group to compare and contrast. Ultimately, the whole team needs to agree on a reasonable representation of how their work, knowledge, and decisions flow through their system. (converge).
For new teams, it’s obviously a little different. It can vary a bit depending on whether they are: a) newly formed, but experienced with the context or delivery approach, or b) new to everything – each other, the work, the context, etc. In either case, it’s more of a greenfield discovery activity and is generally done as a whole team rather than the diverge-convert approach. For new teams especially, it’s important to remind them that “perfection is the enemy of progress”, meaning we’re not going to get it perfect the first time. We just need to get it “good enough” so that we can start to do the work, then inspect and adapt as we go.
In all cases, it’s not uncommon that the team will identify multiple “what if…” or “yeah but…” scenarios. If time allows, explore those that may be critical or impactful. For the rest, we tag those as “exceptions” and may add an item to the backlog to iterate through those in the near future.
Story: As team members, we need to define the various classes of service that will require specific, Explicit Policies (rules), so that we are able to design our Kanban system to effectively optimize flow and give everyone awareness of the ”rules of engagement”
Acceptance Criteria
A Class of Service is a set of policies which describe how something should be treated.
These definitions provide clarity on how to prioritize items as well as what and how we may handle an item, how to decide which items are more urgent–needing to be worked immediately–versus items that can wait.
A common example for a Scrum team might be to define how they handle new development work versus product support or maintenance work.
Often, the sources of dissatisfaction activity can uncover new or different Classes of Service. Teams may also need to define items with different business risk profiles that need different policies. Class of Service definitions (Explicit Policies in general) help teams deal with potential challenges from stakeholders (e.g HIPPO or WSFL challenges), as well as issues related to flow, WIP limits, and bottlenecks.
Another common definition for Scrum teams is the Definition of Done. This is a form of an Explicit Policy and may be defined as a general definition for the team or it may vary depending on the rules or boundaries associated with a particular Class of Service.
This step is one of the reasons why I think STATIK is so effective. We don’t jump into designing the kanban system until we’ve done the discovery and analysis in the earlier steps.
Story: As team members, having now defined and analyzed the primary nature and conditions of our work, we need to design our kanban system, so that we can begin managing and improving our way of working
Acceptance Criteria
Scrum teams often take the value of a well-designed kanban system for granted. After all, the Sprint is set and the Sprint Backlog is our “To-Do”, so all we need is to show “Doing” and “Done”. Right? Well, not always. Scrum was designed to deal with complex, adaptive problems.
So, our kanban system should be a proper representation of the complexity and adaptiveness that the team needs to manage. Many teams have both new development and production support to deal with, multiple products that they’re responsible for, or multiple external dependencies that cause wait states or other flow variances. The more complexity that a team has to deal with often means they need a more sophisticated kanban system.
There is no right or wrong way to design your kanban system. I encourage teams to be creative and emphasize the things that enable flow and collaboration.
To close out this workshop, we do a “team priming” activity. This activity was co-create with a former colleague of mine, Daniel Lynn. He and I have paired on countless workshops and engagements.
Story: As a team, we need to be able to start doing and measuring our work and find out what our current impediments are so that we can hit the ground running and ideally be able to deploy an increment or change to production in our first sprint.
Acceptance Criteria
In this step, we discuss whether the team will maintain both a physical and electronic kanban board. Most, if not all, of the electronic tools have both Kanban and Scrum views built-in. I encourage teams to maintain both a physical and electronic board (often within a tool like Jira or VersionOne) for a while to give them both the tactile and electronic experiences in parallel. It’s much easier to experiment and update a physical kanban board than to change a template in a tool.
However, given the global remote workforce trend (new normal), having a single physical board is not as feasible as it once was when we had more co-located teams. So, instead I recommend using a virtual “whiteboard” tool, like Mural or Miro, or something simple like Trello, that can be easily modified and experimented with in lieu of a physical board.
Roll it out, socialize it, experiment, and… inspect and adapt.
Whether you’re launching a new team or already working as a team with Scrum or any other approach, consider trying STATIK to see if you can gain better awareness, alignment, and visibility into how the team works.
What ideas or concerns has this article raised for you? If you’ve tried and/or adapted STATIK with your team share your experiences and insights below.
The Kanban Method is a powerful way for Agile teams and organizations to visualize work, identify and eliminate bottlenecks, and achieve measurable operational improvements in throughput and quality. This article is a Kanban cheat sheet identifying best practices, meetings, and key terms.
Visualize the work
The Kanban Method is a powerful way for Agile teams and organizations to visualize work, identify and eliminate bottlenecks, and achieve measurable operational improvements in throughput and quality. A Kanban board can be maintained electronically within a tool or manually on a wall. Kanban boards can be team-specific, represent multiple teams, and even entire departments and organizations. The work visualized can be of any size tasks, stories, features, initiatives, projects, etc.
Limit WIP (Work in Process)
Limiting WIP allows us to reduce context-switching that can harm our team productivity. WIP Limits are applied to specific activity steps within the team’s process as typically modeled by a Kanban board. A WIP Limit is also known as a “constraint”, but not in a negative way. Teams do not have unlimited capacity, so think of WIP Limits as a descriptor of our reality within the work process and focusing mechanism.
Manage Flow
The main point of Kanban is to visualize how value flows through the system. This value is typically modeled as a work item card. The speed and smoothness of the work item movement across a Kanban board should be monitored and discussed in an ongoing manner.
Make Policies Explicit
Until rules are made explicit it is often difficult to have a discussion about how to improve. Making policies explicit helps create a shared understanding about how teams will move work through their system. Explicit policies for Kanban may include WIP Limits, Definition of Ready, Definition of Done, approval processes, and general team working agreements.
Implement Feedback Loops
Kanban is an evolutionary process of continuous improvement. The sooner we can get feedback, the quicker we can pivot if needed. Daily standups, replenishment meetings, delivery planning meetings, and retrospectives are a few practices teams can implement to set up feedback loops.
Improve collaboratively, evolve experimentally
Improvements should be small incremental changes over time that build on themselves and effectively fine-tune your team’s flow of value. Once teams have established their Kanban board and are using it, many opportunities for improvement will arise including removal of bottlenecks, creation of smoother flow, reduction of cycle time (from work start to Done), reduction of lead time (from request made to Done), throughput improvement, and variability reduction/increased predictability.
While Kanban does not prescribe any specific meetings, many Kanban teams use the following meetings to ensure alignment of effort.
Purpose: Team coordinates activities for the day which helps ensure they are working on the right priority items
Example Agenda:
The team walks the board, starting right to left, and provides an update to each other on progress and current WIP. Consider having the team answer:
Purpose: Create shared understanding of the work and keep team members focused on the most critical work that needs to be done.
Example Agenda:
Purpose: Team reflects on how they are working to identify opportunities for improvement and feedback
Example Agenda:
Card/Task: Visually represent work items of value. Cards contain information about the work item. They are not different in size because the idea is to break a project down to its smallest tasks and complete them quickly.
Cumulative flow diagram: A visual chart/diagram/report which shows throughput, cycle time, and WIP. Agile tooling can create this for you.
Cycle time: Begins at the moment when the new arrival enters “in progress” stage and somebody is actually working on it until it enters the Done column.
Explicit Policies: Facilitates consensus (agreement) around improvement suggestions and minimizes the chance of misconceptions and lack of understanding.
Feedback Loops: Represent the circulation of info and change between (and during) the team’s meetings (daily standup, replenishment, and retro).
Kanban: The word literally means ‘signboard’ or ‘visual card’. In the late 1940s, it became a term for Toyota’s inventory management system and later evolved as a process management method.
Kaizen: The Japanese word for “continuous improvement”.
Pull System: No new work is started until started items are finished. When there is capacity, a new item is pulled in.
Swimlanes: The horizontal divisions of a Kanban board, helping to optimize the workflow. The columns represent steps, and swimlanes categorize work. Swimlanes can be used to represent classes of service, projects, etc.
Throughput: The number of items, passing through a system or process. According to Little’s Law, Average Throughput = Average WIP divided by average cycle time. The throughput of your team is a key indicator showing whether your process is productive or not.
Work In Progress (WIP): The amount of work in flight at the same time.
“Individuals and interactions over processes and tools;
“Working software over comprehensive documentation;
“Customer collaboration over contract negotiation;
“Responding to change over following a plan.”
For those of us in the Agile community, the Agile Manifesto is a wonderful expression of the True North of Agile software development – empowered teams, swarming to solve customer problems by collaborating closely with people who will actually use the things we’re creating.
But for many, especially those who deliver software in highly regulated environments, the Agile Manifesto can seem downright hostile. When dealing with audit requirements and compliance, the thought of Working software over comprehensive documentation can result in Agile processes being dismissed out of hand.
With the pace of change happening in the world, that would not only be a shame, but organizations working in highly regulated environments would miss the opportunity to get ahead of competitors by leveraging Agile processes and principles.
Regulations – Prescriptive vs. Descriptive
When working in a highly regulated environment like healthcare, financial services, or dealing with reporting and regulatory audits for the US Federal government – I find it incredibly important to use a quick mental filter to understand the types of regulation my teams are working with. Broadly, I’ve found that regulations and their associated reporting requirements roughly fall into one of two types: Descriptive rules and Prescriptive rules.
Descriptive rules seek to provide a definition of a system or process as it is so that it can increase the repeatability of that system or process. I’ve found the most frequent examples of these Descriptive rules used in internal auditing processes and also emerge in quality processes such as the ISO 9001 Quality Management standards.
A key factor in adopting Agile in regulated environments where Descriptive rules are in play is to make sure you work closely with whatever auditors you have, internal or external, who understand your documented processes. When I’ve introduced Agile processes into ISO 9001-compliant organizations, I quickly began close collaborative conversations with our auditors to make sure they understood the interactive and incremental processes we were introducing. Once we identified the gaps and differences in the documented process, I worked with our auditors to make sure our new processes were properly documented. Descriptive rules are made to be changed to meet the work, not to prescribe solutions! (SPOILER ALERT: We’ll cover those in a second.)
Working with clients who primarily deal with these descriptive rules, I frequently look at the artifacts we can provide while using Scrum. The controls provided by a strict SDLC, especially around documentation, audit-ability, and traceability, can nearly always be met through well-written Acceptance Criteria and a light hierarchy of Epics to User Stories to Tasks. Further, most Agile software tools like JIRA, VersionOne, and Rally can provide for and automate the traceability documentation from Epic to production.
While Descriptive rules are designed to document a system as-is or as-it-should-be to provide a reference for a repeatable, quality system, Prescriptive rules are designed to create contracts and govern behavior. In organizations and teams ruled by Prescriptive rules, the sea-change in process and procedures introduced by Scrum can seem insurmountable.
As Agilists, it’s important to remember that while Scrum may have emerged as the most popular of the Agile frameworks – to the point where most people mentally equate “Agile” and “Scrum” – it’s far from the only Agile methodology or framework. When working with teams dealing with Prescriptive rules – such as those legally mandated by Federal agencies like the Food and Drug Administration or Securities and Exchange Commission – I nearly always fall back to Kanban.
Many of us conflate Kanban with the task board our Scrum teams use to make our daily work transparent. Kanban is a powerful Agile framework designed around documenting existing processes and applying rigorous focus toward maximizing flow. Using Kanban, we can find opportunities to incrementally improve our existing teams and processes.
By applying the principles behind Kanban, teams working under the constraints of Prescriptive rules can quickly adopt the principles of Agile.
While this isn’t an article about applying the Kanban principles and practices to your work, the practices themselves require embracing the Agile principles we know and love while also respecting the reality of the environment your teams exist within. Kanban’s practice of Visualizing the Workflow aligns perfectly with Agile’s embrace of transparency and openness; Limiting Work-In-Progress (WIP) closely aligns with the principles of simplicity and frequent delivery; Improving Collaboratively directly maps to the principle of regular reflection and improvement.
By using Kanban to map out your process, and then collaboratively look for opportunities to reduce bottlenecks and increase flow while also making and keeping process policies transparent and explicit, you can leverage Kanban to bring agility to your team and still meet Prescriptive rules and regulations.
When done well, Agile practices provide the means to create engaged and empowered teams who understand and embrace the need for regulations – both prescriptive and descriptive – and the means for those teams to own and optimize how their work is done while still meeting audit-ability, traceability, and regulatory requirements.
For more on our approach to building lasting business agility, you can check out our Transformation Services page.
Traditional product backlogs can get confusing. They typically start off with a high-level list of features, called “epics”. However, as the team starts decomposing the epics during refinement down to sprintable user stories, it’s easy to “lose the plot” and the only person with the decoder ring is the Product Owner (PO). The PO is the only one who knows how all the stories tie back up to the feature and how they relate to each other. One resulting failure pattern is incremental deliveries that create poor user experiences. This is because the release was composed of stories that in principle were of high business value but were functionally dependent on stories that were of lower value and were therefore deferred to future releases.
Presented at Keep Austin Agile 2016, William Baxter explains how a true Agile transformation goes beyond the team level and team practices through his experience coaching a media company in New York City. The case study presentation explores the good and the bad, the successes and failures. A favorite tip you can implement right away? Adding team faces to your board to humanize the process and conversation. This is especially important for distributed team members.
Tesla unveiled the next addition to its premium electric vehicle family, the Model 3, last week. At $35,000, Elon Musk made good on his promise for an “affordable” EV option and the public has responded by exceeded expectations for the slow rollout. According to Bloomberg, there are more than 325,000 reservations giving Tesla Motors Inc a nice $325M cash asset infusion. Implied future sales make it the “single biggest one-week launch of any product ever,” according to the company’s blog.
Even though the EV will not be available until late 2017, buyers reserved their very own Model 3 for $1,000 pre-test drive.
Is this Lean in action?
It’s an interesting situation that we’ve analyzed as outsiders** and Lean advocates. In Lean Startup, you eliminate uncertainty around your product by testing your hypotheses. The product becomes an experiment that is tested instead of something that is slaved upon, tweezed, tweaked, and perfected. Deliver value, get feedback, adjust, deliver.
We’re not saying that Tesla is a startup but looking at how it’s launched its latest product, it has similarities. Instead of creating 400,000 cars at a very high cost (one battery is about $10,000), they created a few for the launch and then began to take orders and therefore gauged interest.
Does Tesla now have $375M in revenue? Car and Driver explains that each reservation is completely refundable and it’s not counted as revenue until the car is delivered. Tesla will use the deposit money for launch and operating expenses but all of that cash is technically considered a debt.
With Tesla knowing that there is sufficient interest in the Model 3 and money to help with the rollout, it’s a safe bet to say the next two years looks pretty good for the company. In Lean Startup terms, they conducted an experiment, learned that their consumers are interested, and at the same time managed to bankroll their launch. Not too shabby!