Every agile team wants to run faster than a speeding bullet and leap tall buildings in a single bound. In agile parlance, we all want to increase our true velocity — the amount of work we accomplish in every sprint.
Being a skeptic by nature, I say “true” because it’s easy to increase apparent velocity without really getting more done.

There’s an old saying: “Time, Quality, Scope — Choose any two.” An easy way to reduce coding time is to minimize testing. But lowering quality leads to defects, and defects increase rework. If we slash scope and oversimplify a feature, many customers won’t be able to use it. A feature that most people can’t use is mostly useless.
In practice, there are three well-worn paths to increasing true velocity: (1) Optimize scope, (2) Enhance infrastructure, and (3) Reduce rework.

  • To optimize scope, carefully select just the right set of requirements that will allow customers to use the feature, easily and effectively. No more. No less.
  • To enhance infrastructure, leverage technology and processes to reduce the human effort needed to take a feature from conception to production.
  • To reduce rework, collaborate with stakeholders to ensure the correct features are implemented correctly. 

Here are twelve key checkpoints that can help your team step forward, without taking two steps backward:


Control Scope 

  • Are we surveying customers to determine must-have threshold features? 
  • Are we implementing only the threshold features first? 
  • Are we documenting the acceptance tests before we write the code?
  • Are we implementing the simplest thing that can possibly pass the acceptance tests?

Improve Infrastructure 

  • Is our unit-test and integration-test scaffolding as helpful as it can possibly be? 
  • Is our continuous integration automation as streamlined as it can possibly be? 
  • Is our software development lifecycle process transparent and clearly understood?
  • Is our team using the best tools for the job?

Reduce Rework 

  • Are we getting feedback from customers as early as possible (preferably by providing access to a beta version)?
  • Are we re-running all acceptances tests against the final release candidate before a major release?
  • Are we writing tests to prove bugs exist before we fix them?
  • Are we documenting support case solutions in a knowledge base for future reference?
If your heartfelt answer to any of these points is “Not so much”, then maybe it’s time for a retrospective with the team, to discuss ways to work smarter and get more done.

Have you found other ways to increase velocity on your own team? If so, post a comment, and lets start the conversation!

Ted Husted is a Release Engineer for Nimble AMS. “My job is to make sure we ship everything that’s done, but not before it’s ready.” For more about Enterprise Development on Force.com, visit DreamOps.org.