Team of Teams

Time has come for another book review. The Summer is, for me at least, time for reading and reflection. I’ve seen the book ”Team of Teams” been recommended within the agile community, and therefore it caught my interest. I really liked ”Turn the Ship Around” by L. David Marquet, retired from U.S. Navy. This book is written by General Stanley McChrystal, retired from U.S. Army. The subtitle is ”New Rules of Engagement for a Complex World”. It holds some 250 pages, and was released in November 2015.



The book consist of 12 chapters divided into five parts. The chapters are:

  1. Sons of Proteus
  2. Clockwork
  3. From Complicated to Complex
  4. Doing the Right Thing
  5. From Command to Team
  6. Team of Teams
  7. Seeing the System
  8. Brains Out of the Footlocker
  9. Beating the Prisoner’s Dilemma
  10. Hands Off
  11. Leading Like a Gardener
  12. Symmetries

So what is this book about? I find this quote in the foreword: ”Management models based on planning and predicting instead of resilient adaptation to changing circumstances are no longer suited to today’s challenges”. The main story told in the book is the one about General McChrystal’s experiences from leading the Task Force in Iraq in their war against Al Qaeda. How they were badly beaten and had to change the whole organization from silos to to a network, to be able to succeed. The primary lesson that emerged, was the need to scale to adaptability and cohesiveness of small teams up to the enterprise level. General McChrystal calls this ”Eyes On – Hands Off” leadership. Meaning supervising of processes ensuring that silos or bureaucracy that dooms agility were avoided, rather than focus on making individual operational decisions.

Some new vocabulary, for me at least, from the military is used throughout the book. One example is ”limfac”, that stands for limiting factor (the one element in a situation that holds you back). I will start to use that!

For a very long time the focus of management have been on efficiency. Getting the most of a desired output (y), with the least available input (x). Now the focus needs to be on adaptability.

”Efficiency is doing the things right; effectiveness is doing the right thing.” – Peter Drucker

Sadly, in many cases still, the opposite holds true. Greatly summarized in the sentence: ”Great landing, wrong airport!”, that I’ve seen heavily shared within the agile community.

How we set up physical space really matters, and is reflected in how people work and behave. ”If you lock yourself in your office, I don’t think you can be a good executive” is a quote by Michael Bloomberg found in this book.

I chapter 9, The Prisoner’s Dilemma is introduced. From a management perspective it has interesting implications. It suggests that there are circumstances in which cooperation is better than competition. This seems obvious, but many managers assume that the healthy competitiveness between companies (that is the lifeblood of the free market), also shall be used within companies. People and departments within a company needs to see the whole to be able to cooperate fully, without having their own ”hidden agendas” (that can be the case in many companies today). The infamous problems with the car models Chevy Cobalt and Pontiac G5 (where GM had to recall 800,000 vehicles in 2014) is summarized with the following sentence: ”It was a perfect and tragic case study of the consequences of information silos and internal mistrust”.

Instead the following quote from Alan Mullally, CEO of Ford, leading their successful return in the market during recent years, shall be a guideline:

”Working together aways works. It always works. Everybody has to be on the team. They have to be interdependent with one another.”

Sandy Pentland, a MIT professor, states the two major determinants of idea flow; ”engagement” within a small group like a team or department, and ”exploration” – frequent contact with other units. In other words: a team of teams.

Finally, how should a leader lead? General McChrystal belief is (and I totally agree) ”leading like a gardener”, meaning:

  • Shaping the ecosystem (instead of ”moving pieces on the board”).
  • Delegate decisions to subordinates.
  • Creating and maintaining the teamwork conditions (”tending the garden”), a delicate balance of information and empowerment.
  • Drive the operating rhythm, with transparency and cross-functional cooperation.
  • Shape the culture.
  • Focus on clearly articulated priorities by explicitly and repeatedly talking about them.
  • Leading by example (it is impossible to separate words and actions, so they have to ”be the same”).


