Hyper productive…, don’t measure the outcome

agile, blog

Scrum is great, when implemented successfully it gives you several benefits. One of the benefit that is also often mentioned is hyper productive output of your development teams.

I read several blogs about hyper productive and I could not find a real definition of hyper productivity. It is not defined as x % more output than current output. What if a team improves themselves and only the quality is improved? Is the team become hyper productive? What if you have a team with freshers and one team with the most experienced team members of your organisation, can both teams become hyper productive? I believe that measuring the outcome of a team is possible but if this proves if a team is hyper productive… I don’t believe so.

After some discussions with companies/organisations like Bol.com and reading books/blogs about Lean (management) last months I came to conclusion: “You should not measure the outcome, but create the environment to become hyper productive”. An organisation should do everything to set the team in paosition to score. If the team is able to score you should have trust they will score the goals.

I believe a team needs the following to become hyper productive:

  1. Constantly Improving;
  2. Good Preparation;
  3. No Dependencies;
  4. Have Fun.

In the sections below you will find more information about the above values.

Constantly Improving

A team should constantly improve themselves, remove impediments constantly. A software development process is never stable, technique changes, requirements change, the organisation changes, knowledge of people changes, everything changes. When a team does not improve themselves, by adapting themselves to the new environment they will not benefit from the new opportunities and even be slowed down when new impediments arise.

Good Preparation

Agile or not, you need to prepare your work before you start working. I believe when product backlog  (PBL) items are well prepared, the team is able to have a high velocity.  

I hear you thinking, what is well prepared? Do I need to write a complete functional and technical design of 42 pages? I would say it depends…. However, I tend to say no 🙂

Preparing PBL items for me is enough communication between team and product owner. The team should  clearly know what the goal is of the PBL items, it should be clear what the product owner expects and there should be some rough ideas about the technical solutions. The team should be able to create a work breakdown structure that consists out of tasks of maximum eight hours.

Of course, there will be situations where a team prepares a PBL item and something unexpected happens during realization. That’s life, you have to deal with it. That’s why constantly improving is important, the team should perform a retrospective on the situation. What can they learn from it, how can they improve?

No Dependencies

Dependencies between teams increase communication. Communication is difficult, there are a lot of blogs/books/articles about how difficult communication is. The search term Communication results in 376.000.000 hits in Google, Communication difficult results in 124.000.000 hits… it is allowed to say 32% of the page about communication is about how difficult communication is?

When you have multiple teams that are dependent on each other, the team with the lowest velocity will partially determine the velocity of other teams. The customer teams have to wait until the supplier team delivers their PBL items. Additionally, when there is one supplier team for multiple customer teams, who comes first?

Another dependency could be on the product owner who has the requirements not yet clear.A team could start working on the PBL item. However, when the product owner is not available, or needs to discuss the requirements first with the real customers, the team can’t continue. When they continue there is a risk they have to do rework. They have to wait until the requirements are clear, this kind of dependencies will stop the team to become hyper productive. It is also in conflict with the previous precondition, preparation.

Have Fun

When a team doesn’t have fun, it will never become hyper productive. Are you motivated to do something that you don’t enjoy?

Fun is not only telling jokes, fun is much more. To have fun you should have for example:

  • Good Hardware, fun is not waiting for a software build that takes 22 minutes;
  • Office, Windows in the office, air condition during a warm summer, a desk that is adjustable in height;
  • Appreciated by colleagues or management. When did you receive a compliment for the last time? Didn’t it make you feel good? The power of giving and receiving compliments is ofter under estimated. However, giving and receiving compliments does often increase the fun in the team.

When all the above is in place, I believe a team can become hyper productive. How do you know when your team becomes hyper productive… you will know trust me, trust your own gut feeling.

During writing this blog I already changed partially my vision. Please leave your comments, I don’t  mind changing my vision again when it becomes a better vision. 


Leave a Reply

Your email address will not be published. Required fields are marked *