Using our kanban board for continuous improvement

Why do you use a kanban board? Why do you use a scrum dashboard? Really? Think about that. And then think again?

Do you track your workload? Do you calculate if you’re going to complete the sprint objectives? Do you use it to divide the work or fetch your tasks?

And why do you manage projects? Is to have something to do? To be able to track progress? Or divide work or just to feel that you’re in control of what is happening?

What ever is your reason if it’s one of the above, I state that this will not help you in the long run. Because this objectives will not improve your work.

This summer I read The Goal and learnt about The Theory Of Constraints. As always, I recommend you reading the complete book, but here is your five minute version.

All processes have constraints. You cannot remove all the constraints in the process, because if one step stops being a constraint, a new step becomes the new constraint.

A process with step 2 as the constraint

If step 2 becomes more effective, the risk is that the constraint is moved to the next step. So, you cannot just map your process, “remove the constraints” and be happy about your highly effective process. You need to work this continuously.

So, the objective is to constantly improve your process so that the effect of the current constraint is minimized and so that new constraints are identified. But how is that done.

Well, first you identify your current process. All the steps are mapped and then you see where there is some queuing going on. And here comes your Kanban board. Or your scrum board. Or what ever tool you’re using.

Here you follow the value stream of the process and by having a visual tool, you can identify your current constraint.

For example, let’s say that you’re going waterfall. What happens (probably) is that a queue forms at the testing steps. When people finally get to test stuff, a queue of bugs will start to form. And it can form quickly. The step to take then is to try to even the identifying of bugs. Hence you get continuous testing during the process. But then something else starts queuing. And you then use the board to identify that and to improve those steps.

A mistake, according to The Goal, is that we spend too much time optimizing the steps that are not a constraint. But by doing so you just add to the queue. So, if you have a problem with testing not being done, making the software coding faster is not increasing the productivity of the whole process.

I’m really excited to be working with this in TUI Nordic. We’re an organization who is working with lean values and empathic leadership, so this will fit nicely into the culture of the organization. Will it be easy? Hell, no. But a real challenge, yes.

Kanban, take 2

When do you use kanban? When I read the recommendations from Swedish Crisp, I see that they recommend kanban for support organizations and software development teams where the possibility to solve problems is most important.

The reason for me turning to kanban is just that I want to solve problems. That, I want them solved, things done. Completely done, according to a definition of done.

If you work with a time boxed methodology like scrum, I’ve found it hard to handle scenarios like these:

1. One day after deployment, a crucial bug is identified so we cannot install on customer sites until the upcoming delivery.
2. In the middle of a sprint, a resource becomes unavailable (sick, has to solve issues outside the project).
3. At the end of the sprint, it becomes obvious that the story cannot be completed and that to meet the deadline with acceptable quality.

With kanban, I can handle these problems much easier and this is why I like this approach in one of my current, very complex projects. Of course, we’ll run into other problems but as a project manager I want the right things done to the right quality.

Why Estimate is a bad word

What is an estimate?

According to Dictionary.com the verb means:

1.
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.

2.
to form an opinion of; judge.

and the noun means

4.
an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.

5.
a judgment or opinion, as of the qualities of a person or thing.

6.
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.

So, why is that a bad word? Well, I don’t think it’s really a bad word, but in the case of software development, the use of the word results in some serious problems.

Case 1: A developer leaves a task unfinished, that is not according to Definition of Done. The reason is that he’s run out of time according to the estimate so he drops it or finish it with lacking quality.

Case 2: A developer starts working on “something else”. The reason is that he finished what he was supposed to in less than the estimated time and felt free to spend the rest of the time with that other stuff.

Case 3: A project manager gets upset that a project is late. The reason is that he feels that the project is late because things took longer than the estimates.

So, why is estimate a bad word? It’s because it can cause people being pushed into not completing the tasks or not doing the things that have the highest priority. It causes confusion.

And if you consider a project where Case 1 and Case 2 are common, what happens? It causes some stuff to be bug infested which probably causes later delays and you’re never able to make up the time since when the developers are faster than the estimate, instead of moving on to the next item, they fill up the time with other stuff. Observe that I don’t assume that they are surfing the web or just idling, perhaps they refactor or something else. So, it is often good stuff, but not the most important stuff. And it does not help in catching up. So, what does this lead to; Case 3. If the project delivers poor quality and unfinished work and never makes up the time, of course the project will be delayed.

So, what word is better? Planned? Don’t think so, even if Microsoft Project use that word. This word most definitely leads to all these cases. Assumption is no better. When you think about it, you just have to realize that the word will lead to misunderstandings. So, what do you do?

