Exploring WIP limits

A few months back I was involved in a highly developer centric project (very unlike my current project). Non-developers were basically only involved and available upon request, so most of the time the team was not very cross-functional.

The team was using Scrum at the time, but the flow obviously had a few glitches and user stories had a tendency to pile in the test column, until very late in the sprint. A huge team effort at the end of the sprint made us finish most of the user stories just in time for demo, but the hurry was at the expense of quality.

It seems to me that most developers prefer starting on a new user story, rather than truly test and complete the ongoing user story. There’s really nothing strange about this, because often the fun part is gone as soon as the problem is solved. In the good old waterfall days, as a consequence to this “law of nature”, none of the features in an entire release might have been tested properly until very late in the project. Needless to say, this didn’t work out very well, and agile emerged to address these problems.

To fully complete ongoing tasks faster, we need to build in mechanisms in the process that enforces us to finish tasks before starting new ones. Iterations (sprints) do this by limiting the number of tasks we can have ongoing during a shorter period of time.

In our case, this didn’t do the trick alone. We shortened the sprints to only one week, and admittedly things got better, but the symptoms were still present. We decided to apply Kanban. First we put a WIP limit of 3 in the test column, later we added WIP limits to other columns as well, to be able to regulate the flow better. To improve the quality on the deliverables, we introduced a rule stating that the person testing a feature must be different from the person developing a feature.

In the beginning, the limits worked more as a guidance than actual rules – just to start changing the mindset from “push” to “pull”. After a while we paid more attention to the WIP limits, and lowered the limit in the test column even more (WIP = 2) to amplify the importance of finishing tasks. This turned out to be artificially low, but it was a great “pull” lesson for the team.

After a while the flow improved and the team effort was more evenly distributed over time. Initially, I thought we might have to “force” people into testing, but our board made it clear what had to be done, and the developers were eager to contribute wherever necessary (an indication of the power of visualization). As a bonus, the number problems we had earlier in the demos went down.

I should probably add that some of the developers took more than their fair share of testing. Over time that could have been an issue we might have had to deal with, but for the short period of time the project was ongoing, it didn’t turn into a problem.

Still, these small changes made a huge difference to us. We no longer had to rush into demos with poorly tested features, and the “boring” parts of process were no longer only at the end of a sprint.

A simple tip for more efficient standups

A while ago, I was asked for advice on how a team could improve efficiency on standup meetings. The team was growing, and their standups were taking an increasingly amount of time. I didn’t have much time looking into why this happened, so I simply suggested they could try walk the board instead of using the traditional Scrum meeting.

As it turned out, it didn’t have much effect. People on this team are usually responsible for one ticket (user story) each, so they all end up speaking anyway. I took a closer look, and realized their great team spirit might be of the reasons why their standups takes too much time. They like working together, there are many outgoing personalities, and they like solving issues directly in standups. In addition to sharing information and solving problems right away, the standup meetings function as a social meeting place.

This is all fine with me, actually I would even encourage it, as long as the discussions are relevant for most people, and they finish up within 15 minutes. As soon as the team grows, however, not all discussions are relevant for everyone. So, the question is, how to improve the efficiency without killing creativity and good team spirit?

In similar situations, we have had to establish some ground rules to add some discipline and structure in the standup meeting. One way of doing this is by establishing a “parking lot” next to the board.

Whenever a discussion starts, we take a collective responsibility to end it gracefully and note the topic down in the “parking lot”, so that the discussion can continue after the standup meeting. Putting names of whom should participate in each discussion, can help determine the most efficient order of dealing with the topics afterwards. Here’s an example:

This usually works quite well. It helps us focus on the meaning of standups, which is sharing status and relevant information – and it shortens them down. You should try to identify problems in the standup meetings, but you don’t need to solve them all right away. To make this work, you need to add some amount of disciplin, but only with rules the team have agreed upon.

