Thanks for a great post, to me this highlights the impoertance of having a shared goal that the team as a whole understand and is committed to. And also hints at a difference in approach between dealing with new development and maintenance. I am guessing that this project was dealing with a completely new application.

Do you think your situation had been different had you had a ‘mission statement’ published on your information area (wiki | whiteboard | wall | window, whatever you were using)? Or if you’d been involved in enhancing an existing product?

I am currently in a situation where we are shifting to agile, from a situation where (M)MF’s are handed to individual developers, who start their own workstream, which then goes into a (not yet identified) release. Since we are woking on an existing system, and these (M)MF’s can vary from new features, bugfixes to legislation compliance I am leaning to a kanban solution.

Having this flexibility to have a ‘living’ backlog and an ‘override’ slot I think is a good way to handle projects that deal with maintenance of an existing live product. Especially when you, as we do, have reengineering efforts and maintenance running in parallell. In these short cycles it would allow a critical production issue to override a reengineering effort in a way that a monthly release cycle in standard Agile would not. The exception is if you plan for it in advance (which goes gainst the idea in my view), or handle it outside of your project (which steal your resources and affect your release anyway).

For these ‘mixed scope’ efforts, I think I will from now on seriously consider a kanbanesqe approach…

//Johan

I’ve been using Kanban with teams that want to go Agile quite a lot recently. I find the Work In Play limits help teams focus on getting stories fully complete rather than getting everything out of dev and into test and therefore helps the value flow through the system.

The other thing I’ve found is it reduces the vast amount of time teams seem to want to use doing Sprint Planning…the ultimate goal of the meeting is simply to make a commitment to the stories for the next iteration/sprint. The quicker you can reliably do this the sooner you can actually get on with delivering the stories and their value.

Kanban can save teams going Agile a ton of time early on when they don’t have a good idea of velocity but have a pile of work to get on with.

I’ve also found that having teams focus on lean principles (Muda, Mura, Muri - check out Wikipedia for details) can be really useful so that people think about what they’re trying to achieve rather than how they’re going to do it which focussing on Scrum or XP or other specific Agile methodologies can sometimes lead to….it helps people build a more adaptive process.

Rgds

Rob

Karl