Well, to handle Case 1 & 2 you need leadership and here I think that Kanban is a real savior. You cannot just drop the work and you cannot use the estimate as “your time”.

But what about that project manager? When it comes to the project manager’s need for planning, it’s important for him to realize that an estimate is a guess. A good or a bad guess. And when you’re guessing, you need to know the value of the guess. I like working the PERT analysis when this is a big issue (isn’t always??). You give three estimates; an optimistic, a probably and a pessimistic. Here is an excellent presentation on PERT analysis by Ricardo Vargas.

Pert Analysis in Projects

View more documents from Ricardo Vargas.

You can also add a value of risk to the estimate. So, when you estimate something, you estimate the size and the risk. And you would be stupid if you don’t realize that if you have a big task with a high risk, you cannot take that estimate for granted.

Don’t forget to harvest the passion of the developers

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.

About kanban and estimations – just a clarification

I previously wrote a post about how we’re starting to implement kanban and I think there is room for some clarification about how we use our estimates.

What you need to keep in mind is that on top of our software development process, we have our project management process. This process raises the funds and priority for the project. When we implement a project, this affects the budget for different departments, based on the assumption that we save time or increase income. To give you a very basic principle, we can have a project which consists of two themes. So, we build a business case:

	Benefit department A	Benefit department B	Sum
Theme 1	500	100	600
Theme 2	100	300	400
	600	400	1000

 

In our business case, we should have a budget of at most 1000 to be able to break even. So, for simplicity sake only, lets say that we include resources matching 1000. The budget for department A & B will now be affected so A carries 60% of the costs and B 40%.

We start with Theme 1, since this has the highest priority. But we must not forget that we cannot continue with theme 1 during the whole project. If we would only deliver theme 1, department B would probably be disappointed. They got to carry 40% of a project which does not benefit them as much.

So, what I do with the estimates is just delivering this to the developers. They are made to understand about how much time will be spent on the different themes. But it’s important to stress that this does not affect the quality they will deliver. It just give them an idea on how big big part of their time should be spent on the different themes. This to enable them to deliver with quality. I see this as transparency in information between customers and developers.

This does not mean that the developers commit to an estimate and here I see the big difference with scrum. You cannot commit to deliver on an estimate. In most cases, things tend to take a little bit longer than expected. In some cases it takes shorter time. The important thing is that the team spend the right time on the right stuff to deliver the right quality.

So, how do I use the estimates? Well, I just keep the guys informed on how much of the budget on each theme that is spent and when we get near the end of the budget of theme 1, it becomes really important to finish the important things on that theme so that we don’t stand there and are faced with the options of delivering 1 with poor quality or 2 with too little effort.

In practice this means that when we’ve used 30% of our resources, I start to really stress completing the tasks, verifying with customers that they have the features they really need so that we can use the rest of the time just completing the work. By now, the guys think they are about 90% done, but means that half the work remains so now we should really avoid new features.

Integrated scrum and kanban

This week we moved into a new phase in our first project on TUI Nordic in which we use kanban. We are kind of working with the same stuff as another project which uses scrum values like sprints and estimates. So, what do we do?

1. Tight communication between product owners

I start every day by a chat with the other product owner. We’ve decided that the best way to do this is mutual success. That is; if both projects are successful; the individual projects are successful. And we both know that communication is the basis for this. So, I plan for my stuff so that it helps the other project, and vice versa.

2. Guest players at daily standup

Both teams have daily standups and first we discussed scrum of scrums but since we have so tight discussions anyway, we realized that what was really important was when someone from my project (which is the smaller one) is working with code which directly affects the other project, he participates in that daily scrum as well. Since he’s a pig he can talk and this has worked surprisingly well. We all know that we have all to gain by helping each other and there’s a lot of sharing work and ideas.

3. Shared code

We work on the same project and work with integration as often as we can. We want to know as soon as possible if the shared code does not work.

4. Consider the scrum team’s sprint delivery

Checking in non working code is never OK but oft course this becomes a worse problem the nearer delivery a sprint is. Since we don’t have sprints on our kanban project, we must not forget to take this into consideration so we’re not half finished with something they need for their sprint delivery.

5. Nice and professional people

This would never have worked with the wrong people. I’m really proud to work with guys who realize that we’re all to gain here and there is no “that’s not my problem since that does not affect my project” mentality.

 

To summarize, I actually think it’s easier to integrate one scrum project and a kanban project than two scrum projects. But the story continues. It’s not over until the fat lady sings!

Kanban & estimates

Estimate or not? Using kanban is focusing on delivering completely done items and having as few items as possible in progress at one given moment. So, should you estimate?