”The leader’s first responsibility is to the whole.” – General McChrystal

In summary the ”Team of Teams”-book tells very many stories, from the Army and the industry. Some of them appeals to me, other don’t. Overall the message told in this book really resonates with my own believes regarding teams, and how they should interact in a larger context! If you are interested in teamwork, and the war against Al Qaeda, you should buy this book.

All the best,
 Tomas from TheAgileist


The Blooming Garden

Yesterday, Agila Sverige (Agile Sweden) 2017 ended. As usual, I’m full of impressions and ideas that I want to try out! Maybe I will come back to this years’ conference in an upcoming blog post, but for now I want to share with you a metaphor that was used, and that I now have written about.


To develop software products is like having your own garden. In the garden you have trees, bushes, flowers and maybe a little pond with fish. All of this needs to be looked after, and you need to remove the weeds to get your flowers to blossom.


I got a little help from my daughter with this illustration 🙂

In software development it’s easy to constantly add new features and functions to your product. This will make your garden grow and grow. A real garden has boundaries, maybe there is a fence to the next door neighbour, but these doesn’t exist in software development. In theory there is no limit, in practise there is.  How do you keep up with this continuous expansion? Hire more ”gardeners” you might say (in the form of architects, developers, testers and so on). That works for a while, but at some point in time the garden will grow wild, and will be impossible to handle. So to add things, you also need to remove things. Maybe that little pond needs to be filled with mould so that new tulips can be planted? In my experience with software, removing something is a much harder decision than it is to add something new.

Technical debt

Another term for this is technical debt. Adding new functions comes with a debt in the form of other work that needs to be done in the product (we can see this symbolically as to ”remove the weeds”). If this debt is not repaid, it will keep on accumulating interest making it hard to implement changes later on (hence your garden will ”grow wild”). All products always need a certain degree of ”gardening”. The problem is that this fact tends to be forgotten when you constantly want to add new functions and features to your product.

In the garden you will plant the seeds, pour over water, keeping your fingers crossed for good weather and then wait and see if it will grow. According to the law of nature, not all seeds will germinate. It’s the same in software development, where you implement a new function and see if it gets adopted and used by your customers. Some of the things you do will be successful, while others will fail. Beforehand it’s very hard to guess what will be successful, but don’t be afraid of failure. Without trial&error there is no innovation. If you always ”play it safe” you will become predicable and your competitors will eat your lunch (or even worse, your company)!

A product is a complex system, you can compare it to an ecosystem in nature. When a new species enter the ecosystem the balance is disordered. What I want to say is that even if your new function in your product is great, adding it can lead to unwanted consequences in surrounding systems/products. Maybe a bottleneck in the communication now shows up between the systems. Of course this goes internally in a product as well (seeing the product as a full ecosystem). Adding a high throughput import adapter to your product may all of a sudden make your history searches painfully slow. Going back to the garden example, planting of some new bushes may attract snails that eat up all of your tulips.

Seasons in software development

In Sweden we have four distinct seasons; spring, summer, autumn and winter. During the winter everything is on low heat literally, since it’s freezing cold! When spring comes along everything is wakening up to life once again. During summer everything is warm and verdant. Autumn is colourful and time for harvest. Maybe your industry has some kind of ”seasons” or repetitive cycles as well? Instead of fighting against them, use them to your advantage! During ”winter” when everything is going in a slower pace, use that for planning and thinking ahead, whilst also taking care of your technical dept. Develop the new functions during ”spring” and release them for customer usage in the ”summer”. ”Autumn” is time for reflection to be able to start a new cycle with ”winter” again. See it as a big wheel that keeps on turning!


You can’t just keep on adding new things without taking care of the stuff that you already have. This is pretty clear to us in general life, but in software development it’s tricky since there are no physical boundaries. If possible, try to use seasonal variations in your industry to take care of your technical dept. 

All the best,
Tomas from TheAgileist

King of Kanban


