Whether you do Kanban, Scrum, 6-Sigma, Lean, waterfall or any one of the methods defined brilliantly here, there is one fatal flaw that can ruin everything hiddenly, while all your metrics showing everything great.

This “little” thing is, goal setting

What is Goal Setting ?

In short, goal setting is defining strategic targets and developing plans to reach that goal. Even though this is considered a management topic, it is valuable to be familiar since it enables one to understand the steering and alignment in a company.

It is very much an ongoing journey for me to read about this subject. However I found following two methods especially good to know about:

• Hoshin Kanri Because, it is practiced by many immensely successful companies for long terms, most notably Toyota. (Toyota recoded loss only in 2008 global crises in 70 years without giving up no-layoff policy)

• OKR - Objectives and Key Results Because it is invented in Intel and used in Google which both operate in very fast evolving industries that might require different approaches in goal setting.

Typically, there are few top level strategic goals to be reached before due dates. Those strategic goals are translated to more explicit goals as they are propagated downwards in the hierarchy. (hopefully via mutual agreement and discussions, not by shoving it down)

Eventually, organizations are supposed come up with plans that do not undermine each other to support the movement towards goals.

The focus here will be setting goals on development teams. As an engineer, I will focus on Gemba, where the actual value for the customer is created.

Why Do You Need to Set Goals ?

As you change your product or how you do your work, you are moving the company towards a direction.

How can you tell whether you are doing the right thing if you don’t know where you are supposed to be heading for ?

This is easy to answer in a small company with a few employees and a couple of products. It is difficult to answer if you have hundreds, or thousands of engineers, just as much projects, budgets, locations, customers etc.

Goals define top level targets that you should be putting effort while developing your product. If you define them good, you will have better chance of success. If they are bad, you may not notice it until it is too late.

Characteristics of Goals

Goals need to have certain qualities in order to be useful. SMART is a commonly used acronym for defining criteria for good goals.

1. Goals need to addres specific area (eg: OPEX) otherwise vague areas create confusion that leads to failure
2. Goals need to be measurable (eg: decrease OPEX by X%) otherwise you can not verify your progress
3. Goals need to be assignable (eg: devops team) otherwise noone owns the goal
4. Goals need to be realistic (eg: decrease OPEX by 5%, not 50%) otherwise motivation drops to 0
5. Goals need to be time bound (eg: decrease OPEX by 5% in quarter) otherwise it is never reached

The other important aspect of a goal is, it implies financial effect on assignees. (eg: bonuses, career opportunities, extra benefits, more head counts etc …) There must be a tangible, predefined incentive to reach goals.

In some companies, such incentives are transparent. In my experience, that results in more honest and fair working environment. When intensives become a secret, it is almost always due to unfairness.

Note that, SMART does not tell anything about the meaning of the goal. Even if you have perfect SMART goal, it can still fail due to many reasons. Such as goal being wrong itself, not having qualified employees to execute it, problems in company culture, financial difficulties, communication problems etc ..

How Do You Set a Goal ?

Goals are not set in an email saying “come on! let’s do this and that!”.

Goals are negotiated, mutually agreed, recorded and announced explicitly. Their progress is tracked and then used to evaluate performance.

Without a direction, team will drift like a log in the ocean.

Without mutual agreement, the work environment stops being collaborative and becomes a feudal place where bunch of few nobles dictating to their serfs.

Without recording and announcement, trust between parties will not be established.

Even after doing all those right, you can still set wrong goals (mistakes in strategy) or set the goals wrong (mistakes in definition of the strategy)

What is The Difference Between a Good and Bad Goal ?

Good goals actually help aligning your business goals and how you work, whereas bad goals create the illusion of this.

This is quite dangerous because it makes you think that everything is proceeding according to the plan.

Why Do Bad Goals Create This Illusion ?

There is one rule that works pretty much everywhere: You get what you measure

What ever you define as a target, people will work hard to make sure that it is met. This is what you want, right ? You point your finger, and everybody follows.

Meanwhile, anything else will be much less important when compared to the things that are targeted. Everything will be done in order to reach goals.

This is where it can go very wrong.

Examples of Tricky Goals

Most bad goals are simply caused by not thinking thoroughly about all aspects and results of following that goal. Let’s go over a few with software engineering perspective.

Release Date as Goal

Some organizations want to make sure that releases always happen on the planned date. This is typically measured by bringing together the planned release dates and actual release dates. If you do not cross the planned date, you achieve the goal. Congratulations!

However, this goal also tells people that making the release before the target date is more important than everything else. People will descope features -no matter how important they are-, or delay bug fixes if they jeopardize the release date.

Unless you put extra criteria about what makes a software ready to release, you will always meet this goal. You will end up software that is always released on time, but hiddenly containing critical bugs or missing important features because you decided to put so much weight on the release date.

Number of More Bugs Found as Goal

Another pattern is to set a goal on the number of bugs found. This can typically happen if there are different teams for testing and development.

The idea is to reward the team to find more bugs, so that a less defective product can be reached.

However, if you check only the bugs that are found, people will be very creative to invent bugs tickets. Note the difference between “inventing bug tickets” and “bugs” here.

