Being agile when there is no project

Sometimes I come across a team saying; "We can't use Scrum because there is no project. We just do what needs to be done on a daily basis." These are typically support teams, teams with a large support responsibility or teams with a lot of small projects running in parallel. On a rare occasion it is a marketing team who have seen the benefits in the development teams and want to be as successful but can't see how they can use Scrum. Well text-book scrum is not a good place to start. A better place to start is my previous guide. Having daily stand-ups are typically no problem in these teams. That is a good start but without the retrospects there is no obvious way to improve the process.

Most teams tackle this by having retrospects at regular intervals even though there is no iteration. And this typically works well. Recently I however heard of a team doing it a bit differently. They had a piece of size A3 paper on the wall and as soon as somebody thought there was something they could improve they'd put a post-it note on the A3-paper. Once the A3-paper was full, they had their retrospect. So instead of having regular retrospects they had them when there was a significant amount of things to discuss. This makes the retrospects "polled" when needed which is a very much along the lines of the kanban-philosophy I discussed earlier.

Actually using a kanban-board is another thing I would recommend these teams to use. The only practical alternative is to have iterations of one day length and we have to be a little bit pragmatic here. But the use of a kanban-board very well mimics the typical work of these teams. They typically have a short backlog of things to do for the next few days and as new things come in, it is prioritized and queued. Limiting the number of things that are worked on in parallel (as the kanban-board helps you to do) will help the team focus and also give outsiders a better view of what is going on in the team.