Calling it Kanban

I have been taking a liking to Kanban a lot the last couple of years, it’s feels to me like a natural evolution for most Agile people from Scrum. Don’t get me wrong, I like Scrum, and I find a lot of it’s practices to be great. And in many contexts perfectly well functioning.

But the last 3 teams I have worked with wanted to try Kanban, or so they said… I think there’s some kind of picture in peoples minds about what Kanban means, and I have rarely seen a team claim to be doing Kanban who I would say actually is.

While that is a little hard to say, because Kanban is so light weight, it does have a few rules, and limit Work in Process is one of them. The problem I am finding is, teams don’t actually want to do Kanban, what they want is to stop estimating, and stop committing. I’m not even saying I have an issue with this, I feel estimating is a precarious activity at best, and a wasteful and destructive one at worst. I don’t have a problem with the concept of no longer committing to Sprints, I think a flow based work cycle feels a lot more natural. But I think what most teams think they are getting with Kanban is what many developers dream about. ”Just leave us alone, it will be done when it’s done”. To me, this is not at all what Kanban is about…

Kanban focuses very heavily on delivery, that’s what I like about it!
Kanban focuses very heavily on collaboration, that’s what I like about it!
But they are right about one thing, Kanban doesn’t focus on estimation, it focuses on Lead and Cycle time, which I personally think is a much more effective system of gaining predictability.

I wouldn’t really take issue with this, except that I worry there are many work places that are starting to think of Kanban as a bad thing, because there teams are not really practising Kanban. So, what kind of things do I see?

They generally don’t have WIP limits, or ignore them, which is essential to the success in Kanban. When you don’t use WIP limits, you lose almost all the value, you just end up with a lot of work started and nothing finished. There’s no drive to unblock tasks, just keep pulling stuff in.

They don’t measure they cycle time and lead time, so they cannot have any predictability, and the question ”When will it be done” is answered with ”shrug… we are using Kanban”. This makes it not very popular with managers you can imagine 😉 When we have reached stability in Kanban, that’s a question we should be able to answer very easily ”7-9 days” type of thing. Also, with no metric, it makes it very hard to gauge improvement.

They generally just have a board that says To Do -> Doing -> Done, which is fine if that is indeed how your process works, but it basically never is, this is actually something I see in Scrum teams a lot as well. The board is a visualisation of you’re process, and as such it should represent how things work, not how you want them to work, and not just so you have a to do list. If you can’t see where things flow out from the point of ”code committed” then you don’t actually have any idea how much WIP you have. Also, you need to understand the inflow into the team. I am huge fan of visualising the refinement process in Kanban.


The in and outflow are estential to success in Kanban. In order to get that predictability, you need to be able to have things arrive in a somewhat standard state, and have them leave with ease.

One of my favourite tools in Kanban or lean is the concept of explicit policies. Explicit policies are extremely helpful, not just in identifying discrepancies in the way the team works, but how to collaborate on fixing them.

So, a few quick thoughts on Kanban. You need WIP limits, otherwise you just have post-it notes on a wall.
You’re visualisation has to be representative of your process, otherwise, it’s just post it notes on a wall.
The other things can maybe wait a bit, but I think having a workshop about those early on is very valuable, and I will be doing a writeup soon about how I’ve started doing this.

I have several projects I organise in this way, running my company, the conference I organise, but those are a different context, and I don’t really need a Kanban approach in those projects.So, If you’re not doing this stuff, I don’t mind.

But please stop saying your doing Kanban and making organisations allergic to the word… It makes my job so much harder 😉


The Product Vision


Since I wrote the last post – about the ever so common product owner-team gap – I’ve been considering the issue and how to solve it, from what seems to be every angle.

Perhaps the solution is simply, as I stated in the original article, to point out the problem to the involved parties, and make them work on closing the gap by approaching their counterpart. But recently, I’ve come to the conclusion that there might be another problem, just beneath the surface.

When analyzing the problem more closely, the true issue is almost never that there is a gap between the product owner and the team. Instead, the problem is that the product owner and the team does not share a common vision of the product.

The product vision is a goal, a common idea, of what the product will be in the future. It might exist in the form of a prototype, design sketches, requirement documents or (perhaps more common) simply as a more or less vague idea in the mind of the product owner. Now, if the team does not understand, or share, this product vision with the product owner, it is not that strange if the gap occurs. The product owner and the team will inevitable talk about different things, mean different things, because they have have no common ground. So, the first step is thus to establish such a common ground. One way of doing this, is to simply gather the team and the product owner in a room, and workshop until a common understanding of the product vision is reached.