I’ve seen that a poll function have been added to Twitter for quite some time now, but I haven’t tried it out. Until recently, when I used it to ”scientifically” (well…) investigate how common Kanban is.


You can always question a result of a poll. During the years I’ve written quite a lot about Kanban, and maybe therefore gained followers that are also into it. The ”sample size” (16 answers) may not be representative either. However, Kanban is used by more than half of the responders, so there must be a lot of usage and interest out there!

Before we start, I must admit that the title of this blog post is heavily inspired by the great documentary ”King of Kong”. It you haven’t seen it, and you are into retro-gaming, you must do!

Alright, do you want to become King of Kanban (or Queen for that matter)? Continue reading!


So how do you learn Kanban profoundly? There is a bunch of ways, and how you want to go about it, is mostly your personal taste, and how you pick up knowledge in the best possible way. You can for example read blog posts (maybe you have your own list of Kanban front-figures that you follow?), see videos from speeches (many conferences are very kind and publish them online afterwards), or look at presentations at Slideshare (that many use to share their material). Maybe I can come back and guide you in this arena in a later blog post, but for now I would like to focus on books, reading good old fashioned books!

Some years ago I made a challenge to myself. Search on for ”Kanban” in the books department, sort by relevance, and buy & read all books on the first page! I was about to make it, but I think you can guess what happened. The first page changed… So I had to buy and read more books. Nothing wrong in that, but my challenge could not be fulfilled. Now I’ve put that aside, and instead here is the list of books from Amazon that I have read and reviewed on this blog (the search referenced below on were performed May 14, 2017). In the headlines below – First is actual position in the listing, the title of the book and within parentheses the year it was released. Ok, so here we go!

King of Kanban – Books

#1 – Kanban (2010)

This is still, very rightly, the most relevant Kanban book, written by ”the father of Kanban” David J. Andersson back in 2010. Many books on Kanban have been released after this, but ”the blue book” still stands as the one must to read, if you want to learn about Kanban. As I wrote in my review: ”Is this the book about Kanban? Yes, it is. David J. Anderson is the undisputed king in Kanbanland.”

#2 – Real-World Kanban: Do Less, Accomplish More with Lean Thinking (2015)

This books holds four case studies in of improving using Kanban. I would go for this as a fist book if you want to learn Kanban, but when you have gained knowledge and want some tips to take Kanban further this is a good source of information. From my review: ”It’s always good to hear real-life stories, this is the most effective way to learn I think.”

#3  – Personal Kanban: Mapping Work | Navigating Life (2011)

Jim Benson (one of the authors of this book) worked together with David J. Anderson for a period of time. While most of the Kanban community focus on teams and larger, this book applies Kanban to your personal work, using only two of Kanban’s core practices: Visualize your work & Limit your Work-in-Progress (WIP). As I put in in my review: ”This book gets really personal about Kanban! I’ll recommend it to all knowledge workers that wants to get priority, productivity and efficiency into their work and personal life.”

#5 – Kanban in Action (2014)

This is my personal favourite amongst the books about Kanban! I’ve read it several times. It sort of changed how I see things, and even how people anticipate me, as you can read in the review that I end with: ”I can truly recommend ’Kanban in Action’ to anyone that wants to know just the slightest bit about managing knowledge work. From the first moment I started reading it, this has been my holy bible of Kanban!”.

#6 – Agile Project Management with Kanban (Developer Best Practices) (2015)

If you are into agile project management and Kanban (as I do), you don’t need to look any further. This is the book you should read! I’ve picked up quite a few tips from this book. From my review: ”If you are into project management and Kanban this is a true gem! The length is perfect for an agile book, 160 pages.”

#7 – Learning Agile: Understanding Scrum, XP, Lean, and Kanban (2014)

This is a book I only picked up, because of the challenge. It’s quite cumbersome and now as ”agile” I want a book about Agile to be. As I state in the review: ”If your are new to Agile, and have a lot of time to read, I can recommend this book to get more knowledge about Scrum, XP, Lean and Kanban. If you only want to know about a specific method, or have short of time, there are other more suitable books around.”

