When will it be done?

You have heard it before: “When will it be done?”

Earlier this year, I was coaching a team who frequently got this question from their product owner (PO). The PO was unhappy with the lead times, and wanted better predictability. The team didn’t really understand the problem, because most tasks were completed within just a few of days.

I analyzed the lead times together with the team, to try to uncover why the PO and the team viewed this so differently. The lead time was about 56 days in average, and out of this the response time was 36 days.

Working with the backlog had always been time consuming, and a subject of continuous reprioritization. The team therefore discussed a new strategy for maintaining the backlog with the PO. First they established an infinite backlog buffer (called “ideas”), where the PO could arrange and rearrange tasks as it pleased him. Then they agreed to limit the number of tasks allowed in the product backlog, and to replenish new tasks from the infinite buffer when needed.

Now, a few months later, the lead time is about 26 days, and the response time is down to 7 days. The PO is satisfied with the improved predictability. And as a bonus, the team doesn’t hear “when will it be done?” that often anymore.

Agile and congruent leadership

You’re a leader in your organization, and you want to improve efficiency. You think you want an “agile transformation”, because you heard others have been successful with it.

Then remember this:
Agile is not just a label you just put on the development department. Agile is a behavior and should affect everything you do.

So if you’re still up for the “agile transformation”, then it’s your job, as a leader, to do whatever is in your power to pave the way for every team, project or department, so that they can carry on with their agile transformation.

Start by truly understanding how agile works and how it affects the organization. Be congruent in actions and words. Ask for elements that are in harmony with agile. Don’t ask for reports, estimates or commitments from a bygone era, just so your way of reporting upwards in the organization is easier. Take that fight yourself. Show that you have confidence in your people. Give honest feedback.

Agile transformation is more than words, it’s behavior, and it affects the entire organization. Start by changing your own behavior.

Talking with carpenters

We are currently renovating an entire floor at home, and yesterday I tweeted about a Kanban board I put up for my carpenters. This was only meant as a “joke”, of course, but it generated some feedback and therefore, upon request, I share the board with you:

image

The intention was not to create a complete work list for them, but I wanted to visualize where their work and my work meet. A couple of examples are; “Pick up new kitchen from [vendor]”, “Tiles will be delivered between 0800 and 1400”. For now I use the columns Later -> Tomorrow -> Today -> OK!

And how did they respond to this? They seemed to understand the concept right away. They even pulled me over to the board today, pointed at a note to discuss possible changes for this particular item. That’s a good sign, if you ask me. They might never move a note on their own, but I think we communicate better this way. Luckily, the carpenters are early birds, so we even have time for daily standup before I leave for work.

To be honest I’m not sure if this goes under the definition of a Kanban board, but once again I see that a visual representation of how we work is powerful.

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.

Estimating software projects

My Twitter stream flooded with estimation related topics yesterday. We’re currently starting up a new project, so the timing was perfect and the topic highly relevant. Here are some recommended blog posts from yesterday on the topic:

Estimation is at the root of most software project failures
In this blog post Rob Bowley explains why we’ll never be very good at estimation, especially the long range high level estimates – mostly for reasons outside of our control. Still many people in the Agile community talks about estimation as if it’s a problem we can solve. The discussion after the post is also highly recommended:
http://blog.robbowley.net/2011/09/21/estimation-is-at-the-root-of-most-software-project-failures/

You Mean I Can’t Even Estimate? The Planning Fallacy in Action
A post by Jim Benson, down the same alley as Rob Bowley. Explains how we might deal with the fact that there will be a variation in every activity, and that we tend to underestimate a given task even if we’ve done that task many times before:
http://ourfounder.typepad.com/leblog/2011/09/you-mean-i-cant-even-estimate-the-planning-fallacy-in-action.html

Estimate the total cost of Agile projects
Kane Mar first describes why estimating the cost of software is, at best, an educated guess. Then he explains how to deal with this when estimating the total cost of Agile projects: 
http://www.scrumology.com/2011/agility/estimate-the-total-cost-of-agile-projects/

Story estimation on Agile teams
A comprehensive Q&A by Praful Todkar. Who should be involved in estimation? Should we time-box estimation? Is pre-analysis necessary before estimating a task? What should we include in our estimates?
http://computellect.com/2011/09/12/story-estimation-on-agile-teams/

On the previous project we started off estimating stories before taking them into the sprint. When we gradually moved into the maintenance phase, we discovered that we only selected stories by priority – not size. Also, the stories were quite small, so estimating them seemed like a major overhead.

Not giving any real value anymore, we decided to stop estimating stories. Later, when we applied Kanban, we removed the iterations as well. We’ve managed well without estimation for about eight months now, instead focusing on the flow and maximizing throughput.

So here we are, about to start a new project. I think the time is right for us to reflect on why we estimate stories, and why we (try to) estimate the total size of the project. After all, for this particular customer, Scrum is the “company standard” – they’re used to estimating stories before prioritizing and starting them. Therefore, I think this is where we will start, this is what the company knows. But who knows where we will end up?