Now, what I have found is that the much more common reason for the product owner gap, is that there is no product vision.  There might several reasons for this, but the most common one is that the product owner considers the needs of the stake holders, but does not consider how the changes will work together as a whole. This is, instead, left to the team to figure out. While this might work with a brilliant, dedicated team, it is almost assured that this will fail with a team in a startup phase, or a team that is suffering from some dysfunction.

In this case, it is important for everyone to understand that there will be no great product, unless there is a product vision. Be it implicit or explicit – it must exist – how else can the product owner assure that the right stuff is being built?

Do you recognize this pattern? Please let me know in the comments.

The product owner – team gap

Product owner team gap

A fully functional, high-performing scrum team includes both a product owner, a scrum master and a development team. The product owner’s formal responsibilities are prioritization and funneling requests from the outside world into the product backlog, while the team and the scrum master grabs work from the backlog and turns it into potentially shippable increments.

However, this is not the full story. Many product owners struggles with the many responsibilities that comes with the role, and therefore – sometimes as a desperate measure to prioritize among their many business activities – delegate a lot of the responsibility to the team and to the scrum master. On the other hand, many teams expect all contacts with the outside world to occur through the product owner,  or that they do not need to worry about managing the product backlog (since that is the responsibility of the product owner).

When the product owner delegates too much to the team, it might leave the team feeling abandoned by the product owner. A good team might seize the opportunity to go ahead a prioritize the backlog themselves – which might work, but also might lead to suboptimal end results. A more challenged team might loose their agile practices altogether. After all, what point is there in having a demo, if nobody cares about the results?

Similarily, when the product owner is unable to fulfil the team’s expectations, the product owner might be frustrated by the teams inability to take the initiative. From the product owner’s point of view, it might seem that the team is waiting around to be spoon-fed ready-to-go-tasks.

I think of this as the product owner-team gap. That is, there is a gap between the decision level, where the product owner has the majority of the responsibility, and the operative level, where the teams technical expertise is required to refine and execute work.

This gap might seem superficial, because in no overview of Scrum there is such a gap. In reality, though, it almost always exists, at least at first.

One of the key ingredients in getting the entire scrum team to a higher level of performance, is to make sure that this gap is bridged. Either the product owner understands the importance of taking a step towards the operative level, and makes an effort not only to be present at refinement meetings, sprint planning meetings and so on, but also to truly understand the teams work environment and the teams needs and wants. Or, the team takes a step up to the decision level, and helps the product owner understand and prioritize the backlog. This means – among other things – that the team must make an effort to explain the contents of technical work on a level that the product owner can understand and relate to. The team must also explain why they need a product owner present in their day-to-day work.

For either of these solutions to work, it requires patience,  good understanding of agile values and preferrably the presence of an agile coach. Also, a key to success is interest in making it work. Without that, as usual, all approaches will fail.


How will they solve it?

I’m sure you have all been there. You know, that discussion that does not really solve anything. Perhaps you took part in it yourself, discussing that problem that your organization is having. All of you in that room agreed that it is a big problem for you, for your entire team, for the entire organization. You talk about how wonderful it would be if this problem could go away, you analyze all the terrible situations that will occur if it does not. You leave the meeting with a sense of having reached some profound conclusion, some deeper understanding of what is wrong with your organization, and you wish that they, the people really responsible for fixing what is wrong, could receive the same epiphany.

Here’s an unpleasant truth: unless you act on your new-found knowledge, what you just did constituted waste, and it should be eliminated.

”Come on”, you say, ”we must be allowed to have discussions about our problems. What about our retrospectives? Surely we can have those?”

Yes. Of course. But here’s an easy tell-tale sign if your discussions consititute waste:

  • If you are talking about ”how we will solve the problem”, it is a valuable discussion.
  • If you are talking about ”how they will solve the problem”, it is probably waste.

The difference in only one word, but it it makes all the difference in the world.

Please also see this  video from Jeff on this topic.


Story points and hours


A very common question from teams starting out with Scrum, is that about story points vs hours. How is estimation done? Can we use hours instead of points? Isn’t it the same thing? (Hint: it’s not.)

Before we proceed, I would like to make it clear that there is no definitive, general answer to how estimation should be performed, or whether you actually should be doing estimation at all. Every team must find its own answer. However, I find that the following is a good starting position.

