Monday, September 24, 2012

Agile Checklist - are you kidding me?

Just hearing the word checklist in connection with agile development makes a lot of people cringe. When I hear checklist, I tend to think of repetitive work where the worker is provided a step-by-step set of instructions with the hopes of achieving consistency in quality and production times. Think line workers or fast food employees doing the same thing over and over. Or places where there's significant turnover like call centers. None of those examples sound even remotely similar to agile development projects. So at this point you might think you know where I stand on checklists. Maybe you do and maybe you don't.

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