Setting goals

Something you already know

Some people set goals for everything in life. They set goals for what they want to accomplish that day, week or year. It makes sense that they do, as a lot has been written about the positive effects of settings goals (see: A Psychological Success Cycle And Goal Setting, Making things happen through challenging goals: Leader proactivity, trust, and business-unit performance, and many others).

Although some may not be great goal setters in their personal life, the majority of people generally agree that setting goals in business (or sports) makes sense. In the software development industry, we are accustomed to setting goals for sprints, releases or milestones. We do this to motivate development teams and to increase commitment to achieve the objectives that are set.

Admittedly, the project I'm currently working on has not been a prime example of great goal setting. During the sprint planning meetings, our team discusses what they're going to accomplish and why that's such a good thing. This could be improved by linking sprint goals directly to long term business goals. And that brings me to the point I'm trying to make.

Why create software?

It might not be a question most software developers ask themselves every day, but it's a valid one nonetheless: why create software in the first place? I bet that the answer is something along the lines of delivering a product or service to the end-user, creating new (business) insights, or streamlining processes. This makes software a means to an end, and not the end goal itself. This is probably something you already know (perhaps deep down).

With this in mind, it is only logical to conclude that to truly measure progress, we need to articulate and visualize (more on that later) business goals. That is not to say that sprint goals are useless, but they are also a means to an end. It may require several sprints to reach a certain business goal.

How we do it

To illustrate my point, I will describe this process with an example. Let's say you're creating a new system that allows people to rank how much they enjoy the beer they're drinking (Pro tip: use https://untappd.com/).

We start a project by reiterating the end goal to all team members. Following this, we identify several sub-goals in our project. In the example this could be: letting users log-in, letting users search for beers etc. The key is to set goals that actually are of value to the business. A system in which users only log-in doesn't have any business value.

A better goal would be to be able to display a single beer and give it a ranking. While the business value is very low, there's still some value.

Every team room is equipped with a monitor that displays a dashboard. This shows the current business sub-goal that we're working towards and the various steps in between. Whenever a step is completed, the dashboard changes and we move closer to reaching our end goal. In our experience, this visualisation gives the team a feeling of accomplishment and it reinforces why we're creating software in the first place.