#9 – Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact (2014)

This books takes another angle into Kanban (than the other books), it uses nine values to introduce it. The nine values are: Transparency, Balance, Collaboration, Customer focus, Flow, Leadership, Understanding, Agreement and Respect. Actually, I met the author, Mike Burrows, at a conference and got my copy signed 🙂 . I end the review with the following: ”If you’re into Kanban you should definitely buy this book! I wish I’ve had it (and especially the knowledge from part III) when I implemented my first Kanban system.”

#11 – Essential Kanban Condensed (2016)

This is (to my knowledge) the newest book about Kanban. If you are totally new to Kanban, you may want to use this as a first starting point. Actually I end my review with: ”You should definitely read ’Essential Kanban Condensed’ if you want to get up to speed in what Kanban stands for and represents today (as of 2016).”

#13 – Lean from the Trenches: Managing Large-Scale Projects with Kanban (2011)

I read this book long before I started blogging so therefore I don’t have any blog post review of it. In this book Henrik Kniberg shares his learnings from the PUST (”Polisens mobila Utrednings STöd”)-project at the Swedish national police authority. Cross functional teams, ”Daily cocktail party” (with team- and sync-meetings) and the project board are for example described in this book. This book is a case study of a very successful project, however six years have passed, and things may be done differently nowadays.

#14 – Kanban in 30 Days (2015)

As hinted by the title, the chapters in this book are divided by days in in a fictive month (30 days) to learn and start using Kanban. It’s a nice angle, but there is no problem in reading the book from cover to cover (it has 106 pages). From my review: ”All in all, I was positively surprised by this book! It covers what you need to know to get Kanban stated and running.”

#19 – Kanban and Scrum – making the most of both (Enterprise Software Development) (2010)

This is the second book from Henrik Kniberg. His first (and the one that really started my Agile journey back in 2008) was ”Scrum and XP from the trenches”, my review of the second edition of this book can be found here. This book simply compares Kanban and Scrum. I’ve read this one also, before I started blogging.

#21 – The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban  (2015)

This book covers a lot of topics, it has 384 pages! However, from my review: ”This book has good structure, well written texts and a lot of illustrating figures. However, I think the overall purpose, to explain Scrumban, gets lost when describing all the surrounding agile practices. Keeping it simple is a virtue.”

#22 – The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (2013)

Compared to all the other books in this list, this one really stands out. It is a novel and the story starts when Bill Palmer gets promoted and become VP IT Operations at the company Parts Unlimited. The company is really struggling, and a gigantic project named Phoenix is launched in order to save Parts Unlimited. It’s not really a book about Kanban per say, but it is in there, from may review: ”A novel and the story presented in this book is a very pleasant and nice way to to learn new things. If you want to now more about DevOps I can really recommend this book!”


If you like reading books you should now have some ideas on what to read to become King (or Queen) of Kanban! Take care, and see you next time!

All the best,
Tomas from TheAgileist

Doing It

I first learned about Ralph van Roosmalen and his work when I participated in a video chat about ”Exploration Days”, hosted by Jurgen Appelo. Ralph is passionate about Management 3.0, and now he has written a book about his learnings called ”Doing It – Management 3.0 Experiences”. The book has 157 pages, with foreword by Jurgen Appelo, and was released in 2017.



The book consists of 13 chapters, and I thought that I should give you a short description to each and one of them.

1. Management 3.0? Huh, what?

Ralph starts out with setting the arena and tells what Management 3.0 is. In short: ”Management 3.0 is about engaging people, improving everything, and delighting the customers.” This short and to the point introduction also have references for more information.

2. What is the role of a Manager?

Management 3.0 highlights six areas for you as a manager to focus on:

  1. Energizing people
  2. Empowering teams
  3. Aligning constraints
  4. Developing competence
  5. Growing structure
  6. Improving everything

