Colors fade, temples crumble, empires fall, but wise words endure.
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?”
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.
NOTE: This blog was originally posted on March 17, 2010
Several weeks ago, I attended AgilePalooza in Atlanta with some of my co-workers. It was a well put together conference and, I must say, a very cost-friendly conference. This was a one day event, that was primarily put together by VersionOne. I attended three sessions, and learned:
- It’s good to get away from the office to simply press the reset button. Even if it is for an afternoon.
- COMMON SENSE RULES! The basic principals of do what you say, treat others as you wish to be treated, enjoy life (which includes work since we spend a lot of time at it), and remember that tomorrow brings another opportunity and today is a blessing.
- Some people need to practice their speeches and make darn sure they are relevant to the topic as promised.
I have both Mike Cottmeyer and Lee Hensen (a.k.a. Agile Dad) in my “Like Minded” links. Both of these guys gave advanced topic presentations and they were very good.
Mike’s focused on scaling agile across the enterprise. The interesting thing is that at my work, we are doing this fairly well — specifically, buy in to the process and seeing value of implementing in other areas. But even more interesting, it seems the adoption of agile in big organizations seems very hit-or-miss, and primarily miss. I’ve worked in mostly large organizations until now, and I can tell you — I have felt the frustration and dismay that some of the folks in the room have. But you can make the case, and prove it can work — but you have to continue forging forward and not give up. Ensure you have all folks seeing the value and establishing the trust.
Lee’s discussion was a re-hash of one I’ve seen him present at the agile conference in Orlando last year. He updated, expanded, and expounded the content. It was a good refresher and a solid reminder that ownership and accountability must be at a team and individual level, not one or the other – but both. I know common sense, but repeated the need to establish trust amongst all of the parties involved and ensure communication occurs constantly. And importantly, keep focus on the value of the project or work product. One other thing he demonstrated is his method for estimating, very good and worth putting to practice. I’ll write more about that later and reach out to him to comment.
Here’s the links to their presentations at the AgilePalooza website:
BTW – This ‘palooza was nothing like my first Lollapalooza experience in ’94 – George Clinton, Beastie Boys, Smashing Pumpkins, L7, Cyprus Hill, Black Crowes and Green Day – just to name a few. That was a great time!