Do we still need estimates, or do we eventually get into trouble anyway when using them? Do you know other relevant blog posts on this topic?

Kanban and Scrum after 500 tweets

I joined Twitter June 22, 2010, so, needless to say, I was not an early adaptor. Nevertheless, I just passed 500 tweets, and most of my tweets are somehow related to agile development, so did I come across something useful? The answer is yes, and I believe it’s an appropriate time to reflect – focusing on Kanban and Scrum this time.

During this period I’ve learned to enjoy Lean thinking, and Kanban in particular. The difference, you may ask? David Anderson puts it well:
“People ask me what is the diff between Lean & Kanban? Answer: Lean is a destination, Kanban is a means to get there.”

If you don’t know Kanban, here is a clean and to the point overview:
http://reaktor.fi/en/our_expertise/kanban/

And here is a first hand experience on what you can expect if you introduce it:
http://www.agilecoach.ca/2011/07/07/kanban-reboot-pt1

It’s not always easy to map a process to the Kanban board, so you might need some tips when you are stuck: http://blog.brodzinski.com/2011/08/map-process-to-kanban-board.html

After a while, you will know that keeping an inventory is not free of charge, and there might be an upside if you manage to keep it down:
”In 1987, while GM held 2 weeks of parts in inventory, Toyota held 2 hours.” (Jeremy Lightsmith)

By then you should know that you need to pull work items, not push them. This strategy, if you see the analogy, might even affect your leadership:
“Management is push, leadership is pull.” (Jim Benson)
…and what’s really the difference between a project leader and a project manager?
http://www.projectsmart.co.uk/project-leader-or-project-manager.html

Kanban takes an evolutionary approach, so big changes won’t happen overnight, but you should still be prepared for resistance in the organization. Here are 5 arguments against Kanban – and how to respond to them:
http://noostvog.wordpress.com/2011/06/29/5-arguments-against-kanban/

Even though I find Kanban very appealing, I still like Scrum. Recently, Scrum even got a major update to the Scrum guide! I found it really interesting that they now had removed release planning, cause it might compensate for poor development practices:
http://www.scrum.org/scrum-guide-updates
This doesn’t mean you have to stop all release planning, it’s just not mandatory anymore, and you should use it with care. This is an example of one small step you can take to improve the quality.

And quality, that’s what you need to focus on, no matter what agile process you are using. If you shorten down the feedback cycles, that would help you on the way. To get fast feedback, there’s a number of things you might consider:
…shorten the iterations:
http://www.itjoblog.co.uk/2011/06/the-iteration-is-too-long.html
…keep the releases small and deploy to production often.
http://kenschwaber.wordpress.com/2011/03/23/major-releases-are-a-failure/
…but maybe not 50 times per day?
http://www.thehackerchickblog.com/2011/02/continuous-deployment-for-continuous-learning.html

If you want to go fast, you need to move with a sustainable pace. You need to stay clean so you can keep going fast:
http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

So, to be able to shorten the feedback cycles, you need to focus on getting working software at the end of each sprint. And if you don’t, you’re definitely not alone. Over 50% of Scrum teams can’t get shippable code at the end of each sprint. Research shows that this will slow you down between 2 and 24 times:
http://scrum.jeffsutherland.com/2011/01/optimized-scrum-getting-to-done-done.html

There are many topics I didn’t cover this time, so maybe there is room for another post?

Visualizing project policies in Kanban

When David Anderson visited us last month, he mentioned that we must make sure project policies are explicit by writing them down. Recently, I had a some sort of epiphany that some of these policies could be visualized as well – directly up on the wall.

I prefer a whiteboard and post-its for our Kanban wall, at least as long as the team is co-located. This gives us an instant overview of the flow, and we gather around it to discuss how to optimize the throughput. It’s simple, but flexible.

To keep track of lead time and cycle time we update the tickets with important dates as we move the tickets across the board. However, I noticed that tickets weren’t always updated with necessary information for my statistics, so we needed a better approach.

First we standardized the way the tickets look, with fixed places for different items, but routine glitches still happened every now and then. Then we started to visualize the criteria for moving a ticket to a new state.

First arrow in the image above shows the transition when the ticket is prepared and moved into the backlog. The person moving the ticket fills in the current date in the upper left corner (the red square). Similar happens in the next transition from backlog to analysis.

When moving from development to test, another person must test the new feature (or defect).

When tickets are done, the completed date is added, accompanied by a subjective well-being using :-), 😐 or :-(. The latter is later used in the retrospective.

Most of these visual elements were added just a couple a weeks ago, but so far the notation seems to be easily understood and effective.

Are you visualizing any of your project policies?

 

P.S.: Thanks to Jim Benson for a great tip on how to measure the subjective well-being, as an input to the retrospective.