When SMART goals are not so smart

Published September 26, 2016 by
Simon Almstrom

We have learned that goals should be SMART: Specific, Measurable, Achievable, Realistic and Timely. As a product owner, I apply this in many situation to help the team focus and to make progress. However last week I threw out the SMART goals and got fantastic results because of it.

SMART goals are generally accredited Peter Drucker for his concept of Management by Objectives. SMART goals are a way to align departments, teams and individuals towards the goals of the organisation.

Being a Product Owner, it is natural to set goals for my teams. I set goals to help my teams lift their eyes and see the bigger picture. This can for example be towards a milestone delivery or a quarterly goal in a continuous product quality effort. But I also set short term goals such as what business value that shall be delivered by the end of a two week sprint.

Although I often use SMART goals there are times where I avoid them because I have found them to be contra-productive. This is usually the case when there is considerable uncertainty around either what the product is, what the team’s capacity (sometimes called velocity) is or what the solution shall look like. All of these factors are usually found in the product or feature discovery phase.

This was the case last week. As a team we wanted to look at a better way to automate our testing. We had done some clumsy attempts before but nothing that we thought was particularly productive. So we decided to set aside a week to look at this. We put the whole team in a room and made sure that no-one interrupted them and instead of goals we set an ambition: “We shall give ourself a running start to our long term goal of higher automated testing coverage”.

As you can see there is nothing SMART about this ambition. I had played around with some SMART goals but found them to be contra-productive for two reasons:

Firstly, I found that focusing on specific goals we were loosing the opportunity to take a step back and questioning the way we had done things so far. Also, I was afraid that the goals would steer us towards a specific solutions instead thinking outside the box and finding new ways to solve the problem.

Secondly, I wanted to celebrate the progress they had done in finding new solutions not in achieving goals. I felt that if the goals are too specific we would either have set them too low and then we would run the risk of feeling disappointed that we did not set them higher. Or we would have set them to high and then we would have felt that the week was a failure because we had not achieved the goals. There was not way to win.

So how did it go? The team had time to attack the problem, prototype two new solutions and create a small number of tests during the week. The first solution was able to test 40% of the code through 4 test cases in only 0.13 seconds. That is fast enough that we can run them on every commit or even on every build if we would like to. The second solution was an End-to-End test scenario. We could not have found this solution if we had been stuck in old ways of thinking because we had to change our test framework to achieve this. These tests takes a little bit longer but is still reasonable to run every night for example. It can also be re-used, with minimal effort, by any of the 22 game teams that are currently using the game framework that we are responsible for.

But the most important achievement of the week was not in the solutions we found but in what it had done for the team. They owned the problem, the week and, by the end of it, the demo. They were able to demo their results to the rest of the company which immediately caught on with lots of questions and affirmation of how this would benefit them as well. We would never have had this great result had we not left the SMART goals behind during this week.