Systems Thinking Approach to Implementing Kanban (STATIK) for Scrum Teams

By: Agile Velocity | Aug 19, 2020 |  Agile,  Agile Technical Practices,  Kanban,  Scrum,  Team

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: 

  • Management struggling with how to address new role definitions like Scrum Master and Product Owner among other aspects of the framework. This causes anxiety and distractions for teams who simply want to get started working together. 
  • Teams jumping into Scrum without getting grounded on the nature and characteristics of their work or ecosystem. This often means the teams are just going through the motions and may be slow to build shared ownership of their work and outcomes.

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:

  • What is the purpose of the team? 
  • What are the products or services we provide and to whom?
  • What is the current way of working?
  • What are the sources of dissatisfaction?
  • What are the sources of demand?
  • What are our current capabilities?
  • How does work flow through the team/system?  
  • What kinds of services are there? 
  • How to design a kanban system that allows us to visualize and manage the work?

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”.

Here’s how it works – 

At a high level, STATIK involves the following steps:

  1. Understand ‘fitness for purpose’ and identify sources of dissatisfaction 
  2. Analyze demand
  3. Analyze capability 
  4. Model the workflow 
  5. Discover classes of service 
  6. Design kanban systems 
  7. Roll out – socialize and negotiate, measure, inspect and adapt…

Using STATIK with a Scrum Team

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. 

STATIK based team chartering steps
This is how I design the chartering agenda


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: 

  • What are the major characteristics of our Work, our Team, or our Process?
  • How do these characteristics impact our delivery? 
  • How do these characteristics influence our decision-making? 

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. 

Step 1: Understand ‘fitness for purpose’ and identify sources of dissatisfaction 

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

    • We have drafted a mission statement and team slogan
    • Our Values and supporting Norms are known (We believe in… Therefore we will…)
    • We have defined high-level Conditions for Success
    • We are able to serve the needs of the Customer 

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

    • We have exposed all relevant Sources of Dissatisfaction and/or things we struggle with
    • We have visibility to and understanding of Customer and/or Stakeholder feedback
    • A backlog for Improvement has been created or updated

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.    

Step 2: Analyze demand   

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

    • ID primary (if not all) sources of demand – including from whom/where, frequency, complexity, and impact of requests
    • Understand the various characteristics of the requests and how that translates into work in progress
    • Agreement on critical gaps or risks to our ability to effectively deliver 

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:

  • How frequently does demand come to us? (known as ‘arrival rate’ in Kanban)  
  • How complex is the work?  
  • How much variability do we have?  
  • What are our customers asking for? 

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. 

Step 3: Analyze capacity  

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

    • ID primary (if not all) sources of demand – including from whom/where, frequency, complexity and impact of requests
    • ID our Capacity to focus on the work at hand, including the core skills and capabilities needed to deliver. (Initial Skills Matrix developed)
    • Agreement on critical gaps or risks to our ability to effectively deliver 

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.   

Market of skills graphicThe 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. 

Team competency map example

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. 

Step 4: Model the workflow 

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

    • Visual representation of how work flows through the team – May start with “most common” items and/or “happy path” workflow, then iterated to refine for exceptions or more rare scenarios
    • Activities that provide the most knowledge are identified
    • Tag potential bottlenecks or gaps that will need to be resolved 

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. 

Step 5: Discover classes of service 

StoryAs 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

    • Key Classes of Service are defined, including prioritization, service level agreements, definition of done, etc.
    • Team agrees on all explicit policies (rules) related to each Class of Service  

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. 

Step 6: Design kanban system  

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.  

StoryAs 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

    • All Team members agree to an initial kanban system that will enable them to begin managing and improving the flow of work
    • The kanban system is visible* 

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. 

Step 7: Roll out–measure, inspect, adapt… 

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

    • Create a flipchart or other artifact reflecting:
      • Tools we need
      • Knowledge we need
      • Environments we need
      • People we need
    • Identify and communicate impediments to delivering a shippable product increment
    • Create the team’s Technical Backlog (user stories w/ acceptance criteria)
    • Communication plan/feedback loop for stakeholders 

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. 

Additional Resources

  1. David J. Anderson –  STATIK article –
  1. Mike Burrows – Kanban from the Inside – 
  1. Peter Senge – Introduction to Systems Thinking – 
  1. Luke Hohmann – Sailboat / Speedboat retro technique –
  2. David Hawks – Kanban vs. Scrum – How to Choose? –

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back