3. Move your Motivators

This chapter introduces The Moving Motivators game. This is connected to the first management area: energizing people. It has ten motivators (the CHAMPFROGS model):

  1. Curiosity
  2. Honor
  3. Acceptance
  4. Mastery
  5. Power
  6. Freedom
  7. Relatedness
  8. Order
  9. Goal
  10. Status

4. Surprise your team during their next review?

When it’s time for the review meeting, the first question you ask your team member is, “How are you doing?” They respond, “Er … good…” Then you say, “Okay, why good?” “Just good, you know … good.” Does this sound familiar?

Do you recognise yourself in the quote above? Then this chapter can help you make the review meeting fun again.

5. Traditional HR combined with Management 3.0

Here you will learn more about Delegation Boards. ”In short, just think of them as a spreadsheet that vertically lists the decision areas that you want to delegate to others, while the horizontal axis sets the amount of independence a team lead has.”

6. Implementing Cudo Cards

Next up is an introduction to Cudo Cards, a peer-to-peer rewarding system.

7. Visualise values and name your team

To get a team together you need to find the team values and then visualise them. Here you find concrete tips on how to do that.

8. Team 1 and Team 2, boring

Let the team themselves decide on their team name. Even better let them find a symbol that they can associate with the team! For example Yoda from Star Wars to symbolise mastery.

9. Getting your guilds going

Don’t feel guilty if you haven’t tried it out yet, but guilds are the thing! 🙂 Guilds to nurse craftsmanship is a common practice within Agile.

10. Things I learned about Exploration Days

You want learning and innovation to take place within your company, right? In this chapter the concept of Exploration Days are described.

11. Giving feedback without fear

Are you upset with a colleague? Don’t give them a slap, instead prepare for them a delicate feedback wrap! 🙂

12. I don’t want to implement the Spotify model!

Don’t imitate, innovate! This chapter tells you not to just copy a successful model without tailoring it to your context and unique needs.

13. To finish up

Time to wrap up! 🙂 Some last words from Ralph on where to go next.


If you are new to Management 3.0, ”Doing It” is the perfect starting point! Read the well-written introduction texts, and then use the references to go further. Do you want to try Management 3.0 out? Perfect, use this book to guide you. I can truly recommend ”Doing It – Management 3.0 Experiences”! Best of all? You can download the book right here. Happy reading, and see you next time!

All the best,
 Tomas from TheAgileist

Zero Inbox

Today I’m sitting at a huge indoor playground, my son is here for a birthday party. I brought my laptop with the intension to ”write something” 🙂 . Earlier this week, I saw the hashtag #ZeroInbox mentioned by one of the persons that I’m following on Twitter. It seemed like a big deal, that #ZeroInbox was reached (meaning no emails in your inbox). I have that all the time, so I started to wonder why that is important, and maybe if I should write something about how I achieve it.



First of all, I’ll set you into my context. I get about 50 – 100 emails every working day. Some of you may receive a lot more than that, some of you less, but I assume the amount I get is pretty average. Many of the emails I get, are from the fact that I participate in email-lists (for example alerts of status changes in a ticket system). Maybe 10 – 20 emails per day are coming from other persons.

What are the reasons to keep ”zero inbox”? For me they are:

  1. I don’t feel any stress that there are things in my inbox that are important, and that may need my urgent attention. Checking the inbox regularly prevents that from happening.
  2. Very seldom things get ”lost in the inbox”. I have a system to keep track of the things I need to do.
  3. I have a possibility to act immediately when something pops up. There is not ”a long list of unread mails that may contain even more urgent things” that are blocking me.
  4. Overall, ”zero inbox” gives me the feeling of control, to be on top of things. I’ve also written about this earlier.

Below I have listed the rules that I try to live by, to keep #ZeroInbox at all times.

1. Use your mobile phone

You must be able to read your working email on your mobile phone (or other device you have with you all the time). Otherwise, you can’t apply my rules. But I guess most of you already do that.

2. Don’t have any filters/macros

I don’t use any filters/macros (for example moving emails in the inbox from a certain sender to a sub-folder). Why not? Isn’t that a good was of keeping #ZeroInbox? First of all, filters/macros you can (or should) only use on emails you get from systems (or email-lists). Then you can create a rule looking at the sender and then move them to a sub-folder. That sub-folder will of course increase and hold ”X unread emails”. That to me is stressful (to have unread emails). What do I do then? When I see an email from a system in my inbox I do:

  1. Delete it immediately (which is 99% of the cases, it takes about 5 seconds per email to do)
  2. I act on it immediately (for example a ticket is completed I send off ”good job”-message to the developer that fixed it).

The down part of not keeping them in a sub-folder, is that you can’t go back and search for old items. That is slightly true, but I almost never find the need to go back, and if I have to, I can check in my deleted items folder (which I don’t empty too often, maybe twice a year).

3. Checking emails all the time

Some of you may disagree with me on this one, but I check my inbox all the time. It’s the only was to keep #ZeroInbox! If you sit in meetings all day, and fall behind (emails is piling up in your inbox) there is no way to get back to #ZeroInbox (or at least that will require a huge effort that you will feel resistance to do). What shall you do if you have meetings all day then? There is always some time before, and in between meetings, clean your inbox then. Maybe someone else is talking at the meeting and you are ”out of focus” for a while? Pick up your phone and clean your inbox.

4. Emails I have to act on (i.e the ones sent directly to me)

Do I delete all my emails? Of course not. I use a system with sub-folders to keep track of them. The folders are ”in the cloud” so I can reach them all the time from all my devices. Some of you may keep an email in the inbox as a ”signal” that this is something to act upon, or keep it marked as unread. I don’t do that. All the things I have to do I keep track of using on online kanban board, right now in Favro.

5. Deleting emails (i.e. CC or from systems/emails-lists)

This may sound frightening to you, but I delete most of the emails I get. This means probably over 90%. Some rules fot that:

  1. If I don’t feel the urge, or have the time, to do something about the email I received now, I will probably not have it later either (if I keep it).
  2. If I’m on CC on the email, I got it ”for your information”, I’m not driving the discussion and therefore I can delete it (to be honest I keep CC-emails in some cases, moving them directly to a sub-folder after reading them).
  3. System emails / email lists – Just by the subject I can decide if I should do something or delete directly (see the filter/macro rule).


There you go, my rules for achieving #ZeroInbox. Are they applicable for your situation? It should be if you receive less or the same amount of emails that I get every day. If you get more, or don’t have the possibility to continuously check emails, you probably have to think about something else. Until next time, enjoy!

All the best,
Tomas from TheAgileist

Concentration cone

In this blog post I will introduce you to the concentration cone. It’s something that I’ve had as a mental model during the most part of my career. The text uses a project, the project manager role and a team to explain the concentration cone, but this is applicable in many other contexts as well.


If you are a project manager and responsible for a project, you need to handle many tasks in parallel. At the same time, you need to be able to juggle around more than one ball in the air if you like. Can’t you handle more than one task at the time? Well, there are other roles that may suit your personality better.

I like the juggling metaphor. At a company conference I attended, all employees got three juggling balls and an hour of practice. Most people were able to get all the balls in the air and catch (some) of them. With a little more practice anyone can learn to juggle three balls. To juggle for a while is also a good way to take a break, it requires total focus and ”clears your brain”.

In juggling, you can’t hold on to a single ball for too long, you need to toss it up in the air to be able to catch the ball that is falling down. There is a ”rhythm” or ”flow” you need to be able to master, the same thing you need to be a good project manager. I believe this to be very important! Below you see my mental model to explain it more deeply.

Concentration cone