And to get us going, we should start with the ”why?” before getting to the ”how?”.

Story points

Story points, or just points, are used in Scrum to estimate the complexity of an item in the product backlog. The estimation are typically done during refinement meetings or at the sprint planning meeting at the latest. Poker planning or swim lane sizing are common estimation methods. The purpose of the estimation is not only to get a complexity estimate – and therefore help the product owner in prioritizing – but also to check that the team has the same idea of the effort involved. The estimate is then used during sprint planning by the team to know how much work to commit to for the upcoming sprint, perhaps based on the number of points done during previous sprints.


Hours are used when estimating the tasks that needs to be done in order to reach the acceptance criteria specified in the product backlog item. If the remaining effort on each task is updated regularly during the sprint, it is possible to create a burndown chart that visualizes how much work remains to reach the sprint goal.


Story points Hours
Estimate of… Complexity Work
Estimated at… Refinement meetings Sprint planning
Can be used to answer… How much work can we manage in a sprint? How much work remains in a sprint?
Are updated… Never; or possibly at start of next sprint if not done. Regularly.

There is no conversion factor between points and hours. Never. Ever. There is a correlation between the two, however. You would expect an item with small complexity to have tasks that sums up to a small amount of hours – but this does not always hold.

Misusing the estimates

It might be tempting to reuse the hours estimate for other purposes than the one stated above. For example, you might feel tempted to grab the number of hours from a number of tasks, multiply by some hourly rate to get a cost estimate. That is a bad idea, since that was not why the estimate was made. In fact, any idea to map the hours of the task estimates to any other measurements of hours, such as the team’s available hours, is probably a very bad idea. If you need such an estimate, ask the team explicitly for this.

Story points and hours

Do we need to do both story points and hours?

If you do not care about how many points you commit to, but instead use some other method (perhaps your gut feeling?) to know how much work to put into a sprint, then you do not need points. Beware, however, as it is quite likely that you will miss out on necessary discussions during refinement meetings.

If you do not plan to visualize the amount of remaining work, or use some other way of visualization, or if you are unable to regularly update the remaining effort, then you do not need hours.


Each agile team must find its own way in doing estimates (if at all), but to avoid the common pitfalls you should understand how Scrum has been implemented before. Story points and hours are used in different circumstances, and the estimation for product backlog items and tasks have different purposes. Be aware of this.

And when someone asks you to estimate the entire backlog in hours, remember to ask ”why?”.

Standing up when you make a mistake

Anyone who knows me knows that I am a firm believer in Lean and Agile principles. One of those principles is ”Respect People”, which for me extends far beyond simply treating people politely, although it includes that, it also means respecting that people are human beings and all that comes along with that.

One of the things I see in this is respecting that people make mistakes, and I try to believe that there should be no shame in that. We act in the way we see best at that point in time, and it is a certainty that at some point we will make a mistake.


The issue is usually not that we make mistakes, but that we lay blame on others when they do, and this leads to people trying to cover up their mistakes due to the shame and pain that comes along with it. I don’t believe in laying blame, mistakes are inevitable, and if you accept that you come to realise that the only relevant question is how we improve as a result of those mistakes. In Scrum language, we need to Inspect and Adapt.

So, I try very hard to make sure I admit to my mistakes when I make them and learn from them.

Standing up

Not long ago I published this post:
Which talked about a negative experience I had when I started with a new team. It occurred to me that some people may have been offend by this post , which caused me to re-examine it and determine I had in fact made some mistakes. This was never my intention, but none the less, I feel I should stand up and say so. But being a human being I will of course also try to justify my mistakes 😉

This post was about how I perceived what happened, and that I don’t make any apologies for. But that doesn’t mean that others are expected to share my viewpoint. And when I read through it again, I realised there were many things that I did not make clear and that was unjust of me.

Inspect and Adapt


There are a few things that when I re-read them I realised lacked the needed context.

”The team had not been informed that I would be working with them beforehand, so the first word they had of a new team member was when I was standing in front of them.”

This was not entirely accurate, most people were aware that there would be a change, I had even met some of them in the interview process. But most were not aware that a decision had been reached and that I was starting on that day. The organisation itself did feel they had informed people, which I’m sure they did, but many people made it clear they did not feel it was appropriately communicated. This was a communication problem, we should have focused on how it happened instead of trying to say why people were right or wrong about it.