If the team is involved in creating the rules, then you have made the first step building a collective responsibility within the team. I believe there’s subtle, but important, difference by how individuals interpret “ending a discussion” vs. “postponing a discussion and create a new arena for discussing the topic”. We don’t want strict rules to get in the way of good team spirit, do we?

Please share your tips for efficient standups!

Using Kanban in retrospectives

I remember reading about the Lean Coffee movement. Inspired by their totally open meeting format, I figured this could be an excellent alternative for our retrospectives. Lean Coffee meetings use Kanban to structure their meetings, they democratize their meetings to learn and discover things about what they don’t know – as well as exploring further what they already know. Sounds like a good fit for retrospectives to me!

I decided to try this out in our weekly retrospectives. After some research I ended up using Kanban similar to what Benjamin Mitchell described in this post a while back.

Here’s our meeting board.

Gather information

We fill the ToDo column with different types of tasks.

1) Ticket (user story)
An important step for improvement is to analyze the tickets we have completed. We measure our subjective well-being of a particular ticket, simply by adding a smiley (also mentioned in an earlier post). There are no rules to what this smiley actually means, it’s just a personal way of expressing how we feel about a particular task.

Actually, there are two potential smileys on every ticket; the person developing the feature, and the person testing it (and this is not the same person according to our project policies).

Completed tickets are taken into the backlog for the weekly retrospectives. A ticket may look something like this:

2) Actions from last retrospective
Follow-ups, that we have finished since the previous retrospectives, are also put in the meeting backlog. Orange post-its for actions items (as we call them).

3) General topic (idea, problem, etc.)
To capture other topics that might be worth dealing with in the retrospective, each of us use a couple of minutes on our own, brainstorming, writing down ideas or problems that have occurred last week. We use blue post-its for this.

4) Time constraints
In addition, if any time constraints applies during the meeting (such as when a person has to leave early), we put that up in a time constraint column – pink post-its. This might affect the order in which we decide to go through the topics. Completed time constraints are moved to “done” when time has passed.

Running through the topics

With all the topics and time constraints available, each of them are given a brief introduction and put up on the wall. Overlapping topics are grouped together. We prioritize them using dot-voting.

We start off with the highest priority topic, and move on, one topic at the time, until time is up (which is 30 minutes). After a while the Kanban board might look like this.

Every topic is time boxed to eight minutes, but if we’re not finished discussing it by then, we might continue discussing it in a new time box – if that’s what the majority wants. Reordering the topics is allowed as we go along!

At the end of the timeboxed meeting this could be the result.
– Two old (and completed) action items debriefed
– One time-constraint passed
– One ticked discussed and completed
– Two general topics discussed and completed
– Two new action items created

Some topics lead to concrete actions. These post-its are put up on the project’s Kanban wall when the meeting ends. If it’s a small task, we usually fix it right away, if not it’s prioritized along with other normal tickets. We take completed action items back into the next retrospective, at least to give an update on what happened, but maybe also discuss them further.

We have been using this approach for a couple of months now, and it seems to work quite well. The structure is fairly easy to grasp, so that all team members can run the retrospective if necessary. We gather data for the meeting backlog in several different ways; finished user stories, previous action items and general topics. All participants prioritize the meeting backlog together, and we move on, highest priority first, until time is up.

Until now, this method has given us new and valuable input in every retrospective. Nevertheless, we will probably spice things up occasionally by using a different technique, just to get a different perspective on things.

Have you tried using Kanban to structure your meetings? Or are you thinking of it? Please share your experiences or ideas below.

(…and the next natural step would be to start Lean Coffee meetings in Oslo now, right? Give me a hint if you’re interested!)

Update 18/10:
After a twitter conversation with Benjamin Mitchell yesterday, I’ll nuance the picture a bit.

1) Our meetings are very effective, actually almost close to stressful. It takes time to prepare and prioritize the backlog, so 30 minutes every week might be too often – or too short. I guess this depends on the team and the situation, but we consider running the meetings 1 hour biweekly. Or maybe you have other ideas on how we might reduce the time it takes setting the stage?

