Linking Agile to HR Theory
To many people, agile is the opposite of sound
theory. Instead of proceeding in a structured, well-planned manner, teams “self
organize” and iterate through prototypes to try and create something. Ants can
self organize and create transportation systems and large, complex community
structures. Yet when people self-organize, we tend to get slum ghettos with no
sanitation. Which outcome do your projects most resemble?
Planning is a slow, boring, unpopular exercise that
attributes accountability to the planning group; if something goes wrong, we
know who to blame. If everyone has a go at creating something and it does not
turn out, then the blame is harder to pin on someone; excuses can be made
around the project being complex and requirements not clearly articulated, etc.
So, is it laziness and dodging accountability that
drives the huge growth of agile approaches, or is there something else to it?
The Standish Group, which studies software project failure and success rates,
process is the universal remedy for software development project failure.
Software applications developed through the agile process have three times the
success rate of the traditional waterfall method and a much lower percentage of
time and cost overruns.”
They sound pretty impressed, so what’s behind it?
It turns out there’s plenty, but in the human resources domain, not the project
execution domain. Projects are undertaken by people for people; they involve
getting people to work together on things, collaborate, create consensus and
sometimes compromise. As such, it is only right that the real key to project
success should come from “people science” rather than “scheduling science”.
Don’t get me wrong: work breakdown structures, Gantt charts and network diagrams
have their place, but they are not the right place to start your journey for
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 :
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.
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
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
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.
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 , 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
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
“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 
- 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
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 , 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 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,
- 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
- 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.
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
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
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.
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
- The “CHAOS Manifesto” report, the Standish Group, 2012, Page 25
- McGregor, D. “The Human Side of Enterprise”, McGrawHill. (1960).
- Bruce Tuckman, “Developmental Sequences in Small Groups”
Psychological Bulletin 63 (1965):
- Patrick M. Lencioni, The Five Dysfunctions of a Team: A Leadership
Fable (San Francisco: Jossey-Bass, 2002)
- Daniel Pink “Drive: The Surprising Truth About What Motivates Us”
(This article first appeared on ProjectManagement.com here)