A task board has been used by many teams when doing Agile development to have a shared place to manage tasks in the iteration.  I have used it myself in a lot of different formats when working with R&D development, customer projects and also working together with offshore teams.

It can be a great tool for the team and creates more collaboration, feedback and risk mitigation when having a visible task board.

But, you might also have more frequent requests from other teams or customers and maybe you also work with maintenance tasks of existing products in production. It can be challenging to combine focus in the iteration with different ongoing requests.

One alternative approach to the traditional task board and iteration planning can be a Kanban system. Kanban is the Japanese word for visible card and originates from the Toyota Production System. It is used to minimize inventory, enforce Just-In-Time and eliminate waste.

I have used the Kanban approach to extend the traditional task board with limits on the number of concurrent tasks in different states to reduce work in progress and apply a more pull oriented process. When working with many different specialists in one team, I have also seen high value by extending the board with more states to manage the work of the different specialists. It makes it much more visible and easier to follow the flow and find wastes in the process.

In one team we combined the Kanban approach with a two week release rhythm and that enabled the team to both have a rhythm of planed activities and also do more frequent business requests depending on their capacity and the business prioritization.

The combination of the more traditional iterative processes together with a Kanban approach is very interesting, and I think many teams and organizations will find a lot of value and increased productivity looking into this area.

By Mads Troels Hansen

Last weekend I took a minor holiday to the german capital, Berlin. On sunday morning I went out to find a place that served breakfast and I came by a nice litte bistro. I was with a small group of friends, so we ordered breakfast based on personal preferences. I had scrambled eggs, some had coffee, bread and croissants, and so on. After taking our orders the waitress went inside (we were sitting outside) for a few minutes. Then she came back -- or so I thought. She went by us, turned left, and entered the bakery that was located pretty much right next to the bistro. A few moments later she came out with a plastic bag that seemed to hold exactly what we ordered. She got back inside the bistro again, and a couple of minutes later our breakfast was served.

Reflecting on what I just saw, I concluded the following. Right after taking our orders she went inside and started on the scrambled eggs. At that time she probably notified the bakery on exactly what items to prepare for here. Afterwards she went out and got the bread that we had ordered, but no more.

Lesson learned. Keeping trusted key suppliers close, allows you to have very low inventory of the most "problematic" items. For instance freshly baked bread, which decays very fast, and is not suited for selling after a matter of hours. Even if you pay a higher price for picking up bread in smaller batches, the bakery -- not you -- will end up with the bread that can no longer be sold, and thus you will rarely have to throw out food. The strategy also allows you to spend the scarce space you might have in your bistro, on more value adding abilities, like setting up a table with a blender and serve smoothies!

The bakery is probably happy with the setup, as their incomming orders are now levelled out on the entire day, instead of having to prepare big batches in the morning. Furthermore the customers are probably more happy as the average time from bread leaving the oven until it is served, is now shortened, resulting in bread that is still slightly warm, and tastes better.

 

By Sune Gynthersen

Creating quality software on a continuous basis is a complicated business.

I think it is a sign of maturity if your team can admit that there are daily problems which are ultimately obstructing flow. While not everyone will appreciate that your team does a complete halt until the obstruction has been removed I think it is a necessity for a team to stay in good shape and continue to deliver frequently.

Just the other day I came to think about what were the most common obstructions of flow we see in software development environments. So here is my preliminary list -- I bet you have seen them all.

1. Build breaks
If you don't have a build, you don't have anything. Nobody is able to do any progress progress as the state of the product is unknown. Developers cannot check-in, as they will not get any response from the continuous integration environment. Testers cannot try out the latest build. Users cannot see the product in action, and the list goes on. A build break is like a blindfold, and you should treat it as such. Don't try to go anywhere until you have your vision back.

2. Test failures
If you have a failing test, you have dysfunctional software. Imaging somebody fitting some cool new styling parts on to a car with a busted engine. Now, who would ever do that? It really is the same with software. Why do any feature work on a software product which has a failing test? I know this can be hard to respect, especially when a deadline is closing in on the team. Deadlines however, does not justify continuing without stopping the line upon test failures.

3. Bug reports
If you have bug reports, you have dysfunctional software. There is no need to do any feature work, until the product is stabilized. Bug reports are even worse than failing automated tests as those bugs can only be reproduced by a human. You should not spend work hours on anything but writing tests for these bugs, and fixing them.

4. Any other blocks keeping the team from a steady flow
If you are experiencing an obstruction which is keeping from moving forward as fast as you could, suggest to the team that you stop doing anymore feature work, until you are able to eliminate the obstruction. One obstacle which I think is quite common is builds that take way to long time. "Yeah, but how can you build 2 million lines of code in less than two hours?" -- Well, I suppose you could start by reorganizing your code and build only the module related to a particular source control check-in. Hopefully you don't have modules consisting of 2 million lines of code!

I'd like to hear about any other obstructions you may have experienced in a software development environment.

By Sune Gynthersen