Measuring scrum teams' velocity acceleration

No matter how exactly the scrum teams decide to measure their velocity, how the people are incentivized or motivated to drive productivity improvements, at the end of the day what really matters is the elimination of waste due to unproductive activities and increased output of value for our customers.

I found this blog post by Jeff Sutherland (Six Signs your Team’s Acceleration is Too Good to to be True) offering a great insight into the challenges with measuring velocity improvements of Agile scrum teams.

Why should we aim for shorter sprint duration

I was asked the other day why do I prefer shorter sprint duration, say 2 weeks instead of one month. I’d like to have shorter sprints for a number of reasons:

• Assuming we are motivated to demonstrate something tangible at the end of every sprint, with shorter sprints we end up looking for ways to produce something tangible sooner. The resulting sense of urgency in itself is good, although this is not about making our engineers work harder, that’s not the point at all.


• Shorter sprints encourage teams to master ways to break down large chunks of work into smaller independent user stories and as a result to better manage technical risks, helping increasing the odds of delivering more value at the end of each iteration.


• Shorter sprints motivate us to scope and size just enough level of detail and just enough user stories ahead (Just in Time) to help us deliver value and move at brisk pace. We gradually find ways to reduce and eliminate waste from our processes. For example, we learn that a user story that is thoroughly researched too far in advance often ends up collecting dust on our backlog as we may switch our priorities before we ever start working on it.


• With shorter iterations there is less time to procrastinate. Every day the team goes through daily stand up and it does not take long before we all know who makes good progress and who needs help.


• Shorter sprints help better manage risk across multiple scrum teams within a release. The longest a product team will go without knowing something is wrong is two weeks instead of one month or longer.


• With shorter sprints we become more nimble, more Agile as a vendor and competitor. In only two weeks we can pivot, change our priorities based on newly acquired knowledge, instead of sticking to the plan for one month or more.

Self-promotion vs. Tall Poppy syndrome

Some years ago my first manager/mentor in Australia warned me during my exit interview, "to beware of tall poppy syndrome." At the time I took it to refer to the price of doing what's right. Later I learnt this was a more general reference to Australian culture of low tolerance toward people who stand out from the crowd.

Australian is not the only culture where keeping low profile is a common norm. Growing up in Russian-speaking Moldova, I remember how children were taught modesty. The teaching was supported by a popular illustrated fairy tale about nasty, selfish letter "I" who no one liked, and an old folk proverb roughly translated as "I is the last letter of the alphabet". Indeed, the Russian equivalent of "I" is the letter "Я" and it is the last letter of the Russian alphabet.

Not surprisingly, people brought up in cultures that place high value on humility and teamwork often find it difficult to adjust when moving to the USA, where every growing child is encouraged to seek stardom, and a strive for individual achievement is widely considered to be a key success factor.

This HBR article (by Dorie Clark and Andy Molinsky) takes a look at how people deal with these differences in the context of self-promotion in a business setting, and offers some good tips.

Personally, 14 years after moving to the USA I came to see the self-promotion as a way to simply inform others about me. When I frame it like this it does not feel like bragging at all, not in the culture where others are often genuinely interested in my personal accomplishments...