Time for a Demo?

When I first learned Scrum, the idea was to have 30-day (4 week) iterations with a demo at the end of each iteration. Today I see teams that have iterations from 1 to 4 weeks, or in the case of Kanban, no iterations at all. So the question is, how often should there be a demo?

I’m a believer of getting sign off on a user story once it's done. This usually comes from the person who wrote it, who may be a proxy to the product owner. So when we get to the end of the iteration, all the stories that are completed have already been reviewed by someone on the business side but not necessarily the product owner. 

So the questions is, If it’s a short iteration, does it make sense to have a more formal demo of the stories? I think in some cases the answer is “no.” 

On one of my projects where we were using Kanban, we planned the demos every 4 weeks. This allowed us to finish a set of stories that were part of a feature, so the demo was more complete. I think this approach works with short iterations as well, only conducting the demo after every second or third iteration, depending on how long your iterations are and how complex your features are. 

There's also another consideration. I work with clients building applications that will get rolled out to the organization. On these projects, we need to consider organizational change management. The demos serve as a way to help introduce the new application to the end users. So from this perspective, there may be a large number of attendees at the demos. This is another argument for less frequent demos.

So while a demo can be held at the end of every iteration, even for short iterations, there are some reasons to hold them less frequently. 

Trying New Things

Over the past weekend I went ice climbing with my son. He is a pretty serious climber and I've picked it up because of him, but neither of us have ever ice climbed before. We went to a place near Cedar Falls Iowa that ices down a grain silo. It's really different from the sport climbing we've done, but it was fun and by the end of the climbing day, I was able to make it to the top of the silo.

How often are we open to trying something new? In my work environment, we follow an agile process based on Scrum. We do 2-3 week iterations, with planning sessions at the start of each iteration and demonstrations and retrospectives at the end…but sometimes you have to try something new.

I had a project a few years ago where the work wasn't as predictable. My team couldn't come up with estimates because they hadn't done anything like the work that faced us, so I decided to throw out the iterations and use Kanban. In this case, trying something new paid off. The Kanban approach worked well, we were able to get the work done and everyone learned from it, especially myself. When I was faced with a troubled project a few months later, I knew Kanban would address the challenges and get the project back on track. 

So don't be afraid to try something new. It could be as simple as changing the questions you ask in your daily stand up, or as complex as trying a different methodology. If the approach you're taking doesn't seem to be getting the results you want, inspect, adapt, and move on.

The Zeigarnik Effect

An interesting discussion came up on one of the agile groups I subscribe to; the Zeigarnik effect. What this theory says is that people remember unfinished tasks better than they remember finished tasks.

The context of the discussion was retrospectives. During a retrospective, people will be less likely to remember the tasks that completed smoothly in the project, things that fall under the category of what did we do well. Since these are important, you want to make sure people remember them.

One of the tools I use in retrospectives come from Norman Kerth's book. The tool is building a timeline of the project and having people identify key events throughout the project. This is one way to help people remember. Another technique is to hold your retrospectives often; at the end of the iteration rather than waiting until the end of the project.

As I was thinking about the Zeigarnik effect for this post, I also realized it impacts your work in progress (WIP) limits for Kanban. The more things you have in progress, the more things that you are trying to remember. Get your WIP to high, you start forgetting what you're supposed to be working on. So how much unfinished work are you trying to deal with?

On a side note, if you teach, you can use this effect to your advantage. Give your students an assignment right at the end of the day. They will keep thinking about it until they have time to finish it. They'll learn their lesson better than if they finished the assignment in class.

The Zen of Kanban

I'm using Kanban on one of the projects that I'm overseeing right now. It seems to be a perfect fit for this particular project.

Kanban came from the Toyota Production System (TPS). The idea is that you don't stockpile parts, they flow as you need them to the production line, minimizing your work in progress. If you want to read more about Kanban and software development, here is a good article.

On this project, the product owner had already pulled together some requirements before we stepped in. Our first step was to organize the requirements into a backlog and get him to prioritize the work. Then we asked him when he wanted the next release to be ready.

We did some high level estimates and then cut the backlog in half, saying we thought we could get through half of it by the release date. That was the first step to reduce our work in progress.

I have two developers on the project, so they each picked a feature from the top of the list and got working. They did some more requirements gathering, design, and build and unit test...keeping the product owner involved throughout the cycle. They then did a demo for the product owner, getting his approval that the work was done. At this point, these features were ready for final testing (by another group), and the developers picked more work to start on.

What has really made the Kanban approach work well here is that the team was small, the work could be timeboxed, and the product owner was involved and flexible about how the work was delivered.

Like Scrum, Kanban doesn't dictate specific software engineering practices. In this case, the developers are following some standard practices that we use on other projects and I have another team member doing code reviews as part of our QA process. The final testing is being done be another group in the organization and because that decision was made after the project got started, we don't have them looped into the Kanban approach. We are planning an iterative approach to testing, so they aren't waiting for all the work to be done before they start. We'll have to work on better integration of the testing approach on our next project.

So if you have a small project (maintenance releases work well) and want to try something different, consider Kanban. I've found that focusing on one or two features at a time make the team more efficient at getting the work done.

Multi-tasking and Kanban

I was at a presentation on Kanban put on by the local agile group tonight. I'm familiar with Kanban, but still picked up some good information.

One thing that struck a chord with me had to do with multi-tasking. In a previous blog post, I've discussed how multi-tasking doesn't work. In tonight's presentation, a statistic was shared that software developers waste 20% of their time when they are multi-tasking.

Kanban is the solution. The idea is you only take 1 task at a time and work until that task is done before you grab another one. You don't have a long backlog of work and you're not trying to manage a full plate of work with all the task switching that goes with it.

I find I'm more successful when I take this approach to work. At the beginning of the day, I figure out the tasks I need to accomplish. While I'm working on a task, I do my best to avoid interruptions. I ignore my email and avoid other distractions (or at least I try). I'll catch back up on email and other stuff when the task is done. It helps when I can keep tasks to an hour or less. If it's a big project, I break it into smaller chunks.

So if you find you are often interrupted, look at how you can break your work into small chunks and turn off the distractions while you complete your task.

Kanban for process improvement

Kanban is a popular topic these days in the agile world, even spurring some debate about whether or not it is a lean technique. While is does move away from some of the standard elements of agile such as fixed length iterations, in my opinion this is another good tool for any project manager's toolbox. If you're looking for a good overview of Kanban for software development, go here.

As I was thinking about it, I could see how Kanban would be especially effective in Business Process Improvement (BPI) where Lean is being used. The idea to BPI is to apply Kaizen; find an improvement, implement it, watch the results, and then figure out the next improvement and repeat the cycle.

Kanban would work well because you aren't trying to build up a long queue of improvements. The completion of one improvement is the signal to examine your process and identify your next improvement; just like running low on a part in manufacturing is the signal to get more parts.

For example, you've implemented a new business process in your organization, most likely with a BPM tool. A good BPM tool will capture metrics on project execution; how long are various steps taking, are there bottlenecks, are exception paths being followed a lot etc. Based on this, you would identify the next improvement. Maybe, for example, putting in some business rules to automate an approval that is currently a manual step. This improvement would go through your development cycle and be implemented. At this point, your queue is empty; signaling for the next improvement. Or it could be you already have a list of improvements, you just need to pick the next one off the list and move it to the first queue in your development process, which may be elaboration. When it moves on to the next queue (development maybe), something else moves into the elaboration queue. With Kanban, you've turned your development lifecycle into more of a pipeline and your process keeps improving.