When I bring up checklists in a conversation with an agilist, many times the reaction I get is typically something like:
- "You can't script agile work"
- "Checklists aren't applicable on agile projects, you'll stifle creativity."
- ...
So what's the big deal about having checklists? It's what's on the checklist that matters. In my experience, I have found checklists to be valuable if used correctly. However the way you structure the list is what's most important. Are you creating a specific sequence of steps or procedures? Or are you creating a list of objectives or artifacts that the team needs to complete, with the freedom to create them in a way that makes the most sense. I've used checklists where the line items on the checklist are a single word or a short phrase. And I've used checklist where the items in the checklist are framed as questions. Both work fine.
Examples using questions:
- Does the team have a product backlog with user stories?
- Does the team have a up-to-date Roadmap showing upcoming planned releases?
- Is the top of the backlog groomed in preparation for the next iteration?
- ...
Examples using phrases:
- Product Backlog
- Roadmap
- Stories ready for the next iteration
- ...
You can also use checklist to remind the ScrumMaster/PM to schedule recurring meetings before the team starts their first development iteration.
In agile development I see great value in checklists that express outcomes. It's not about prescribing the specific approach to getting to the outcome. They are just reminders for the team to ensure they are covering all the bases. By the way, if you're using a definition of ready or a definition of done you're already using checklists. Look for other places where they might be helpful to the team.
One last point, I find checklists even more helpful when coaching new teams. Being more prescriptive with a new team is important when they are just getting started. But that's another topic.
No comments:
Post a Comment