”What’s more, there was a team member who had been serving as Scrum Master in a part time capacity, I was being brought in so that he could focus more on development work. Which he didn’t know until I was standing there in front of him. It actually turned out he was very upset and had clearly stated in the past that he was keen to remain Scrum Master.”

I realise now this might have given the impression that this person held it against me in some way. This could not be less the case! He was very welcoming, supportive and helpful. He was a pleasure to work with, and an all around good person. My reason for saying this was because I felt it did hurt my credibility with the team, I might be wrong about that, but that is my impression of the situation.

”This team was already very frustrated with the way their organisation was handling this transition and now I was just one more part of that problem. I am sad to say it was a blow I was never able to recover from. I worked with them for about 6 months, and I don’t feel I was every actually accepted into the team and as a result was unable to help them move forward.”

I thought about this one a lot, but I don’t feel I made a mistake here. I do feel that I got off on the wrong foot, I do think we never really recovered from it, and I did feel at the time that I was never truly accepted into the team. The team may see that differently, and they are perfectly entitled to that opinion.

This does not however imply that these people mistreated me in any way whatsoever. This was definitely not the case. They were kind and welcoming to me on a personal level, I was speaking more in the work culture divide I felt it created.

My final word on this is that I consider myself the only one responsible for our inability to move forward, if I was not able to overcome this then that is my failing and I need to improve my skills or approach to do it better the next time. I felt embarrassed over the situation and was personally not able to overcome it.


So, what matters now is I try to improve on the situation.

That was the intention of the original post. I wanted something I could have to send to teams and organisations in the future to make sure I took responsibility for not allowing this to happen again.

This post is also an attempt to adapt, I am trying to improve on the mistakes I made by admitting it was me who made them. I will add this post as a link from the previous post. But I will not remove anything from the original as I feel that would be hiding the problem.

I will consider things I write more carefully in the future, because I honestly didn’t think of any possible negative consequences of what I was doing. I try very hard to be an open and honest person, I usually consider this to be my strongest trait. It also means I am not always good at knowing what not to say, which is my weakest trait.

Finally, I will invite anyone who was offended to say so in any way they see fit. You are welcome to comment, I will gladly make you a guest poster to write your own post disagreeing with me (anonymously or otherwise), you can call me for a personal apology, or I will happily buy you lunch and discuss it further.


I am always cautious not to use the names of any person or organisations as I feel it is not responsible to out anyone without their consent, as well as it being a legal question. Please respect this if you decide to comment.

Makers Academy Experiment

My partner, Henrik, and I have spent a fair amount of time discussing how to improve the IT market in Göteborg, and really how to improve the IT industry in general. This is one of our main motivations in creating and structuring it so that we never have any incentive to lower our quality standards (

We are facing a lot of different issues in the IT industry not the least of which revolves around technical excellence.

The question is not one of intelligence, we have absolutely no shortage of brilliant people in our industry, but one of environment and practice. Most people do not enter the workforce with knowledge of modern engineering practices like test driven development, continuous integration and delivery. Once they enter the workforce there is a lot of stress and pressure which results in virtually no time to learn new skills. Sure, they will need to learn things everyday to solve the problems they face, but what about doing more than just solving the immediate issue? What about a larger shift in the way you think or work?

Most day-to-day environments don’t allow for systematic improvement and addressing root causes of problems. Obviously, this leaves underlying problems in place instead of them being fixed once and for all. We can all agree on that this is a great waste. This is especially true in our industry where demand is ever increasing – addressing the symptom will not save us. We need to attack the root cause.

This is why, when we were approached by, we were intrigued. The concept is simple, it is a 12 week intensive coding camp, aimed at teaching people the fundamentals, enabling them to hit the ground running – and keep running. But what is important is that modern engineering practices are considered to be part of this foundation. Students work from day one with automated testing, continuous deployment, and other such skills. Meaning when they enter the workforce and are faced with problem, their instinct will be to solve right rather than just hacking a solution together.

Our hope is that this will contribute to a changing culture in the world of software development, which has already begun, and improve our technical excellence for the better.

But, we have never done this before and there are a lot of unknowns.
Can someone become a good coder in the course of 12 weeks?
Is this program the best way to go about that?
Will it provide value to those who attend it?
Will it be something we are proud to have our names on?
Do we have something to contribute?

As we always do when uncertainty is high, we decided to perform an experiment. We will work with for their first 12 week camp. We will be doing this free of charge and during our spare time. At the end of the 12 weeks we will know a lot more than we do today!

Wish us luck, I will keep you up to date!