Agile Is About Velocity, Not Standups

It seems to me that any good process should provide assistance in four basic areas.

  • Predictability
  • Quality
  • Throughput
  • Morale

Predictability is important because you want to be able to tell people approximately how long something will take.  Quality is important for obvious reasons.  Throughput, the amount of work  you get done, should be positively impacted, and morale should go up if your process is a competent one.

Agile is handy for the above if you can create a meaningful velocity because it serves all four areas.  If you can effectively break down and point stories and have a meaningful velocity, you can tell people more accurate information about when you will be done.  If you effectively break down and point stories and have a meaningful velocity you can measure throughput and know if changes you make increase or decrease your throughput.  If you effectively break down and point stories with the input of test and business stakeholders quality should theoretically improve, as well as predictability as stakeholders are more likely to get what they are asking for.  If you effectively break down and point stories, and involve all team members as equals, morale is likely to be high.

Stand up meetings are nice, but that does not make for effective Agile.  What makes for effective agile is tracking and maintaining an effective velocity.  To do so means you are effectively breaking down work into stories that testers and business agree are of value and are done.  Agile is really organizing yourself so you can create and track a meaningful velocity.  By doing this good things collaterally happen.    If you have stand up meetings, and scrum masters and task boards and no velocity you are doing something, but it isn’t Agile as far as I’m concerned.  Have only the meetings and artifacts required to track and maintain a meaningful velocity and the rest will take care of itself.

When a group says they embrace Agile, ask them what their team’s velocities are and how long they’ve tracked them.  If blank stares are the response, then run.

Backlogs, Backlogs, Backlogs

Have an interesting circumstance.  If you are using an Agile/Scrum approach what I have seen historically is that each dev team has a backlog.  Different projects funnel stories into the one team backlog.  This allows you to clearly see the amount of work the team is tasked with doing.   My current client insists on having  a backlog for each project and sprint, so there is sort of a Cartesian product of backlogs.

I can understand how it may make project management activities easier, but it has only served to confuse me as far as understanding what work the team is currently and future tasked with.  I mentioned my questions, but the client assures me they know Agile and this is how Agile is done.  It has been interesting to compare this approach to others I have seen.   So far it seems to muddle the concept of a sprint as sprints have no start and end date, they end when all the work for the project/sprint backlog is done.   If it works better than one team backlog I’ll be down with it and waiting to see how it all turns out to make that determination.