Agile Drive - What Motivates Agile Teams?

Every since I watched this cool video for Dan Pinks book Drive, I have kept his message front of mind. According to Dan and contrary to what many believe, motivation is composed of 3 simple things: purpose, autonomy and mastery.  Initially I found this hard to believe but the more I look at this the more motivated I become.

So turning to Agile teams, how does this relate?

Purpose
Agile creates a great sense of purpose.  Sprints or iterations create a tangible sort term goal that helps the whole team focus together.  The best teams I have worked with all establish and agree a clear sprint goal, in terms of value to the user and perhaps technical improvement.
Stand-ups frame each day, establishing work completed and work planned - focusing the mind for the day to come.  Blockers are those issues that stand in the way of the team purpose.
User Stories express software in terms of the goals and actions of a user - the purpose the user will be able to achieve when the story is complete.  Moving these to Done moves the user closer to their purpose and connects us to the value of our work.

Autonomy
The key element of autonomy in Agile is the ability for team members to pull new work to themselves. We drop task assignment in favor of this.  The are many reason why but apart from autonomy, I will leave them to another post. When we are free to choose our own work from the board, we have a different relationship to the work. The opportunity to choose goes along way - even if only dud work remains.  Modern societies are founded on the freedom to choose.  Why then would we drop this in the work place? (answer: Frederick Winslow Taylor and another post).  If you are finding motivation to be low, this is a great place to start looking for answers.  Why in our modern, democratic society do we think it's right to tell people what to work on? Rather than ask them to pick from the list of available, prioritized tasks?

Mastery
Agile is built on this.  We focus on developing expert skills in project delivery, then generalize this across the whole delivery life cycle.  Generalizing specialists.  It's key to be able to fulfill a role well before moving on.   In the mad dash that has been the growth of this IT industry, I think this has been forgotten.  There is so much focus on moving into management roles that people forget about mastering a skill.

I think a large part of the growing popularity of Agile is because these three factors are baked into a well functioning team.  The first thing I do now, when asked to help a team, is look at these.  Of course we talk about practices and principle but what I am really looking for is:

Do they have purpose?
Are they mastering their skills (or trying to escape their role)?
Are they free to choose their own work?

After that it's the Agile Principles and finally, if there's any time left, we look at practices.

What if a Product Owner is Out of Control?

In the last couple of years, I have experienced a few "out of control product owners". What I mean by this is: Product Owners that are not representing the business, the project stakeholders or product users/consumers. They have no constituents. Strictly I mean product owners that have their own opinions on what should be built and they concede to no-one.

Perhaps this is something to be celebrated? A Product Vision and Owner so strong that they can move forward in spite of all opposition. Maybe this is what's needed to get a product to market in some organisations?  We often hear how design by committee can kill a great product idea. Surely more "out of control product owners" would help? Would be a Good Thing?

I don't think so.

Scrum, with it's singular focus on the role of Product Owner, leaves it soft underbelly exposed to the tyranny of megalomaniacs.  Teams are trained to bow unconditionally to the wishes of the Product Owner.  For some teams this becomes absolute and common sense is parked at the door.  Anything to satisfy the needs of the Product Owner demigod.  Anything to buy another two weeks of peace and security....

So what to do?

Agile will always be about Customers, Users and Business Value.  Business Value is something that a customer is willing to pay for - a proxy for profit.  If we focus on what people will actually pay for we can't go far wrong as a business.  If you're not a business, or profit is not part of your equation, then ask The Users what do they actually want today?  Either way Ask The Users

A Customer In approach is the only way to evaluate what customers and users really want, or will pay for (*).  A great product owner will embrace this collection of data.  This capturing of user needs.  An evaluation of market forces.  A relation to revenue and profit.  A tyrant will fight this at every turn. Because the data will undermine opinion.  The only way to level the field is to capture data on the needs of the customer. Without this it's a matter of opinion.


(*) Unless you're like Apple. So far in from of the market that 'bleeding edge' looks like last years top gaming PC, then you are in a different place.  Most product development wishes it was there, but is not.  Apple is creating new markets.  Not products.

The Best Retrospectives Engage Our brains in the Right Way

Organisational Change can be very challenging.  70% of initiates fail according to Dever Powell as he looks at David Rocks SCARF model for Orgisational Change Management.  Keeping people in a 'Forward State' is the key.  Simply put, this means avoiding triggering Fight or Flight.  This allows people the time and space for their own insights.

http://nihrecord.od.nih.gov/newsletters/2013/03_01_2013/story3.htm

A carefully run Agile Retrospective can keep people in a 'Forward', creative space.  The key to this is Norman Kerth's Prime Directive:  

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." 

http://www.retrospectives.com/pages/retroPrimeDirective.html

By removing blame from the equation we have a much better chance of keep people in a positive, action-oriented frame of mind.  We avoid these 'Away', or fight or flight states of mind.  This allows the full creativity of the brain to be used for problem solving.  With this creativity we can solve problems in a very different way.

My recommendation is to always use the Prime Directive at every turn.  I always read it out at the start of a retrospective, and re-read it if blame or conflict arises.

Is there a Road Map for Agile Transformation?

I often get asked about the best way to implement Agile Transformation.  Generally speaking this will depend a lot on where you are now and where you want to get to.  It would be overly simplistic to say there is a One Size Fits all approach. There is however a set of activities or steps, that when linked together can form a map of sorts.

Agile Transformation is not a liner process but one of reflection, adaptation and making small changes.  Over time these tiny steps become giant leaps of transformation.  The giant leaps that get noticed.  From the outside this might appear like a some magical formula to make sweeping changes but in reality, every lasting change is composed of a series of tiny steps.  Each step is self-motivated by individual and groups that want to make their working world a little better.  A better work environment means better outcomes for the customer and great satisfaction and engagement for the teams.

In a series of posts to follow, I will attempt to outline my experiences with this. I will suggest a set of steps that could be followed, should you wish to do so.

Agile and the freedom to choose

Nice article here http://www.infoq.com/articles/managers-support-agile-transformation about how Agile can benefit the wider organisation.

One of the major benefits of Agile is that it increases engagement. It does this it two ways. Firstly it moves control out of the hands of the few and into the hands of the whole team.  This allows the whole team to engage with the importance of a goal.

Secondly, it supports people to choose their own work.  By doing this we create freedom of choice.  This creates high motivation and engagement.  Of course if  'being a yoga teacher' is the only card on the wall that you want to pick, then obvious questions about taking a role of a Java developer on a delivery project spring to mind.  We don't just park common sense at the door with this - but the freedom to chose goes a really long way.

I'll expand on both of these topics - Control and Choice - in subsequent posts.