Agile, People, Software Development, Team

Three rules to make Stretch goals work

Many times late in projects we frequently see the use of stretch goals to instill a sense of urgency and motivate the team. But do they truly work? Many times stretch goals are applied in a manner that can actually cause them to be de-motivating rather than motivating.

In my experience, there are three rules that need to be followed to make stretch goals work:

1) Collaborative Goals – The goals need to be collaborative. There is nothing more de-motivating than someone else making a stretch goal for you with out your input and consent. These goals will end up being ignored as the team members are not engaged on the stretch goals.

2) Realistic Goals – The goals also need to be realistic. If the goals are not merely stretch goals but also impossible goals, the team members will lose their motivation to try to reach them. Impossible goals will have the opposite effect. Instead of people putting more effort in, they will put even less effort in as they are doomed to failure.

3) Empathetic Goals– This is perhaps the most important rule. Even if the stretch goal has been set collaboratively and is realistic, there is still one more factor. Team members need to understand why they should care about the goal. I read a fascinating book called ‘Leading Geeks’ that proposed that geeks and other professionals can’t be just told what to do. They need to be reasoned with and convinced that the goal is appropriate and worthy of their care.

Summary

Can Stretch goals work? They certainly can if they follow these three rules.

But I find what usually happens is that there is an issue following one or more of these three rules. Either there is a hesitancy to be collaborative or the goal may not be realistic. Even more, there may be a challenge convincing the team as to what the reason is for the goal. In those cases, the stretch goals will probably be more de-motivating that motivating.

I understand there are reasons for stretch goals being demanded of projects teams and sometimes they can’t be modified or rejected.

But you also should know they probably aren’t going to work.

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: