UPDATE I have learned new stuff. There are a better ways. Find the update here

This is the second post in my series where I show how you can get make powerful visualizations of process data. As before, my goal here is that you can dump your process data into one tab of my sheet and then the dashboard will make all the other calculations.

In the first post, I talked at some length about other goals of this tool and some of the principles I built these ideas on.

Speaking of those principles; in this post, I will violate one of them a bit, by adding a filter capability to the lead time chart, so that we can see just a part of the data.

The reason I want to do this is that, as it the chart stands now, it’s a bit too...

UPDATE I have learned new stuff. There are a better ways. Find the update here

I have been coaching agile teams for about 15 years now. One thing that I often help teams that I coach is to tap their process of some valuable data. It turns out that many of the tools that we are using have a lot of data in them that we seldom look at and even more seldom act on.

Most of these tools (like JIRA or Team Foundation server) obviously have ways of looking that this data too, but I’ve found that it’s either really hard to understand the visualizations or that the reports that you can produce simply don’t cut along the right axis.

I’ve now grown tired of recreating these simple reports for every client and wanted to share my, very simple, stats here. This way I can reuse it for...

At </salt>, a boot camp that I’ve been part of setting up, I get to try all kind of different things that I haven’t done before. Mostly around configuring, management and supporting the students computers and our code.

Just last week we had the need for a simple way to do a copy of our GitHub repositories. I did some research and found a simple way that I’ve put together in a script. I wanted to share it here.

The case

At Salt we have all our code, exercises and test checked in at GitHub. A normal workflow includes the students, cloning the repository to a branch with the name of their mob (programming) team. They then commit code to this repository.

This becomes messy as we are running several courses per year and need to keep the different courses separated.

We have, therefor, created a...

When I introduce agile I do that through a nice little quandrat originally from the This is Lean book by Pär Åhlström and Niclas Modig, and visualized by Håkan Forss. I’ve wrote about it here. This post will only focus on the top left triangle - where we focus on maximizing resource utilization.

But I’ve noticed that personal stories sticks better and I have used a story about my dentist to show an example of a setting that focuses heavily on the resource utilization.

I lately was called back to a checkup at the dentist and did some further research. It was a fascinating peek into a world where many people was working hard, smart and diligent to achieve an outcome that was not any good for me as an end customer (aka the wrong thing, in my book).

I wanted to share this story...

Quite often I get to introduce people to using a “work visualization board” (often referred to as a kanban board), these days. When I do I’m struck with the common misconceptions that follow many tools - especially tools that I have been nudged (or forced) to use..

I wanted to share a few of the things that find myself repeating to new users of kanban boards.

A board is just a tool

A board visualizes your work. That is its use. Just like a hammer is used to hit (and occasionally extract) nails.

Use this tool to get more value from the tool. If you find the board “being a pain in the ass” or “hindering from working at all” then you should probably find another way to visualize your work. I strongly suggest that you visualize the work somehow, but find a way that doesn’t hinder...

Hey Marcus, can you just add a License file to each of our repositories?

All of them?

Yeah, all 42…

This was a task given to me about 50 minutes ago. I’m done now.

Obviously I spent all that time writing a script to do this. And I wanted to share this with you guys and my future self.

Obviously I learned a lot as well.

Game plan

My game plan was pretty easy:

1. Create a LICENSE with the proper text.
2. Clone all repositories of the organisation to a new folder
3. Loop over all the repositories and add the LICENSE file to each of them
4. Add and commit to git and then push to the remote repository

Create a static license file

I went to Choose A License , picked an appropiate license and create a...

I got another email from a former client that I wanted to answer here on the blog. In fact, in this instance, I also got the same question during a Lean Coffee discussion at a current client too.

Without stating the whole email the questions were a little bit like this:

With kanban - isn’t there a risk that you lock in and cement the different parts of the board?

Also, are we not risking to focus too much on the efficiency of the individual steps in the workflow?

Since the board clearly shows bottlenecks in some areas we risk putting in an effort to solve that and then just move the workload to another place in the workflow.

and then in the lean coffee

I don’t like those columns - it looks like a waterfall. I just want DOING to show that we are working...

The last couple of weeks I have talked a lot about prioritization at my current client. In many conversations, I’ve felt the need to go back the foundation of things that I build my coaching and consulting on. For example, I might question how we prioritized as we done, and then I notice that people become defensive - thinking that I am questioning them rather than the way. This has led me to reflect, formulate and then re-iterate three basic assumptions that are increasingly important to me:

1. Everyone did their best, and continue to do so
2. There’s always more work to do than we have the capacity to do
3. We don’t know what will work best

Let me describe a little bit more what I mean.

Everyone did their best (and continue to do so)

This is probably (who knows - my brain … I...

At my current client, we are trying to make a change to focus more on flow than on resource utilization. This is harder than it sounds because much of the current ways of working, structures, roles and rewards are built to support another mindset.

One of the things that lately have popped up for me are the words we are using to describe the roles we have in different parts of the organisation. This heavily prevailing in the IT-industry and maybe agile actually has helped to cement a few of these (an excellent keynote by Michael Feathers put me onto that idea).

This also ties into a great quote from David L. Marquet and his excellent Turn the Ship around book

There’s no they on Santa Fee!

Let me try to explain.

On the sub

When David Marquet was the captain on...

I got a question the other day from Enea Zuliani and Michele Degrassi. It was particularly heartwarming to read as they just read Kanban In Action and now have started to use. Kanban. In action.

They now had a question and I asked if I could share that question and my answer here on the blog. They kindly obliged.

Here’s the question (I’ve edited it a bit):

Dear Markus, let me get back to you with a question. If an agent has to choose between different kanbans (cards) which one to work on, and all the kanbans have the same characteristics (dimensions, etc.) and he can actually decide to work on every one of them, is there any “rule” you might suggest in order to pick a kanban - everything else being equal?

Kanbans or not kanbans

First of all - excellent use of the word...