Most of them will end up closed as “works as designed” or “not applicable”, wasting people’s time on analyzing them. Some of them will imply feature requests under the mask of a bug.

If you go on this path, you should calculate only the bugs that are resolved by a code change and you must make a clear definition of what a bug is, together with what tangible criterias make a bug prioritized.

You can also calculate the ratio of bug reports that receive code change vs the ones that are closed without code change, to see if the system is abused. Every raised bug causes the development team to engage with it. This is extremely cost if you have many bug reports that are wrong.

Number of Less Bugs Found as Goal

Bug statistics are very attractive to set goals. One of them is to set targets on the bugs found in the system in a way that less is rewarded more. The intention here is to motivate teams to create higher quality products that have less bugs.

This one also has a weak point. Just like people becoming more creative to invent bugs when more is rewarded, they will end up hiding bugs if less is awarded.

How does this happen ? When numbers have to be minimum, people will start changing bugs to stories or tasks by changing their content slightly to fit another type. Also, they will negotiate with reporters to not to submit now or submit as different type. Developers will start taking note of the bugs they found -instead of reporting it- and fixing them under the umbrella of ‘refactoring during story implementation’.

Speed of Bug Fixes

This type of goal focuses on how fast bugs are fixed. It is not wrong to assume that fixing things faster is good. However, you need to define what makes a bug fixed ? If you only care for the ticket status, you can be sure that it will be closed very fast. For example, a bug fix that does not have test case for verification is usually fishy.

Number of Story Points Implemented (Or Higher Velocity Reached)

The purpose of this approach is to encourage adding features which would be very welcome by business people as well. As all short sighted targets, this has potentially devastating side-effects. Let’s define some:

• During estimation sessions, people will try to set slightly higher numbers for some stories.
• Since the number of total story points become the focus, bug fixing will have much less importance.
• Since the goal only cares about points, the nature of stories will not be that important.
• Stories will contain less acceptance criterias since more criteria usually means longer cycle time and rewards are given for the signed-off stories.

Moreover, story points alone do not necessarily mean that you implement right things. It will be useless if you finish crazy amount of stories that nobody actually use.

Remember that, every new feature increase complexity of your software.

Goals Based on Result of Static Code Analyzers

This approach assumes that the static code analyzer results must be minimized so that better quality can be achieved.

When rewards are given based on this, people will end up spending their time on making code changes that practically add no value to the customer, considering that static code analyzers can return great amount of false positives depending on the language if you do not configure them properly.

Goals Based on Code Reviews

Mandatory and proper code reviews is a pillar for quality software. However, if people’s performance is measured based on tickets they resolve, they will abstain themselves from contributing to code reviews, saying that they are too busy (i.e: they are expected to close tickets, not do reviews). This usually ends up few people doing most of the reviews while the rest simply checking in code and don’t look at reviews unless they receive a comment for their own code.

To make code reviews a priority, sometimes it becomes a goal to met such as engineers has to do certain percentage of reviews etc. However how do you measure this ? If you measure the performance by checking for the votes given, you will end up people casually giving +1. (They will not give -1 or -2 because in that case they actually have to make a comment)

A tool like gerritstats may provide useful statistics if you use Gerrit.

Are All Those Individual Unethical Behaviours ?

You may argue that people behaving like my examples are unethical people. In fact, they are only following the goals given to them and when they reach it, you have to give the credit. They do what everybody would do under the same circumstances.

Everybody is managed by the goals given upon them. They are simply returning what you asked.

Leaders’ responsibility is not just setting correct goals but also setting the goals correctly.

Journey Towards Better Goals

There will never be a magic list of team targets that will be applicable to every software team. But there are few useful tips that can be followed in order to support better, working goals.

1. Explicitly define conditions that categorize a request to be a epic, story, bug or task This prevents creation of bugs tickets that hiddenly change features or tasks that hiddenly fix bugs.

2. Explicitly define conditions that change prioritization of requests This prevents people from arbitrarily prioritize requests.

3. Explicity define your SLAs and set goals to meet them. This helps maintaining a certain level of customer satisfaction via quality support.

4. Define exit criteria together with release goals Especially bind quality related goals as gatekeeper for release goals. This will prevent slipping out low quality products just to make the date.

5. Define goals that reflect customer feedback and experience A small bug reported by your customers is usually worse than a bigger bug you discovered internally. You can give specific weight to bugs reported by your customers.

6. Define goals that target efficiency and waste elimination It is never too early to do Kaizen, but it might be too late if the ship is sinking.

7. Explicitly define what is required for a code change to be considered as completed (Definition of Done) Do not leave shortcuts that allow dirty, sneaky code changes.

Conclusion

Many software teams define some goals to push themselves to a better state. When those goals are not well thought, teams often see themselves reaching goals but unable to produce fruitful results or continously conceding goals from different fronts.

When the goals seem right but not really taking you anywhere, it might caused by how those goals are defined and measured.

Therefore it is extremely important to avoid being careless while defining targets and do a meticulous work that will clearly define priorities without gaps.