Know more and connect with me on [Linkedin Profile].

Sunday, October 30, 2016

Why Velocity is a Broken Performance Metric?

In Scrum, we have two main metrics to measure Sprints. The first one is the Velocity, which is defined as the total story points of completely developed and tested User Stories. The second measure is Burned Effort, which is the total number of hours spent by the team throughout the Sprint. We use Burn Down chart to plot the remaining effort to check our progress daily and ensure we are on the right track, else we are advised to take action.


Velocity is designed to be used as a metric to measure and manage scope of work within a release. It is not designed as a productivity measure that we urge to increase overtime.

Many teams or sometimes managers consider Velocity as a productivity measure and insist that, teams should optimize their work and increase their velocity always. Optimizing engineering work is an acceptable target, but Velocity is has another goal to play. See what happens when teams are urged to increase their velocity overtime:
  • They tend to estimate new stories in larger sizes. So a troy that is used to be of size 3 will be sized as 5.
  • They frequently resize finished stories as if it took more than the planned effort and consider this as a correction.
  • They relax Done Definition. So, more stories are earned even if they are not really complete. You will know just before the release date, when you find a lot of bugs are accumulated and needs a lot of extra time to be fixed. 

This usually shows false increase of Velocity or inflation, where the increase in Velocity does not represent actual increase in value delivered. But managers may feel happy achieving better Velocity over time. Is this misleading? Yes of course. If you are already improving, why you may consider other ideas for improving?!

So, the point is, do not use Velocity as a measure of team productivity, but to manage release scope so that, you are able to track your progress effectively throughout the release.

Optimizing your work in Scrum has a different set of measures and actions, let me highlight some:

  1. Ensure a strictly Done definition overtime through the heavy use of automation. So, each Sprint is producing a really potentially shippable product increment. There are no stability Sprints at the end of the release any more.
  2. Ensure  the reduction of number of test/fix cycles. Testing is valuable, but too many bugs are a waste that switch our focus from learning to write better code first time to expensive cycles of test-fix-retest. 
  3. Ensure you finish almost all stories planned in the Sprint and avoid partially done stories that are moved from Sprint to Sprint.
  4. Reduce Sprint timebox over time. As example, if you started with a Sprint of 4 weeks then optimize to switch to a 3 weeks Sprint, then to a two weeks Sprint, etc. Agile prefer shorter cycles. Per second Manifesto principle: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

Finally remember, Velocity is a metric to manage Release scope, not a metric to measure team performance or productivity.

Notice: Illustrations copyright Jurgen Appelo, Management 3.0

Monday, October 10, 2016

Is Time Pressure an Acceptable Reason for Poor Quality?



I worked with many teams who had the same issue. An intense time pressure that led them to react by doing either of or both of the following:
  • Coding in hurry, and falling into too many cycles of testing and bug fixing, which delayed them much more time and made the situation worse.     
  • Delivering a code that is full of bugs, which makes the customer distrust the team.

When I ask developers and team leads, why they fall into this situation? They always point to the same reason. They had unreasonably forced deadlines and pressure. They reported to business people about the situation and they refused to listen. That meant the whole responsibility was on the business people or the customer himself. Developers see themselves as victims of the bad guys. They wish that the world would change around them and give them enough time to do their work the right way.

This perspective gives the whole blame to the pressure of business people and customers and no blame to the development team. And, of course business people blame the development team. This is a finger pointing situation where everyone is blaming others. I would like to ask some questions to highlight my point of view:
  • Who knows more about software engineering principles? Developers, business people or Customers?
  • If a customer pushed you for the sake of optimizing your work, or even as a sort of greed. Is it helpful for you or your customer to ship a buggy code?
  • Do many cycles of testing/fixing support you or your customer to deliver faster or just wasting more time?

Under pressure, if developers decide to voluntarily work all weekends and a lot of overtime and ship the right product, it may be OK, relatively. Developers sacrifice their personal life for the sake of happy customers. It is a lose-win situation, which is not optimal, but at least someone wins.

What is happening is much worse. We fall into a lose-lose situation, where developers are exhausted from working too much overtime, shipping a product with too many bugs and on the other end dissatisfied customers and business people. What could be worse than this?

Developers, please stop trying to change the world around you and start changing yourselves and your responses. You know your craft and you should act responsibly. I would like to give an example of what you should do as a professional.

Your car is broken and you need to fix it. You have a 500-mile journey and you are in a hurry. You went to a car maintenance center. After a careful investigation, the engineer told you that it would take 6 hours to fix. You asked him to finish it in just 1 hour due to your situation. The mechanical engineer knows his craft and work, you assume. I would fictionally describe two responses because of the intense pressure to finish early.
First Response: The engineer just listened to your demands and did an unreliable fix to the car in one hour. You were happy to be on time. You took the car and drove it, and in the middle of your journey at 2:00 AM in an uninhabited place, the car stopped, and the fire caught your engine. What would be your feelings about the mechanical engineer? Are you still happy that he fixed your car in one hour? You asked him to finish in one hour to support your urgency not to make your situation worse.

Second Response: Imagine this. The engineer took your request into consideration and consulted other engineers to optimize the time of fix. And the engineer came back to you with a full explanation, facts, and context to explain the constraints. He told you, ”there is no way to finish in one hour, but we  will do some high priority fixes in parallel and we will skip some minor enhancements. Some other fixes can be delayed until you reach your destination.” With all these optimizations, they could finish in two hours, not less. You were not so happy, but you felt they were disciplined and professional. The fix was well done and you drove your car to your destination safely (but with a one hour delay).

From these responses, which one would be appropriate for the customer? What is the response that is expected from a disciplined engineer or a professional organization? What is the ethical reaction that you should take regardless of the intense time pressure?

Nowadays, software is critical to billions of people's lives. Billions of dollars are lost because of bugs in software systems. People die from bugs in software. Can you imagine a bug’s consequences on radiology treatment machine? A bug in a blood-bank software! A bug in charging a mobile battery that may explode it! Or at least, do you know how many disappointed users there are, because of poor quality software?

ACM (Association of Computing Machinery) developed "ACM Code of Ethics and Professional Conduct" for software developers at [http://www.acm.org/about-acm/acm-code-of-ethics-and-professional-conduct]. The declaration has 8 moral imperatives. The second one is "Avoid harm to others". In our described  scenario, you are not only harming others, you are harming yourself as well.
As a conclusion, please:
  • Do not try to change the world around you.
  • Change yourself and choose your reactions disciplinary.
  • There is no reason to fall into lose-lose situation and harm your customer and yourself.
  • Always write clean code and follow technical excellence practices. 
  • Technical practices will not delay you, but will save you time and hassle.

And remember, Be powerful and be happy.

Notice: Illustrations copyright Jurgen Appelo, Management 3.0