Tag archive

planning

Words Mean Things – Velocity

in Agile/Humor/Randomness by

Colors fade, temples crumble, empires fall, but wise words endure.
Edward Thorndike

As everyone knows, many challenges we have in software development are around semantics. People seem to really get wrapped around the axel when in a meeting team members (including stakeholders) start using words that are similar to others or there is an assumed shared meaning. So this is not a very easy problem or challenge to solve, so I thought we would start discussing some of the terms that occur regularly in the agile development world.

Let’s start with Velocity.  In my experience, sometimes it seems like the word velocity may have been a poor choice. When we talk about velocity in terms of agile software development, we are referring to the rate at which a team produces working software.  Velocity is a metric and knowing a team’s velocity is key to agile planning, not to mention it helps drive predictability which is a major benefit of using iterative processes.

Most people when they think of velocity with agile, they instantly say “how fast the team produces.” This is only natural when you look at the dictionary definition:

Velocity – speed of motion, action, or operation; rapidity; swiftness

Now for the problem that this creates. Once the velocity for teams is published, the stakeholders and managers automatically start asking the question, “can’t the team go faster?” Or, “why is that team slower than the other?”

Speeding to the limitI think that instead of focusing on speed, using a term that relates to quantity such as “Volume” might have been more appropriate. With a definition like:

Volume – amount; quantity. Also, amplitude of sound.

The idea of quantity is clear, but it is also an appropriate metaphor to relate it to the wave or amplitude of sound in that it can vary. If we originally used the word Volume, would we hear “how do grow our volume?” Or, “you all need to turn it up and get more out!”

Another word that may also be good to use instead of Velocity is Throughput. When I worked in the process manufacturing world, that was the word we used when we talked about how much materials were moved through the production line or how much ultimately came out the back. We also use throughput when it comes to processing data, so it only makes sense that we would use throughput. This would lend an opportunity for a new abbreviation, much like bandwidth of an internet connection — 300 MB/s, we could have 28 SP/i (or Story Points per Iteration).

I guess at the end of the day, the word Velocity works as well as any other word and we are most certainly going to re-write all the books. And even if we did use a word different than Velocity, the stakeholders and management would still want more and want it faster.

But the next time someone asks your team to go faster, try getting them to see Velocity not as speed, but more as Volume.  And explain to them that your team is more like bucket and just like that bucket, it can only hold so much.

Or, tell them that your team is like a fine-tuned system that has a particular throughput.  You may be able to do some small tweaks to change the throughput, but pushing it to much will simply result in bottlenecks somewhere down the line or all-out system failures.

Let me know what you think?  Does the word Velocity cause challenges for your organization?  Look for more posts in the series and your suggestions for new words to explore are welcome.

Five Simple Guidelines to Agile Metric Bliss

in Agile/Agile Engineering/Project Management by

Over the past couple years, I’ve had the opportunity to work with many great teams in many industries. I often work with teams and their managers to generate reports. In doing so, I quickly realize that although teams may be working to adapt and leverage one of the frameworks that fall under the Agile moniker, they are not yet adopting or clearly understanding the Agile Principles and Values. This comes through clearly when we look at the kinds of reports people are using.

kittenI’ve seen dashboards that compare multiple team’s velocity. Or, the classic utilization report that shows time worked by team member. Or, the quality reporting that focuses on who versus what. And then there is the singular snapshot that represents percentage of backlog done – doesn’t sound that bad until you have a manager have kittens because the percentage is not what as expected.

Now, I have to admit — I’ve made all these reports before and used them myself. Sometimes the purpose of the report had an intended outcome, but my best intentions sometimes resulted in gamesmanship of the numbers or fear by the team and in one case, a team member pulled me aside worried that he may be culled.

Let’s face it, all metrics and reports can be used for bad. But what do you need to do to create good metrics? There are some great resources all over the internet that help answer this question, but let me give you my top five things you can do to make your metrics effective while fostering an agile environment:

  1. Make them Transparent. This is obvious, but often I see people create reports and don’t share them. I get that there are some reports for “their eyes only”; however, in most cases, if not all, unless it has salary information — make the reports visible to everyone – the Team, Stakeholders, Managers, and even Customers.
  2. Make them Visual. Use charts, shapes, colors, and or pictures over a table of figures. We do this for three reasons – easy to read, reduces the likelihood that people focus solely on outlier values, and in many cases — creates conversations. By the way, use colors wisely — just like words, colors mean stuff.
  3. Follow the Trends. Goes hand-in-hand with visualize — a good metric should be informative provided indicators that make it easy to see if the needle is pointing up or pointing down. Trends generally allow you to decide if what we are doing is good or bad, and reduce snap decisions.
  4. Make them Relevant and Timely. There are the out-of-the-box metrics — burn downs, cumulative flow, burn ups, cycle time, and or velocity – that should be maintained on a daily, weekly, or iteration basis — updating them in arrears does no good. This is the same for all agile metrics. Since the goal of any metric should be to continuously improve in some way, reports/metrics that are created or updated weeks or months after the fact does us no good. And, couldn’t we better utilize the time and brain power on something current.
  5. Have a Purpose. Every report or metric needs to be leveraged for importance. If you cannot answer two questions about a report or metric, maybe you should stop spending time and money to create the report. First, why are we creating this report? And, second, what will we do if the report is indicating a need to adjust or change?

Now, these are my five simple (and in some cases, general) guidelines – what are your’s? Do you have any suggestions?

Always keep in mind …

Working software is the primary measure of progress.

Continuous attention to technical excellence and good design enhances agility.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Agile Manifesto

Go to Top