Build Projects around Motivated Inviduals

If you didn’t know, in addition to the 4 values of the agile manifesto, there are also 12 principles behind the agile manifesto.  I myself think the 12 principles are much more useful than the 4 values and am disappointed that the values get much more press.  One of the things we have done at our monthly AgileIndy meetings is to spend 10-15 minutes at the start of each meeting focused on one of these principles.  We get a volunteer from the group each month to lead the discussion.  It gets more members from the group involved in the meeting and gets everyone exposed to the 12 agile principles.  It has been working very well (with the exception of the awkward silence we endure waiting for someone to volunteer to speak the next month) and we have received great feedback on it as well.  To continue this, I thought I would start to post a summary of some of these discussions and some additional thoughts of my own each month.  So hear goes…

This month, one of our members lead a discussion on the 5th agile principle:

Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.

First, I think the wording of that first sentence is very important.  It says to build projects around motivated individuals.  Notice it doesn’t say motivate your team.  You need to accept the fact that you can’t motivate people, but you can select motivated people.  Of course, the real trick is to ensure you aren’t demotivating your team!  That’s really what the second sentence is about.

So if we accept the fact that we can’t motivate people, one of the next questions we need to consider is what does motivate people.

Start with Why

I’m a big fan of Simon Sinek and his book Start with Why.  He has a TED Talk that summarizes his thoughts well.  If you haven’t seen it, I’d encourage you to go watch it now.

Simon is talking a lot in here about customers and buying your products, but this applies to your employees too.  Employees that share the same WHY as your company are going to be motivated.  They can see what you are about–why you exist–not just what product you are building.  They are going to go the extra mile to help your customers and will feel great satisfaction helping you meet your goals.  I get annoyed anytime I hear a company say they are a “software company”.  Any company that describes themselves as a software company doesn’t have this down yet.  You don’t build software for the sake of building software…at least I hope you don’t.  Every employee in your company should know your WHY and when asked what their company does, they should reply with that, not list the products that you sell.

I think agile does a great job of helping companies focus on the why.  In my opinion, the most important part of a user story is the why.  In the standard format, this is the last part of the story…

As a …
I want …
So that …

This is something that is almost always ignored in other forms of requirements.  I see lots of teams leave off this part of the user story as well.  I personally like moving it to the front of the user story so that it becomes the focal point and it should really be what we always start with.  If we can’t put something good in that spot…if we don’t know what value this story is delivering to the customer…why are we doing it?


Another great source of information on motivation is Dan Pink’s book Drive.  Like Simon, Dan has a good TED Talk out there as well as an animated sketch that provide good summaries of the information in his book.  Again, if you haven’t seen them yet, I highly suggest taking the time to go watch them.

Dan talks about the scientific studies that have been done that show that external motivators (stick and carrot style, money) actually have the opposite affect rather than the desired one when we are talking about creative or thought work.  External motivators can provide great focus, but when a job requires creativity and out of the box thinking, that focus actually hinders progress and slows us down.  We get focused on the trees and lose sight of the forest.

Dan tells us that the three things that really lead to better performance and satisfaction are autonomy, mastery, and purpose.  Purpose really gets back to the same thing Simon Sinek was talking about.  Why are are doing something…what’s the greater good we are working toward?  If employees can see that and understand it, they will have a better sense of purpose and thus be more motivated.  Autonomy gets back to the trust part of the principle.  Do they have the power to get their job done…to achieve their purpose.  Mastery is all about continuous improvement and always getting better at your craft.

So What

So what does all this really tell us?  We can’t motivate people, but we can demotivate them.  The first step is to find motivated people.  To find motivated people we have to first know why we are doing something (this story, this project, etc).  Then we need to find people that can relate to that WHY, that share the same purpose…those are motivated people.  After that…we need to get out of their way and trust them.  We need to make sure we aren’t demotivating them through incentive plans that dangle carrots in front of their faces or by taking away their autonomy and not letting them determine the best way to solve the problem.  We need to ensure we give them the time and resources to continuously improve their skills and knowledge.  That is how we build a truly great team and a truly great company.


Comments on this entry are closed.

  • I know I am way late to the party on this post, but I am really moving towards Open Allocation as the right answer. It will be really hard to do, but if it is done well, I believe it can propel a company above their competition…

    • I have to agree! In fact, I was just discussing that with other coaches at the Agile Coach Camp in Atlanta last weekend. I have actually been meaning to write a post on that recently, especially after watching the Dan Mezick interview ( from a recent conference. He points out to be successful, an agile transformation really needs to be opt-in, not mandated, and he references using Open Space to facilitate such a transformation.

      My thoughts are around structuring it like a start-up pitch session that you see at incubators. Treat each “project” the business wants to do as it’s own startup (after all, it seems start-ups generally have the most motivated teams…so why not try to replicate it). Get all the R&D organization in a big conference room (dev, test, ops, etc) and, starting with the highest priority project, have the Product Owner get up and pitch the idea and ask for volunteers to help. There are probably some ground rules you would need (or maybe not) and some potential outcomes you should consider how you might handle if they occur, but this is a really appealing idea to me. Some of those ground rules and potential outcomes (and limited time to write) have been keeping me from completing the post, but hopefully I will get to it soon!

      I know one of the other attendees in Atlanta mentioned he had used Jurgen Appelo’s Meddlers game ( to do this at a small scale on a team, so I was wanting to look into that. Have you actually tried this yet or how are you envisioning it would go?

%d bloggers like this: