Picture of Stephan van Rooden

Stephan van Rooden

Groups & Scrum: Setting goals


“To win, you’re dependent on others. To improve, you depend on yourself!”

Last week, I had a very interesting session with some fellow coaches on how to assess an organizational department who has started the transition to Agile a few months back. From that moment we started measuring some boundary conditions. Those things you really need to have in place to enable a faster adoption of Scrum and preparing the path towards agility.

The Dashboard 1.0

We decided to make a ‘dashboard’ where these boundary conditions were to be assessed on a monthly basis. Also we thought it would help to make this transparent to everybody in the organization. However, this resulted in some undesired ‘gaming’ of the results. All of a sudden the boundary conditions were being met. This was strange because in reality hardly anything had changed other than the dashboard with several colors had been made transparent. This also resulted in another unanticipated side-effect.

All of a sudden we got management attention! But not the good kind, instead of going to the teams and asking them how they could help them to become better, management attention focused on us, coaches. Who are we to make this transparent (on large TV-screens through the building) without notifying them? Well, yes, we made a mistake there. We assumed that management knew what was going on IN THEIR OWN TEAMS!

So this dashboard not triggering the correct behavior we gathered to think of something else. And then it hit me, the answer that has been there all along and how I have been living for years! Measuring the improvements of a team and assessing their ability to win is similar to how I used to plan my sports season. Below I hope to provide some insight for managers struggling with setting goals or KPI’s for this year in a new Agile organization (or in transition).

The best of the country!

I have been a (semi-professional) swimmer for about 15 years. In the last few years, I trained eight times a week in the swimming pool, three times a week you could find me in the gym. A lot of work for trying to become a tenth- or a thousandth-of-a-second faster. When I just started swimming my personal bests improved not by milliseconds but by seconds. As I became better the improvements were less big but the impact of these smaller improvements were a lot higher (so were the stakes).

So when you are a professional athlete, you can only peak twice in one season, three times at most if you are lucky. The rest of the season you are working very very hard towards this peak! This requires some clear goals and a plan. So every season I would sit down with my coach and discuss the plan for the upcoming season. By looking back at last season and taking my long term goal into consideration I drafted the goals for the upcoming season. The way I did this was by splitting my goals in two. Result goals and process goals.

Goal setting

Obviously, I wanted to be the best. So most of my goals during the season focused on being the best on the 100 meter individual medley (for example). And I assumed based on historic data that a time of 55 seconds flat should be enough to win.

Great goals, very ambitious but these goals are result goals. In achieving these goals I am depending on others and on the things I do while swimming. So having such goals alone would limit measuring progress towards this goal until the moment I would be swimming at the national championships. I couldn’t swim 55 seconds flat every week because I can only peak twice a year.

So in order to measure my progress during the season, I identified process goals. Goals which I could influence myself and would result in achieving my result goals. For example, I need to learn a different turning technique to become faster and I need to be able to do butterfly kicks for 15 meters below the surface for the butterfly and backstroke part of the race.

These goals I can train myself in and every match I can measure if I am getting closer to one of my result goals (55 seconds flat) or that I needed to focus on different goals.

So, I hope you see the point here. I can set goals that are aiming towards a certain result, but in achieving these goals I need to work on the process to get to those goals.

Dashboard 2.0

So after telling my fellow coaches this story we knew we were onto something here. Because, for teams and organizations the same things apply. You can measure results but by achieving these results you are depending on different factors. The key is to identify this practices or techniques to apply in order to positively influence the result. For agile teams, we came up with a dashboard like the one below:

Team 1

Team 2

Team 3

Team etc.

Reliability of service





Customer happiness (1-5)





Predictability (planned vs done)





Lowers results (# of teams)

Contributes to results (# of teams)

Automated regression testing (4)

Stable teams (2)

Stable Team (2)

Continuous integration (2)

Pair programming (1)

Scrum of Scrums (1)


For several teams we measured the same results (reliability of service, (customer) happiness, etc.) but we also assess which (agile) practices influence the results both positive and negative. This gives input for managers to see if they need to facilitate teams in – for example – setting up automated regression testing. Also, by identifying practices which contribute to these results, we enable teams to promote collaboration between teams to share proven practices.

So, you may have frowned when you read the quote at the start of this blog:

“To win, you’re dependent on others. To improve, you depend on yourself!”

You can focus on being the best, but therefore you are depending on others. To become better, you can focus on things that are within your own reach. And like Peter replied to in his Tweet, in today’s world you need some awesome teammates to help you become better!

This is the fifth post in the series on groups and scrum.

More to explore

Dagelijkse voortgang

De daily scrum bestaat uit het developer team zelf, eventueel aangevuld met de scrum master, product owner en andere geïnteresseerden. Even wat