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.

TFS 2010 for us product owners

I’m currently using a lot of Microsoft Project to keep my distributed stakeholders updated since the scrum dashboard just works for the current sprint and the 2008 web access isn’t very… accessible.  The stakeholders can’t get the overview they need. So, I spend time on separate Microsoft Project files with the long term plans (as described in a previous post) and I keep the product backlog in TFS.

So, I was just thrilled by the images on BHarry’s blog, describing the new features for us non programmers. Finally, I can really invite my stakeholders to keep themselves updated on the level they need.

The dashboard looks awesome! Here are two examples:

For me as a product owner, I of course long for the hierarchical work items:

If I still want to show Gantt charts, I can (if all goes well) use the upgraded Project Integration, since it conserves the hierarchy. This is the main reason I don’t use the integration today.

I’m also very curious about the Sprint planning functions

So, what more can I say: JUST BRING IT ON!

Assigning the business people

Yesterday, we took yet another step in our slow transition towards a more agile software development. As I’ve explained earlier, we use Team Foundation Server‘s work item tracking with the Scrum for Team System work item template and the Scrum Dashboard from EPIServer for daily updates. But with us I mean the developers, not the business people and not the acceptance testers.

But the other day, one of the business responsible started asking questions concerning who’s, and what’s and when’s in a project where I’m not exactly involved but where I function as an agile coach. First, I started looking myself, and then realized what I was doing. So, instead, I asked him to look for himself. Now, you agile warriors might argue that if we’d been using post-its he could have gone and looked for himself. But he works in Norway, so that is easier said than done when our developers are in Sweden.

I gave him a crash course in how he could use the scrum dashboard (read only rights) and he was very happy to see that he could now look for himself.

It was less than an hour when another person approached me, asking about the same question. This guy is both an orderer and a supplier of material. Since he’s our interaction responsible, developers are often dependent on him supplying them with sketches and suggestions. First I considered just giving him the same read-only rights but then I realized that he should also be considered part of the team. One of our team members had registered an impediment which stated that he was waiting for material from this guy. So, I gave him some read and write rights instead and told the guys that from now on they should assign him on tasks and impediments like they do with each other. This became a step towards integrating the business people into the development teams and processes.

Enterprise scrummish and some don’t try this at home with EPIServer’s scrum dashboard

Current work

I’m currently involved as an administrative resource (you could say something of a scrum master even if we don’t use scrum for this project) in a very short project which has many resources. The resources are divided into multiple teams with shared resources and many dependencies between the tasks of the different teams.

We decided on using Team Foundation Server with the Conchango Scrum For Team System Work item template and EPIServer’s Scrum Dashboard. We are as I mentioned not using scrum but are moving in that direction and by slowly introducing some of the artefacts and tools, I hope to build an understanding for what we want to accomplish. Most of the guys had never used the dashboard before but they loved it. We sit in an open space but with this big a crew, it is hard to get a picture of how things are going for the other teams. Hence, the dashboard and scrums of scrum.

It is really interesting to see how these simple tools work in an enterprise environment. Having only handled one scrum team at the time, this is almost amazing to watch. I can’t wait introducing scrum to these guys and girls.

Think about this if you’re using the EPIServer Scrum Dashboard

But, back to the subject. Since people are new to the tool and I want them to see WHY we’re using the tool, I’ve taken upon myself to fill the product backlog and help out creating the first tasks on the sprint backlog. With so many teams, you can imagine that this takes some time. And since I’m not familiar with all the terms and systems, I can hardly guess what they mean.

So, what I did was that I used the team explorer to create a product backlog item. Then I created related sprint backlog items by right clicking the product backlog item and selecting Create Linked–>Sprint backlog item. Then if the next product backlog item shared many attributes, I right clicked the first product backlog item and selected Create Copy–>Product Backlog item.

Let me put it mildly: don’t do that. What happens is that Create Copy also creates a link and when I then opened the Scrum Dashboard the sprint backlog items of the first product backlog item was instead drawn on the latter product backlog item.

So, instead I created all the product backlog items using Copy from, and then I added the sprint backlog items. I guess the same problem occurs if you do the same with work items of the work item type Bug.