When you discuss estimation, independent if you’re doing scrum or kanban, you have objectives (scrum term product backlog items). And to accomplish these, you have tasks leading up to the objectives. When using scrum, a relative value should be used for estimating the objectives (so called story points) while an absolute value is used for tasks. These are separate estimations which are also done during different occasions. You estimate product backlog items (or user stories) during release/product planning and you estimate tasks during sprint planning meetings.

Before you answer the question “estimate or not” you need to understand why you estimate and if that applies if you are using kanban instead of scrum.

The main reason for estimating user stories/product backlog items in scrum is to be able to plan your releases and to be able to prioritize. When you know the relative size of a story, you can more easily set a priority and if you know your velocity (the avergae number of story points completed during sprints) you can plan for approximate deliveries for your features.

The main reason for estimating tasks is to be able to decide on an appropriate work load during the sprint. During the sprint planning meeting, the team estimate how big tasks are and when the work load (estimated task sizes) matches the available resources, the team commits to the sprint backlog.

So, how about kanban?

Do we still need to plan releases and prioritize? Well, yes you do. These needs remain, so I do think you should keep estimating your product backlog. You cannot use the same definition of velocity, since you don’t have the sprints but you can calculate velocity as story points/week or story points/months.

Do we need to estimate tasks then? Well, since you don’t have the committing to the sprint backlog, this need is actually not there anymore. But another need has arisen. You can in many cases put in everything from very little effort to a lot of effort into a task and before you get started, you need an indication of how much work is to be spent. But you don’t have to be as specific as in the case of scrum task estimating.

First impression of going Kanban

I can admit that going scrum for me can be described as the following process:

1. Well, this is not hard
2. Why don’t anyone care about this but me? Why do I even bother?
3. Oh, crap. I’ll just go on and try to make it work.
4. Ok, it doesn’t work cowboy style. Let’s go hard core.
5. Great…. Flow… Finally it works.

This took me about a year. A hard bought year, both for me and the project. But when we finally went Scrum all the way, it actually worked like clockworks. Great. I loved it. Then everyone started talking about Kanban. Oh no, a new buzz word. But scrum worked so well? I started collecting links on delicious but never took the time to actually read them. Why should I. Scrum works, doesn’t it?

Yes, it does. Sometimes. But sometimes chaos is overwhelming. And either you fight the currents or you just go with the flow.

Scenario: one project with one team. A rather long list of requirements of which we know we cannot do all. And there is a bug risk that the resources can be grabbed by other projects.

Can you do scrum during these conditions? Well, perhaps you can, but why. This is perhaps a project manager’s worst nightmare. But still, I sleep tight at night.

So, what did I do? First, I explained the situation to the stakeholders. We are low priority. We will lose developers on the way, so we don’t know what we’ll get. Then I asked what they wanted most. And the answer was two features. These brings most value to the customers. And then I took those features and divided them into smaller chunks so I knew which parts of the features were the most important. You could use story writing seminars and the user story form for this, but I didn’t think this would bring more value to the actual description. But that is beside the point. The point is that I didn’t build a product backlog. Instead I just created a pile of requirements and could bring out the most important thing in the pile.

That story went up on the board first. I told the guys: we all work on this. So, they divided the task between them and started working. Within half a day, half of the crew were off on incident hunting in another project but the rest could move on. So, they kept on that item until it was completed. When that was completely done, we put up the next thing on the board. Half way through that task, the guys were stuck. They needed the guys stuck on other projects. So, we put that task on hold and moved on to a new task.

So, what have we gained? By not pushing a deadline or an estimate, a developer cannot hide incomplete work by “well, I did not have the time due to delivery”. We deliver when we’re done. Not a second before. So, I think we’ll get better quality. Also, we’re not stuck with many unfinished tasks but just the bare minimum. Incomplete work is waste. You cannot avoid it all the time, but here you focus on this. We’re not crippled by losses of resources. It effects how many tasks we can do and if they have different competences: which tasks. But we don’t miss the delivery. We also give the stakeholders to change priorities often. So what if they come running with new stuff: this only means that we change the queue. Since the guys are just working on one thing, we can change the very next task if they want to.

So, what do you miss out on? Well, fixed deliveries are great if you want to plan acceptance testing. But to what use is acceptance testing if what you test is crap? You also have the risk that the guys never stop working on one item, polishing it too much. But here it’s important to be present and describe what you want and what you don’t want. And this is no different than scrum.

So, what was the process for going kanban (up til now)?

1. Why should I care?
2. But this is just like scrum, so why bother?
3. Now I get the difference. But where is my control???
4. Blizz. I would have gone mad on this project if I hadn’t gone Kanban.

I’ll get back to you on further progress!