When you work in an Agile Coaching group – whatever it's called – a "competency", a "practice" or some such thing, and some of you get together to talk about what you should do to improve what you do, it's almost guaranteed that at some point, someone will suggest that it's very important that you all "Eat your own dog food." OK, maybe you'll be lucky and they won't use this gastro–intestinally challenging metaphor – they'll merely point out that if you call yourself Agile coaches, you should be using Agile to manage your work.
Sounds like a good idea surely? If we're pushing Agile, advocating Agile, coaching people in Agile, surely we should be using it ourselves. Well, yes, but in my experience, this is a lot more complicated than it sounds.
Here are some thoughts as to why.
1 Explicitly break the big jobs down into smaller bits or
2 Run the jobs at a much looser, more general Kanban level
Change needs a budget. Often when members of a practice get together, there seems to be this idea that the tasks that are handed out can somehow be done in coaches' "spare time." This doesn't really fit in with one of the fundamental principles that we're always trying to explain to our clients – change needs a budget. Somehow it's very easy as coaches to talk ourselves into the idea that change needs a budget unless it's us that needs to pay.
Actual velocity is always unpalatable – your own velocity, doubly so. We should pay very close attention to our actual velocity with the tasks that we assign ourselves – unlike software development (or, actually, maybe exactly like software development) there will be a tremendous variety in the tasks that get assigned – some will amenable to being completed as a result of sustained effort, some will require feedback, some will be long latency. We should try to provide some kind of categorisation of tasks and then, over time, develop an understanding of what the actual velocity/cadence is for different kinds of task.
What is the natural cadence for an Agile Practice? This will be different for every practice, but my feeling is that it might be much shorter (weekly? – everybody who's in town gets together on a Friday afternoon – commits to one thing they're going to do in their "spare time" in the following week and then everybody goes down the pub). Monthly? Three monthly (all practice work is done as part of collocated day–long workshops, once per quarter).
Is this really the right time to test your favourite lifecycle management tool? The industry has settled on Jira, so we should probably use Jira. Yes, I know there are problems with it but we should probably know what they are. Yes, I know there's some dinky open source thing, that does Kanban really well and integrates with eclipse and all. But still, we should probably use Jira.
Written by Mark Stringer: this is me