Mike Cohn’s description of a task board is the clearest I’ve seen. And it fits well with my preferred ways of working.
When the Product Owner doesn’t have enough stories to drive development, try running an incremental analysis project that keeps one iteration ahead of the developers. The deliverable from each analysis iteration is a modified Product Backlog, ready for the upcoming development iteration’s planning meeting.
Whatever the reasons, it’s sometimes a fact that the Product Owner just doesn’t have the backlog prepared in time for the next development iteration. This can have a destructive effect on the development team’s morale and productivity, and must not be allowed to continue for too long. So something we’re trying on a current project of mine is to set up a parallel “analysis” project, to be run using the Scrum process. (This is certainly not a new idea; for example, Martin Fowler talks about this technique in Planning and Running an XP Iteration.)
I expect the mechanics of the two projects to work something like this:
Your team holds a daily scrum or stand-up meeting. But for some reason you all decant to some other room for the meeting itself. Maybe you don’t want to disturb the other teams who share your bull-pen. Or maybe you’re used to meetings being in the Boardroom, so you just head off there out of habit. Or maybe someone once told you that a change of scene helps meetings to focus. Whatever the reason, don’t do it!
The daily stand-up should be about the tasks on the board. If the board isn’t in the room with you, the meeting will lose its structure. Sure, everyone will still take their turn in describing what they did yesterday and plan to do today. But without the task board there are no visuals for the listeners, no cues for the speaker and no controls for the coach or tracker. No-one can point to the tasks, so it becomes much harder to discuss tasks, disconnects, blockages etc. It is also now impossible to re-plan during the meeting. Finally, your task board should also be the place where you display your big visible charts. If you hold your daily stand-up somewhere far away, you can’t discuss them. No tactical analysis or retrospectives. No daily update to maintain momentum. Huge loss of communication. Huge loss of focus.
The more I think about it, the more convinced I become that selling agile at all is a mistake. Certainly as a coach/manager, what interests me most is the ‘process’ side of things, and agile is always an interesting and rewarding approach for both me and (I hope) the software team. But what interests my bosses is more often the business value delivered to the user base.
I’ve never been someone who believed that it works to simply plonk a methodology onto a team straight from a book. Every team is different, and every business is different; enforcing conformance to some pre-determined monolith is likely to bring out as many minuses as plusses. And I believe that’s true of the agile methods just as much as it is of the heavyweight ones. What’s more, the successes I’ve been associated with have all been due entirely to having the team grow their own processes – gradually, incrementally making the changes required by the current situation. Only when the current way of working is shown to fall short in some respect does the team call a review and work out a different approach. There is never any change simply for the sake of it.
Of course the agile movement directs and informs my thinking, and hence my coaching and management styles. And all of the teams I’ve coached have become increasingly agile over time, without any of them ever consciously adopting a ‘book’ method. The stakeholders get to learn that iterative and incremental delivery is better for everyone, that feedback loops must be short, that quality helps the team go faster, etc etc. But most will never hear the words ‘agile’, ‘SCRUM’ or ‘extreme’.
In the future though, I do expect I’ll be using the word ‘lean’ a lot…