2) The link between the project’s Kanban and the meeting backlog, lets us delve into more details on completed action items and tickets – and find new ways to improve. Vice versa, new action items from the meeting are followed up in the project. These links, both ways, are probably the best things about this approach. Even though it might be valuable also to discuss items in progress (those are fresh in mind), we wait until they are completed. Reason? Simple. We use a manual board, and if we move ongoing items off the board, we risk messing things up. Keeping track of this should be simple, but we skip it to avoid complexity.

Who’s your safety valve?

I love what I’m doing, I can actually be pretty passionate about things, and if I really believe in something my first instinct would be to let others know how this can make their lives, jobs, projects – you name it – better. But if you ask people I have worked with over the years, I guess they would characterize me as quite calm and diplomatic.

So how does these traits go along? In the beginning of my career I could burst out with things every now and then. Luckily no irreversible mistakes were made, but occasionally it was a bumpy ride. Now, even though my face might turn red, verbal and written outbursts are far less frequent – actually almost completely absent. I’m still passionate about things, but the difference is that now I have a safety valve.Outburst

My safety valve is a trusted person I can share my thoughts and ideas with. Even more important, I can share my frustrations openly with this person. When heated I use my safety valve to read through e-mails and documents before I fire off something I will later regret. The safety valve is most likely sitting somewhere nearby, and sometimes, depending on the situation, several people can act as my safety valve – maybe covering different areas.

Even though I have my safety valve right next to me, I always reflect a few seconds, on my own, before sharing my frustrations. I work with different customers and need to take confidentiality issues into consideration, so it’s not a given that everything can be shared with everyone. As the relationship with my safety valve develops there is room for discussing almost everything. To build a safety valve relationship, get comfortable sharing thoughts and ideas, before moving on to frustrations.

One last thing, the safety valve system works better if it’s bidirectional, so make sure both get the opportunity to vent. Call it bidirectional coaching, if you like.

Do you have a safety valve?

Improve team performance – seek inspiration elsewhere

As a teacher, my wife had to step in to avoid a conflict among sixth graders at school. She told me that she would let her students come up with different solutions on how to solve this conflict the following day. I mentioned briefly that she, in this particular case, could use a retrospective technique I have used in several occasions, prioritizing with dots, and let her students vote for the solution they would prefer. 

It slipped my mind for a while, I didn’t even go into details when I mentioned it, but a couple of days later she told me she actually had tried this technique out on her students. Some minor adjustments was necessary to make it more suitable for sixth graders and a chalkboard, but in essence it was the same technique.

She found the results surprising. While she expected the majority to vote for asking an adult for help, and at lower age they probably would, the majority voted for a certain way of solving this on their own – without adult intervention.

Instead of taking the answer for granted she generated new valuable insight of how her students think – and she only spent a few minutes totally. In addition she might have found the tipping point when children start behaving like adults in terms of conflict resolution.

For those of us who embrace agile development, we might find some inspiration in this to bring back to your workplace.

Retrospective can be successfully applied at any age and with all kinds of people, just remember to adapt it to your audience. Even the smallest effort can generate valuable feedback, and you might be surprised of what you find. This can help you improve your team.

My wife tested a new retrospective technique amazingly fast – with almost no preparation. It seems to me that they have a great environment allowing them to experiment. If they make a mistake, they get immediate feedback from theirs students and take a different approach next time. This is an important agile principle, find a faster way to fail, recover, and try again.

Create a climate in your organization that allow people to experiment and innovate, make sure there’s time to do this. Break a few rules. Take a step outside your normal boundaries and seek inspiration elsewhere, for instance see how they use visualization in a first grade classroom – the prototype for a creative learning environment. Some elements might be useful for your agile wall.

Question: Have you ever been inspired by something you have discovered elsewhere, outside your normal domain, and brought it back into your team? And how did it go?

Further reading: