Why Trust Them?
The Agile Manifesto principles say that we should “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”and that “the best architectures, requirements and designs emerge from self-organizing teams.” Which all sounds well and good, but why be so trusting? How can we justify this?

Douglas McGregor popularized the “Theory X and Theory Y” approach to worker motivation in the 1960s [2]:

“Theory X asserts employees are inherently lazy and will avoid work if they can. Management believes that workers need to be closely supervised and comprehensive systems of controls developed.

Theory Y however, assumes employees are ambitious and self-motivated. They enjoy creative problem solving, but their talents are underused in most organizations. Managers should communicate openly with subordinates, minimizing the difference between superior-subordinate relationships, creating a comfortable environment in which subordinates can develop and use their abilities. This climate includes the sharing of decision-making so that subordinates have say in decisions that influence them. In other words, use empowered teams and, in the words of the Manifesto, ‘trust them to get the job done.’”

Given that today’s knowledge worker projects bring subject matter experts together to collaborate on problems that often have incomplete information and use new technologies, the project manager does not have all the answers. The PM does not possess the technical expertise and so depends on the team for help with estimation, planning and risk management. When we do not have all the answers, we have to trust the team to fill in the gaps.

So the team may have the key information, but what about them being a bunch of lazy slackers, padding their estimates for an easy life? Well, getting them in front of the business every couple of weeks (demonstrating what has been built so far and answering when the next features will be ready) certainly helps reduce this risk. Nobody likes demonstrating little progress, and when people see the impacts of their work on the business they develop stronger desires to perform than just meeting task-list deadlines. Empowering the team to troubleshoot capacity constraints also weeds out under-performers. Slackers and estimate padders don’t last long in an empowered team looking to improve their capacity week after week.

Today’s agile teams (and how we lead them) are very much the embodiment of Theory Y motivation. It is okay and desirable to trust teams and give them the tools to self-organize, self-assess and improve.

Co-Located Kumbaya
To the cynical, it could seem that agile teams want to be co-located so they just chat rather than have to write anything down that can be later used against them, play Planning Poker rather than develop proper estimates and debate technical options rather than getting on with some real work.

Yet knowledge worker teams are easier to develop if they are stable and co-located. It takes time for teams to progress through the Tuckman stages of forming, storming, norming and finally performing [3], so to optimize team output we should facilitate the process and keep teams stable. Swapping people in and out triggers the storming and norming phases again as these new team members find their places in the team dynamic and the team adjusts to them.

Part of the storming and norming process is learning how to deal with team conflict, gain commitment for decisions, and ultimately develop a sense of accountability for the project outcomes. These are complex issues that impact all projects where skilled people need to collaborate on building novel solutions. Getting SMEs to work together and harness constructive disagreement to rigorously test decisions is the goal of team development.

Co-location of team members helps this process and allows direct face-to-face communication. While co-location is not always possible, it should be a goal. And if given a choice of two resources--one experienced but remote, and one more junior but local--the local resource is often the best choice for the team.

They ask to be co-located and then just argue all the time!
“Empowered teams” sometimes appear as “enraged teams” as debates and conflicts frequently occur. The term “war rooms” seems apt to describe where team members criticize proposals and shoot down colleague’s designs with little mercy. Cubical farms may be sterile, but is it not more humane if the workers are at least calm and quiet?

Well, it turns out if your team is all quiet, you are either not working in a demanding domain or your team members are not committed to the project goal enough to fight for their designs. High performance requires accountability, commitment and conflict. The lack of these characteristics is a sign of project team sickness.

The challenges teams face in working together and learning to trust, thrash out issues, make decisions and commit to shared responsibility are well described in Patrick Lencioni’s The Five Dysfunctions of a Team [4]

• Absence of trust--Unwillingness to be vulnerable within the group; people must be open about mistakes and weaknesses to build a foundation of trust.
• Fear of Conflict--Teams that lack trust cannot engage in unfiltered debate; instead they resort to veiled discussions and guarded comments.
• Lack of commitment--Without passionate debate, team members rarely (if ever) buy in and commit to decisions, though they may feign agreement during meetings.
• Avoidance of Accountability--Due to the lack of commitment and buy-in, most people will hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team.
• Inattention to results--Failure to hold one another accountable lead to putting individual goals (or department goals) ahead of the project.

These dysfunctions are ever-present risks to knowledge worker teams. Project managers can help build a culture of trust by sharing their own mistakes with the team and demonstrating it is okay and desirable to be vulnerable and admit to mistakes. Saying “I made a mistake on the status report and will be resending it today” and “I forgot to add in regression testing to the estimates and will have to redo them” demonstrates the desired behaviour.

Co-location helps facilitate unfiltered debate; without the barriers of video conferencing, email and telephones it is much easier to really get to the heart of an issue when you are face to face with someone. The concepts of empowered teams and team decision-making help overcome lack of commitment issues. Teams vote on estimates using techniques like planning poker, building commitment for the outcome.

Daily standup meetings, sprint planning meetings and retrospectives reinforce and reiterate team member work commitments and team accountability for results. These agile practices have very real impacts on addressing the typical dysfunctions of a team and should be developed to mitigate performance risks.

Monosyllabilic or Motivated?
Why would team members rather instant message someone sitting 10 feet away rather than get up and go talk to them? Is this just a generic nerdy, lack of communication skills or something else?

Agile team members often get into deep, hyper-productive states called “flow”. Flow can be seen when someone is so absorbed in a task that they are in the zone. It describes the state of mind when time seems to disappear and we are just immersed in the task. This feeling of flow can be difficult to find when our work environment interrupts us unduly or places restrictive work processes that impinge the ability to create flow.

Giving teams control over their work (autonym)--when coupled with encouraging and preserving flow--goes a long way to improving motivation and productivity. Daniel Pink, author of Drive: The Surprising Truth About What Motivates Us [5], explains why traditional “if/then” carrot-and-stick type rewards do not work long term.

Pink states several MIT studies where adults and children were rewarded for conducting work, hobbies and play activities. Once the reward is removed, people stopped doing them--even if they had previously happily voluntarily done them before. Once tainted by if/then rewards, the motivation was sucked right out of it.

Pink asserts the current if/then extrinsic motivation corporations use is flawed and needs an upgrade. Hence the need and rise of a new form of motivation based on:

• Autonomy
• Mastery
• Purpose

Autonomy means giving people control over how they work, including:

• Task: the work, and how they undertake them
• Time: when they choose to work in the day, week, year
• Technique: how they perform tasks and from where
• Team: how they organize, interact and collaborate

Mastery comes from:

• Flow: Having the time, space and freedom to find and exercise your passion for a profession
• Goldilocks Tasks:Not too difficult and not too easy, but just right. We need enough Goldilocks tasks to stretch, engage and indulge our desire for completion and satisfaction.
• Mindset of learning: People who believe intelligence and knowledge is not a fixed capacity we are endowed with, but rather a muscle or skill we can grow. People who are happy to face their limitations and continually find new learning opportunities achieve mastery easier.

Purpose describes tapping into people’s belief that there should be more to work than just making money and being successful, aligning company goals with individual’s aspirations for doing good and meeting a higher guiding principle.

This is why companies like TOMS Shoes were created; it gives away a pair of shoes to poor countries for every pair sold. Buyers feel good since their purchase has a charitable impact and the workers at TOMS feel good since they are doing more than just generating shareholder value. Instead they are tapping into their motivation principle of a compelling purpose.

Motivation for Agile Teams
The good news is that agile teams are halfway there. The stepping stone to autonomy that empowered teams have is a huge leg up on those people caught in command-and-control hierarchies.

Agile teams already have good autonomy over task, technique and some aspects of team. Time, the remaining component of autonomy, is seeing some progress, too. Kanban approaches that are being adopted by agile teams have a more pragmatic view to iteration structures and scheduled meetings. If these time structures add value, then fine go ahead and use them; if they do not, then try without them using more of a pull model of task selection and work scheduling. Not only does this remove delays and eliminate waste, but it also affords the team more autonomy over their time.

Some agile organizations go further and allow 20 percent time (or 10 percemt time) for pursuing new ideas and experiencing the joy of flow, being in the groove doing work you love. These one-day-a-week (or half-day-a-week) opportunities for self-directed work provide more autonomy, an opportunity to experience work mastery and pursue a goal with a purpose, perhaps for a good cause.

Summary
Agile methods can appear unstructured, poorly planned endeavours when viewed through a traditional lens of project scheduling and execution. However, when stepping back and recognizing the people side of projects, we see the embodiment of many established good principles. Projects rarely fail because the technology does not work; projects usually fail because of people issues. Finding ways to improve the people side of projects, even if they appear counter intuitive, pays huge dividends.

The Standish claim that “the agile process is the universal remedy for software development project failurr” is going too far; there is no silver bullet, but agile approaches are definitely a useful place to start improving your project performance because of how they engage the team.

References:

1. The “CHAOS Manifesto” report, the Standish Group, 2012, Page 25
2. McGregor, D. “The Human Side of Enterprise”, McGrawHill. (1960).
3. Bruce Tuckman, “Developmental Sequences in Small Groups” Psychological Bulletin 63 (1965):
4. Patrick M. Lencioni, The Five Dysfunctions of a Team: A Leadership Fable (San Francisco: Jossey-Bass, 2002)
5. Daniel Pink “Drive: The Surprising Truth About What Motivates Us” 2011

(This article first appeared on ProjectManagement.com here)