At the top of the concentration cone you are handling many tasks at the same time (colourful circles in the picture above). You need to have a constant flow of things happening, you can’t spend too much time diving into details for each task. You need to have the correct amount of information about the task, so you can make a proper decision and act. Wether it be doing the task yourself or pass it along to another person. Picture yourself swimming at the top of the concentration cone, dip your head into the water for each task to find out what to do about them, but then get your head up above the water surface again to catch the newt task. As a project manager, its at the surface you need to be, and let others ”dive deep”.

On the bottom of the concentration cone, you are in deep concentration and are working focused on only one thing (black circle in the picture above). Here you need to be, to be able to solve complex problems and do deep thinking. When you are here you shouldn’t be disturbed, then you will be forced up to the surface. Maybe if possible, its best if you can focus totally. But since you need to be available to your team to be ”in control” you can’t be deep down in the concentration cone too long. Your team members needs to be deep down in the concentration cone a lot, if your project shall be successful!

It’s very hard to find balance if you are trying to go ”up and down” in the concentration cone. My recommendation is obvious, stay at the surface to be a good project manager. I once experienced a fellow project manager that struggled to get the grip of a project. To get things going, he dove down into the details of every single task trying to do them himself. By doing this, the overall ”helicopter view” of the project was lost, and the customer was deeply unhappy about ”nothing happening”. It can surely itch in your fingers to dig into the details yourself (for example being an old programmer like me, that wants to ”hack code” again), but don’t do it. When you are deep down in the concentration cone, you can get stuck, and it’s a long way back to the surface. Your project will not benefit from you losing the overall control.


Did you like the mental model of the concentration cone? If you are more into soccer, you can say that a project manager should be like a midfielder and not like a goal keeper. The midfielder has to be involved in the game all the time, whether it being offence or defence. The goal keeper on the other hand, just have to focus on one thing only, stop the opponents from making goals. Until next time, enjoy!

All the best,
Tomas from TheAgileist

Tachometer to find perfect flow

How do you obtain a ”perfect flow” of work tasks passing through your software development team? That question have been in my head for quite some time. I can start by admitting that I don’t have a solid answer to that question (yet). However, I have instead thought of a way to visualise if you are having ”perfect flow” or not. How? I’m thinking of a tachometer!


Tachometer to find perfect flow

First of all, this is just an idea that popped into my head (this is actually the first encounter with the ”outside world”, so please bear with me). The idea is however to use a tachometer to indicate ”perfect flow” on a kanban board for a development team. Just like a tachometer is indicating if you are using the sweet-spot of your engine at any given moment.

My little example is a kanban board with three columns:

  • Design – Given the value 1
  • Development – Given the value 2
  • Test – Given the value 3

The values are used to calculate the position of the needle in the tachometer. I will now give you three examples that hopefully explains it all!

Example 1 – ”Too early”


In this example three tasks are in the ”Design”-column, giving a ”tachometer value” of:

1 + 1 + 1 = 3

Thus indicating that we are ”too early”, and that the later steps in the flow (”Development” and ”Test”) are not utilised. The analogy with a car would be to ”gear up” meaning that the team needs to take the ongoing tasks to the later steps of the process.

Example 2 – ”Too late”


In this example three tasks are in the ”Test”-column, giving a ”tachometer value” of:

3 + 3 + 3 = 9

Thus indicating that we are ”too late”, and that the team soon will run out of things to do. The similarities with a car would be to ”gear down” and for the team to put focus on feeding in new tasks to the kanban board.

Example 3 – ”Perfect flow”


In this example the three tasks are evenly spread between the columns, giving a ”tachometer value” of:

1 + 2 + 3 = 6

Thus indicating that we have a ”perfect flow”, and that the steps in the process are utilised in the best possible way!


I understand that the mathematical formula behind this idea must be improved if this should become a reality. There are also cases where a tachometer like this will not be useful, for example if the team has just started. Maybe this can act as a challenge to manufacturers out there of digital kanban tools to add a tachometer in their product!

All the best,
Tomas from TheAgileist