Agile Teamwork:

The Leadership -
Self-management
Dilemma
Self-managed teams are unstable and
are successful when the Leadership
Self-Management dilemma is
understood and dealt with.
Page 7
Designing
Collaborative Spaces
for Productivity
This article shares the collected
wisdom of dozens of teams who
created their own work spaces, as
collected by several experienced
Agile coaches.
Page 12
IBMs Elizabeth
Woodward on
Distributed Team
Collaboration
In this interview, Elizabeth
Woodward talks about overcoming
the collaboration problems that arise
in distributed team development.
Page 17
Collaborative Leadership and
Collaborative Management
In this article, we propose a leadership and management framework that fts well with the current
need for innovation and distributed decision-making.
Page 3
TEAM
COLLABORATION
Team Collaboration eMag / Issue 4 - October 2013
by
Page 2
Contents
Collaborative Leadership and
Collaborative Management Page 3
In this article, we propose a leadership and management framework that fts well with the current
need for innovation and distributed decision-making.
Agile Teamwork: The Leadership -
Self-management Dilemma Page 7
Self-managed teams are unstable and are successful when the Leadership Self-Management
dilemma is understood and dealt with.
Designing Collaborative Spaces for Productivity Page 12
This article shares the collected wisdom of dozens of teams who created their own work spaces, as
collected by several experienced Agile coaches.
IBMs Elizabeth Woodward on
Distributed Team Collaboration Page 17
In this interview, Elizabeth Woodward talks about overcoming the collaboration problems that arise in
distributed team development. She also discusses using Scrum in distributed teams.
Jean Tabaka About Team Collaboration
and RAPID Management Page 22
Jean Tabaka talks about team collaboration as a key ingredient of the Agile development, but she
also mentions RAPID management as a solution for the product owners in an Agile environment.
Linda Rising: Prejudices Can Alter Team Work Page 27
Linda Rising shows how prejudices can affect the relationships between team members.
Contents
Page 3
Contents
Team Collaboration eMag / Issue 4 - October 2013
A new framework for leadership and management
has started to reposition the role of a leader in
todays dynamic environments. Does traditional
management provide value in a market that requires
agility and adaptability?
As a starting point, lets consider Chriss recent
experience:
I have always avoided the leadership space
because Im not convinced we need leaders. A
recent discussion with Sue McKinney and Pollyanna
Pixton helped me realize that my problem is with
leaders and not with leadership; similarly, managers
not management. My problem with managers and
leaders is that everyone talks about them making
decisions. This is something Im uncomfortable
with because they do not necessarily have the best
knowledge or information to make those decisions.
Realizing that leadership and management were
things that everyone in the organization should be
engaged in was the real breakthrough for me.
Using this experience, we propose a framework
in which everyone is responsible for different
leadership and management responsibilities,
different depending on their role in the organization
but responsible for leading and managing in their
spheres of infuence.
How Do Leadership and
Management Differ?
At the higher levels in an organization, leadership
shows the path, presents the options for direction,
and defnes the boundaries for the decisions that
teams will make in the various spheres of infuence.
Recent work from Dachner Keltner at the University
of California, Berkeley, cites research showing
that power leads people to process information in
shallower ways and to make decisions that are less
carefully reasoned [BusinessWeek, Business@
Work: Toxic Bosses, August 14, 2008]. Effective
leaders push decision-making to the edges of the
organization where there the available information
is more relevant, available, and real-time. Such
leaders focus their attention on defning the
what that their teams are to deliver rather than
controlling or defning the how.
Management is the guardian of the process. All
organizations need agreed processes to help them
function effciently and effectively. Management
facilitates the creation of the agreed processes and
then acts as guardian to ensure that they are not
broken, either by a change of context or gaming
by those operating the processes. In this role,
management does not make process decisions but
facilitates the creation of the process and then
identifes when the process needs an upgraded. One
Collaborative Leadership and
Collaborative Management
Written by Chris Matts, Pollyanna Pixton and Niel Nickolaisen
Page 4
Contents
of the primary roles of management is to avoid failure
of the system - in other words, risk management.
Given these roles, how do leadership and
management combine to create a culture that
unleashes talent and innovation? In our proposed
model, leadership defnes the vision for what needs to
be delivered and management ensures the capabilities
to deliver.
For example, let us consider a critical software-
development project. Leadership considers the
organizations needs and establishes the results the
project should achieve. As the project team decides
how it will organize and operate to deliver the results,
management looks at the prescriptive behaviours of
Kanban, Scrum, and Lean and determines how these
will be used and improved to facilitate the teams
delivery.
Leaders and Managers
In this light, we can look at the functions of leaders
and managers in organizations.
Leaders are outward-looking. They look beyond the
current system.
Leaders facilitate the creation of visions within the
global marketplace through collaboration. They group
people with interest and passion around an issue or
initiative, create an environment to foster the fow of
ideas, inspire the conversation and stand back, letting
the group work. The team will make the decisions,
set the agenda and pace, as the passion of the group
emerges. A leader checks in regularly, not to collect
status, but to see if there are any obstacles they can
remove for the team. Teams own the implementation
of the vision and its evolution. Leaders listen and if the
path diverges, ask, What is the value of this path to
the organization?
Managers are inward-looking. They intently study the
current system.
Managers of a system cannot be part of the system
or they will not have the objectivity to identify a
problem. Project managers should be far enough from
the project to critically observe it. They cannot do
this if they are making decisions within the project.
Similarly, project managers of projects in the value
stream may struggle to observe the value stream
from afar and as a result managers are needed for
the value stream. Although a project may seem to be
performing at the appropriate level, a dispassionate
observer of a number of projects may identify
performances above or below the others, which
presents an opportunity to learn how to improve
the process. Rather than a hierarchy of authority,
management should consist of an overlapping set of
responsibilities.
Risk Management
Managers are like the Catcher in the Rye. They
should stand outside the rye by the edge of the
cliff and prevent anyone from running off the
edge. Members of collaborative teams can help the
manager by warning the Catcher that someone is
running toward the edge.
Managers should observe the process and identify
risks and issues inside (endogenous) the system. Risks
are things that might go wrong. The manager should
identify how much warning will be given before the
Leaders are outward-looking.
They look beyond the current system.
SAN FRANCISCO 2013
SAVE $100 WHEN YOU REGISTER
WITH PROMO CODE
TEAMCOLLABORATION
Page 5
Contents
risk materializes and how long it takes to mitigate
the risk. They should also identify the warning signs.
If the mitigation takes longer than the warning time,
they may want to work to bring the mitigation within
the warning period. In order to identify early warning
signals, managers will beneft from a proper study of
control systems (Butterworth, Chebychev, Nyquist)
to identify that the system is becoming unstable.
Managers are responsible for the risks internal to the
system. When a system is failing, managers should
facilitate the creation of new agreed processes.
Leaders are looking at risks outside (exogenous) the
system. They are watching for disruptive technologies
or waning markets. Rather than deciding whether
a risk is signifcant or not, leaders should make the
system aware of them. Leaders may decide to invest
in options to allow the system to respond to a risk.
Team Dynamics and Confict
Before members of a new team trust each other,
it seems they withhold information. This leads to
confict or failure of the team. (Failure is not always
a bad thing. Remember that most effective learning
comes through failure.) From a game-theory
perspective, information-hiding is the behavior
individuals or factions will take to win, known as The
Strategy of Confict.
Eventually the system fails, and the participants in
the game learn to share information to succeed. In
other words, they collaborate. Collaboration is the
emergent behavior of the prisoners dilemma. This
behavior can be summarized as forming, storming,
norming and performing. This is the natural life cycle
of a system in which participants can choose their
own performance.
It is the responsibility of management with its inward
focus to ensure that the system cycles to the end
state of collaboration as soon as possible. In particular,
management should ensure that the system does not
get stuck in the underperforming forming state.
Confict avoidance results in delayed confict, which
results in worse and further confict. Managers
should ensure that the system has effective confict
resolution skills and processes. Confict resolution
leads to more confdence in solutions and prompts
teams to solve conficts sooner. This leads to less
serious confict, which leads to more confdence and
leads to more healthy confict. Confict is effectively
information hiding which indicates an adherence to
the strategy of confict.
Leaders with their outward focus will seek to identify
unresolved and unnecessary confict with external
agents: customers, suppliers and partners. Once
again, rather than avoid confict, leaders seek to
engage external agents in a collaborative state. Healthy
confict with customers, suppliers, and partners
will lead to more healthy relationships with more
benefcial information sharing. And will lead to strong
collaborations, ensuring leading change results.
Learning
The conscious-competence learning model states that
a system moves through four states.
1. Unconscious Incompetence. You do not know what
you do not know.
2. Conscious Incompetence. Now you know you do
not know something.
3. Conscious Competence. You know something but
you have to think about it, or refer to your notes.
4. Unconscious Competence. You know something
and you do not have to think about it.
Moving from Unconscious to Conscious
Incompetence is a revelation and may be quite
shocking. The trigger for this tends to come from outside
the system, and as such it is the domain of the leaders.
The best strategy for handling this is real options
because decisions are not made whether is something is
going to happen or not - we just prepare for it.
Moving from Conscious Incompetence to
Competence is the act of learning. Here the system
seeks to fnd a way to do something. This is an internal
process that should be handled by management
who will seek guidance from leadership. Shannon
information theory tells us that we learn most when
the chance of failure is 50%. The best strategy for
handling this is an Agile culture in which failure is
tolerated for the sake of learning.
Moving from Conscious to Unconscious Competence
is a case of process optimization. Systems improve
through repetition and by reducing the variance
between the desired and actual outcome. In
knowledge work, another way to accelerate learning
between these states is in helping others learn
the material. This forces the teacher to fnd new
Page 6
Contents
metaphors for less experienced learners, which
eventually can lead to a deeper level of knowledge.
This deeper knowledge is only achieved if the learning
is learner directed and not teacher directed. Teaching
the same material with the same metaphors and
examples does not improve insight. This aspect
of the learning is inward facing and as such is the
responsibility of management. This is best facilitated
by the Lean process.
Moving from Unconscious Competence to
Incompetence is also called forgetting. Management
should seek to avoid this. Knowledge in the
Unconscious Competence state is tacit rather than
explicit by its very nature. Information is contained
within documentation but knowledge is contained in
the mind. Management should ensure more people
have that tacit knowledge and that they continually
seek to spread the knowledge through collaboration.
The ultimate expression of real option-based learning
is a learning organization. The key success factor for a
learning organization is the behavior of management.
Management should facilitate a learning process that
promotes a learning culture, one that rewards those
who share knowledge and encourages those who hide
knowledge to share it.
Dealing with Uncertainty
As leaders drive the innovation within the system,
they will constantly push to defer commitments to
allow them freedom in their choice of solution. This
deferment of commitments causes uncertainty and
stress for the management of the organization.
Once again, Real Options provides the best solution.
Real Options provides a number of tools to address
this issue, most notably the last responsible moments,
which is another way of saying options expire.
Management will need to defer commitments by
specifying the conditions upon which a commitment
will be made. This will allow the monitoring of
decisions to become automated. Management will
now face bounded uncertainty rather than total
uncertainty. Total uncertainty causes the Must decide
now or Need to control behaviors that result in
management making immediate decisions rather than
deferring them until more information is available.
Leadership thrives in uncertainty because uncertainty
enables innovation, thus unleashing the talent in the
organization. People will innovate at the edges of
uncertainly. Innovation is highly restive and is not
encouraged in repeatable or predictive environments.
Thus, leaders must constantly temper chaos by asking
questions that do not take ownership (by providing
solutions) but keeps the visions connected to the
purpose and to the global initiatives. Leaders inspire
the possibility of the vision and the discovery of other
visions by the teams.
Current Management and Leadership
Theory
Much of the current Agile management theory is
inspired by manufacturing (Deming, Goldratt, Lean,
Theory of Constraints, Toyota). Whilst this addresses
the manufacturing aspects of software creation under
the observation of managers, it fails to address the
information arrival process as guided by the leaders.
It fails to defne business value, business risk and how
to incorporate new information, never mind actively
seek new information that breaks the model. To
address this issue, leaders must move away from
questions like Whats the business value? to the
questions like Do we have enough business value to
go to market? and Will we ever have enough value at
the rate we are generating business value?
Whilst Reinertson addresses some of these issues,
management needs to fnd new inspiration in
Financial Mathematic, Information Theory, Game
Theory and Learning.
Whilst Agile holds that the bottleneck is learning,
in reality the bottleneck always moves once the
issue is addressed. Leaders and managers who push
the decisions down into their organizations create
learning and collaboration, the basis for information
sharing. By asking the organization for answers,
managers unleash the talent. By collaborating with
the outward connections to the organizations, leaders
unleash innovation in their organizations. Leaders
open the many paths before organizations. Managers
facilitate the processes to move rapidly down the
paths and discover the best solutions within their
talented and creative organizations and facilitate the
new visions that will arrive.
READ THIS ARTICLE ONLINE ON InfoQ
http://www.infoq.com/articles/leadership-management
Page 7
Contents
Team Collaboration eMag / Issue 4 - October 2013
Agile Teamwork: The Leadership -
Self-management Dilemma
Written by Rowan McCann
Introduction
Back in the 1990s, self-managed teams were all the
rage but often failed mainly because team members
lacked people skills. These ideas of self-managed
teams were borrowed by the Agile movement when in
2001 they formulated a new way of working, based
on Agile principles.
However, self-managed teams are inherently unstable
and are only successful when they understand and
deal with the Leadership Self-Management
dilemma. Too much central control destroys agility,
inhibits creativity and resists change. Too much self-
management leads to chaos and anarchy and destroys
a team. A successful Agile team needs to operate as
far along the continuum towards self-management as
it can without tipping over into chaos. You cant just
say to a software development team, OK, youre now
an Agile team you need to self-organize. This is a
recipe for failure, and one of the reasons why many
organizations resist the Agile approach.
What is required from the very frst meeting of a new
Agile team is an understanding of the basics of team
dynamics. Everyone must learn as much as they can
about human behaviour and why people do the things
they do. My own IT degree course spent hardly any time
on people skills and none on the even more diffcult
concept of what people need to do to self-organize into
a high-performing team. Ive had to learn this through
experience. I wonder how many readers fnd themselves
in a similar position?
Ive successfully applied the Team Management Systems
concepts to many Agile teams that Ive been a part of.
A good starting point is for everyone to learn about the
nature of teamwork and the preferences people have for
some tasks and not others.
Weve put up a free Agile Team Performance
Questionnaire on our website to help you to measure
your own Agile teams strengths and weaknesses as
far as teamwork is concerned. Youll get a free eight-
page assessment of what you think about your teams
performance, based on the Types of Work Wheel.
The Types of Work Wheel
The Types of Work Wheel identifes eight distinct
Types of Work that all teams need to undertake
regardless of their industry. These eight work
functions are listed below, with permission from the
Team Management Systems organization.
Team Management Systems Types
of Work Wheel
The Advising function is associated with the
gathering of information from all stakeholders and
responding quickly to changing requirements. It
involves keeping up to date with developments inside
and outside the organization and passing advice
Page 8
Contents
to others to help them in their work. It requires a
transparent fow of knowledge of what is going on
and where, and a focus on consulting skills so that
information can be gathered quickly, accurately and
effectively.
The Innovating function involves generating new
ideas and new ways of doing things. This requires the
development of creative problem-solving skills so that
the team remains one step ahead of its competitors.
To do this well requires original thought, imagination
and innovative thinking.
The Promoting function is concerned with the
identifcation of opportunities and the selling of these
opportunities to others, both inside and outside
the organization. It often involves the application of
infuencing skills and making presentations. It can also
involve communicating the team or organizational
vision. High visibility throughout the organization
may also be required.
The Developing function is associated with the
turning of concepts into reality. Ideas are worked
on to produce practical products and services.
In many cases, it may also involve developing
workable and practical solutions when problems
arise. Agile teams need good analytical skills so that
requirements can be quickly prioritized, enabling
accurate estimates of iterations and burn-down
charts.
The Organizing function involves organizing
people and resources efficiently by setting clear
goals and objectives and making team members
accountable for their actions. It is associated with
the implementation of quick, effective action when
problems occur, so that the planned outputs are
always within reach. In summary it is the function
that ensures that the work of the team is structured
and focused towards common objectives.
The Producing function focuses on outputs,
ensuring that iterations are completed to high
standards of effectiveness and efficiency. It is the
function associated with the regular delivery of
releases and other services. It requires a systematic
approach to work and an emphasis on the delivery
of products on time.
The Inspecting function requires an attention to
detail and an emphasis on the monitoring of systems,
contracts and outputs. It is associated with a focus
on accuracy, ensuring that work outputs are always
delivered to the right quality. This function is the
classic control function in which procedures are
regularly monitored for effciency. Its often a core
feature of the sprint review process.
The Maintaining function is a support function
which ensures that proper standards of conduct and
ethics are upheld and that quality is maintained. It
is associated with supporting others in the team so
that the team processes follow agreed ground rules.
Personal conviction and loyalty are often important to
this function as is an interest in helping others.
Work Preferences
Nobody enjoys all the tasks that have to be done in
an Agile team. Some tasks we like; others we hate.
Work Preferences is just another name for what we
like doing at work and how we like to do it. Work
Preferences emerge from individual tendencies to
show consistent patterns of relationships, thoughts,
feelings and actions in the work environment.
Preferences are usually transparent and are often the
frst thing we notice in others Hes rather quiet, isnt
he? or She never stops talking. Some people prefer
to think things through on their own whereas others
need to talk to clarify their ideas. Preferences are
readily visible to others and are usually the basis of
frst impressions.
If we are more extroverted, we likely enjoy work with
many interactions with others both inside and outside
the organization. If we are more introverted, we may
LINKING
TM
Organizing Advizing
Innovating Developing
Inspecting
Promotong
Producing Maintaining
Page 9
Contents
prefer to work on our own with few interruptions
and minimal meetings. Under optimal conditions, our
energy can fow freely with minimal resistance. Just
as electrical energy generates heat when it meets
resistance so our work energy generates tension and
stress when it has to fow through areas that dont
match our preferences.
I prefer to work in the Advising and Innovating areas
on the Types of Work Wheel and I dont really enjoy
Promoting or Organizing activities, so wherever
possible Ill spend time thinking about new ideas or
fnding out as much as I can about the project.
In an Agile team, theres likely to be an imbalance
among the work preferences of all the team members.
If everyone is like me then therell be a tendency to
give priority to making changes and incorporating the
latest ideas. Teams like this may not ever track their
burn-down charts!
Other weaknesses occur if everyone enjoys just
Organizing and Producing. Your team may be well
organized and on target but is it really delivering what
the stakeholders want or need?
If your Agile Team is to be truly effective, you
must understand the work preferences of all team
members and look at the preferences balance. It
will give you an immediate picture of strengths
and weaknesses, as far as teamwork is concerned.
Information like this helps the team match everyones
work preferences to the critical job they have to do.
Where the match is high, our energy fows freely. We
are more likely to enjoy our job, stress is lower and we
feel happier at work. But all eight work functions must
receive the priority they need and never be relegated
to lower importance.
The Team Management Profle
Team Management Systems developed the
Team Management Wheel to combine the idea
of preferences with the critical work functions
that all teams need to do well. This describes the
characteristics of people who enjoy undertaking the
various Types of Work.
The Team Management Wheel
When team members complete a 60-item
questionnaire, they receive a Team Management
Profle that discusses their work preferences
in detail. The report identifes a major role (e.g.
Thruster-Organizer) and two related roles
that usually account for the majority of the
respondents work preferences. Normally, you
will enjoy a job where two-thirds of your critical
tasks align with your work preferences. Such a
high level of engagement with your preferences
means greater commitment to the team and
increased happiness at work.
Here are some general characteristics
of each sector:
One of the main applications of the Team
Management Wheel is to allow teams to map
LINKER

Explorer
Promoter
Assessor
Developer
Creator
Innovator
Controller
Inspector
Concluder
Producer
Upholder
Maintainer
Reporter
Adviser
Thruster
Organizer
Reporter-Adviser: Prefers gathering information and
likes to fully understand situations
before acting
Creator-Innovator: Enjoys thinking up new ideas and
new ways of doing things rather than
focusing on delivering outputs on a
regular basis.
Explorer-Promoter: Like to take ideas and promote them
to others, not worrying too much
about any details involved.
Assessor-Developer: Enjoy analyzing and developing
different possibilities before decisions
are made
Thruster-Organizer: Like to make things happen and get
results rather than waste too much
time debating issues
Concluder-Producer: Practical people who like to carry
through things to the end by working
to a plan
Controller-Inspector: Quieter, refective people who enjoy
the detailed side of work and like
dealing with facts and fgures.
Upholder-Maintainer: Enjoy working in support of others
ensuring that tasks are delivered to
high standards
Page 10
Contents
everyones role preferences then use the distribution
to assign tasks and responsibilities, as well as adding
key actions to the team ground rules to ensure that
those parts of the Wheel having a lower preferences
are not ignored.
Diversity
Different roles on the Team Management Wheel see
the world in different ways and this is excellent for
problem-solving and decision-making. A balanced team
on the Team Management Wheel will ensure multiple
descriptions of any event and from this diversity
the team can consider more options. If everybody
considers an issue from the same perspective, the team
will produce a much narrower range of options to be
considered, and this invariably leads to group think.
However, opposites on the Team Management Wheel
are prone to negatively consider each other. Explorer-
Promoters, for example, may see Controller-Inspectors
as dull, boring, pedantic and detail-oriented. Controller-
Inspectors in turn may see Explorer-Promoters as
loud-mouthed, waffing and with little substance. Its
a natural human tendency to dismiss those who are
different. Nevertheless, all roles are necessary to get
the best from a team because it is often out of diversity
that the best solutions arise.
This is where teams have diffculty self-organizing
because confict is always incipient and can break
out at a moments notice, leading to chaos and failure.
The traditional way to prevent this has been strong
leadership control, but this goes against the values
of Independence and Empowerment that are usually
the hallmark of the Agile knowledge worker (BAs,
developers, testers, PM etc.). Team members react
against the organizational constraints and dont feel
they have ownership of the teams outputs. This
results in low levels of motivation and commitment,
which leads to apathy and low performance.
Once team members learn to understand and value
difference, leadership control can be substantially
relaxed and self-organization can take place. This
requires a substantial training and development input
from day one. High-performing Agile teams dont
spontaneously create themselves. They need help!
Linking
So what are some of the important linking skills
that keep an Agile team productive? The set of skills
applies individually to team members and collectively
to the whole team. To sustain a low level of leadership
control and a high level of autonomy, Agile teams
need to focus on the central part of the Team
Management Wheel, the Linker. Six people skills, fve
task skills and two transformational skills make up the
set, but the most important ones to get right are the
people-linking skills. These enable the team to operate
at the self-organizing end of the Leadership/Self-
Management continuum. The people-linking skills are:
Active Listening, Communication, Team Relationships,
Problem-Solving & Counseling, Participative Decision-
Making and Interface Management.
Active Listening
Listen well while others are speaking
Ask questions rather than make statements
Summarize well their understanding of what has
been said
Not interrupt when others are speaking
Check others feelings on important matters
Engender a good two-way discussion of issues
Communication
Contribute regularly to discussions at team
meetings
Communicate persuasively when speaking
Keep others well informed
Be effective at written communication
Facilitate group discussions well
Vary communication style to match the needs of
others
Team Relationships
Make sure team members understand how their
roles and responsibilities affect one another
Ensure that team members value one anothers
contributions
Positively address confict issues that may arise
among team members
Develop high levels of trust with team members
Encourage the development of mutual respect
Promote loyalty and pride among team members
Problem-Solving & Counseling
Be readily available to discuss problems
Deliver on commitments
Be responsive to others problems
Gather and assesses information before making
judgments
Help team members to improve performance
Ensure everyone feels able to share their concerns
Page 11
Contents
Participative Decision-Making
Share key problems and opportunities with other
team members
Encourage differing points of view be put forward
and discussed
Encourage people to express their opinions and
participate in discussions
Involve the team in the development of solutions
to major problems and opportunities
Organize effective meetings so that team
members can contribute to solving problems
Ask for input from members of the team about
matters that affect them
Interface Management
Coordinate and integrate the work of other team
members
Ensure that team members regularly get together
to review how well the team is working
Communicate what is needed from other groups/
teams in order to achieve team goals
Effectively handle disagreements between their
team and others
Encourage team members to cooperate with
other groups that impact the team
Represent the team well in discussions with senior
management
It takes time to develop these skills but it starts at
the frst meeting of the Agile team. Team members
received a personal Team Management Profle
report which gives them positive feedback about
the way they prefer to work. The Pacing section of
the report highlights how each person likes others
to communicate with them. This opens up discussion
of the Communication skill. Everyone learns that
communication is dynamic: you have to constantly
change the way you communicate depending on who
is on the other side of the loop. A Thruster-Organizer
interacting with a Reporter-Adviser needs to use a
totally different approach than when interacting with
another Thruster-Organizer.
Using their Profle report as a basis, team members
are encouraged to draw up list of answers to two
questions:
When interacting with me its best if you
The things that annoy me most when others
communicate with me are
This information is then shared.
Conclusion
The Leadership/Self-Management dilemma has
intrigued behavioural researchers for years. For Agile
teams, the challenge is to strike a balance between
the structure required to achieve high performance
and the leadership control to effect it. Teams can only
operate at the self-management end of the dilemma
if they understand a lot about people and why they
behave the way they do.
High-performing Agile teams have learned to:
Recognize individuals as autonomous, intelligent
agents that interact and collaborate by
understanding and valuing behavioral differences
Operate with simple ground rules that help them
function at the edge of chaos
Willingly undergo continuous learning and
adaptation
Implement the Linking Skills, where guidance
rather than control allows emergent order to
appear, thereby harnessing creative talent
Operate with open information to all team
members and stakeholders, making use of Agile
project management tools to capture and share
rapidly changing situations
Is your team coping with working in an Agile way?
Take the free Agile Team Performance Quiz now and
rate your current or future Agile project. Youll get a
free eight-page assessment of what you think about
your teams performance.
About the Author
Rowan McCann has 10 years experience
implementing IT applications, with a management-
consulting background. He has worked on some of the
largest global ERP and CRM implementations in the
capacity of developer, business analyst and architect.
He has recently partnered with international
teamwork specialists Team Management Systems, to
conduct research into improving the performance of
IT teams.
READ THIS ARTICLE ONLINE ON InfoQ
http://www.infoq.com/articles/agile-teamwork
Page 12
Contents
Team Collaboration eMag / Issue 4 - October 2013
Designing Collaborative Spaces
for Productivity
Written by Deborah Hartmann Preuss
Many think that Agile teams all work in common
rooms, but the truth is not so simple. We forget that
the classic XP-team room layout was called caves
and commons and it explicitly recommended that
people have access to some personal space, as well.
Teams fnd out fast enough that some of the facilities
and creature comforts left behind in traditional
spaces were there for good reasons. When working
with Agile, working close together and without
interruption, its more important than ever to account
for the needs of human beings in designing healthy
and effective workspaces. To that end, this article
shares the collected wisdom of dozens of teams, as
collected by several experienced Agile coaches.
The Problem with Meetings
Over time, traditional software teams can become
oblivious to the time they dedicate to activities like
arranging meetings, reviewing email, and waiting for
stragglers to fnally arrive. These are the necessary
evils of teamwork in large organizations. However,
as teams move toward a fully Agile approach, these
inconveniences rise to the level of major obstacle:
You dont want to have to wait to fnd a meeting room
thats available in order to get some modelling done.
You dont want to have to worry about somebody
erasing your whiteboards, or throwing your index
cards in the garbage. Ive worked in several companies
where there was a severe shortage of space, where
we would have to wait for days to fnd meeting rooms.
Progress ground to a halt.
-- Scott Ambler [1]
War Rooms, Team Rooms, Bullpens
The classic solution, and a key strategy to support
and foster Agility, is co-location. The osmotic
communication which buys Agile teams immediate
feedback within the team relies on team members
working within the same visual and auditory space.
The idea of teams working in an entirely new type of
space often comes as a shock to the organization. But
while some teams have trouble getting management
to replace cubicles with tables and whiteboards,
other teams suffer equally when eager (or scheming)
managers remove not only cubicle walls but also other
facilities long deemed important to team morale and
function. This may be done innocently, not realizing
what is lost, or with an eye to reclaiming space in a
congested building, a sacrifce demanded of the team
in exchange for the open space they need.
Look Before You Leap
Its important to look around before eliminating a
space. We can become so used to our surroundings
that we no longer notice whats really going on. Take
the time to notice how things work: where are people
going when they are not at their desks? Not every
absence is for a meeting. People run errands, take
Page 13
Contents
walks, confer with other departments, and reappear
with drinks, markers, printouts and new facts. Think of
the entire calendar year if your location has changing
weather: team members will bring coats, gym bags,
umbrellas and motorcycle helmets in with them.
Determine how much space each person really needs,
both at their workstation and elsewhere in their team
space. A single persons workspace, for example,
probably shouldnt measure less than 25 square feet.
This calculation is especially important when two are
pairing at a single workstation. Its tempting to save
space by reducing the footage per person but people
still need their own space and teamwork will suffer if
its not provided, as teammates inevitably get on each
others nerves. In general, a collaborative team space
accommodates no more than half the number people
it would if arranged as a conference room.
As teams move to a collaborative style, consider
the activities theyll need to handle in their spaces.
People will still need to handle sensitive or personal
phone calls and emails. New collaborative tools
like fip charts, whiteboards, bulletin boards and
projection screens require extra planning to remain
unobstructed and usable. And when many people and
computers share a single space, ventilation becomes
more important than ever.
Care and Feeding of an Agile Team
Its important that someone be tasked with watching
for and following up on infrastructure problems
right from the start. This seems simple, but a team is
sometimes so engrossed in learning new practices and
working in unaccustomed ways that they neglect such
details, not realizing that these are in fact contributing
to their diffculties.
Common problems can be as simple as putting
a programmer at risk for back pain or tendonitis
by using a keyboard at the wrong height, easily
resolved with an under-table keyboard tray. Some
team members strain their eyes against window
glare on their monitor again, easily fxed by moving
a workstation or providing flters on windows or
screens. People will usually, at frst, sacrifce their
lunch hour to make important personal calls. As the
team progresses and their work achieves a regular
rhythm, these accommodations become inadequate
and grate on the nerves.
Team self-organization also means that food and
drink are likely to appear in the workplace by way
of celebration or to facilitate collaboration at key
moments. Fruit and other healthy snacks take up
space. A cramped workplace with awkward storage
hampers the fow of teamwork and team building.
Alittle extra table space is a simple device to foster
team creativity.
Obstacle removal is a key function of the team coach,
ScrumMaster, or PM. Obstacles related to the team
space should be prioritized on the teams obstacle list
and should be resolved early. While it may be tough
to quantify the impact of inappropriate working
conditions, again and again weve seen signifcant
increases in teamwork, hence effectiveness, once
these obstacles are resolved.
Elements of a Humane Workspace
After so many years of using professionally designed
work spaces, teams sometimes throw out the baby
with the bathwater when they start from scratch with
their own designs. Elements like light, air, traffc fow,
noise, refreshments and comfort are not negligible:
high productivity teams still consist of people,
not robots, and the spaces in which these people
work can enable or discourage them. Its true that
motivated teams have been known to work in the
weirdest, most disadvantaged locations but when a
team commits to increasing their delivery of business
value using Agile methods, it is appropriate for them
to ask management to support the needs of their new
collaborative work style.
Here is some advice on creating spaces that work,
from coaches who have seen many and varied
team spaces, in both successful and unsuccessful
arrangements.
Mishkin Bertieg has blogged about eight important
considerations when creating a healthy and effective
work space. While some of these may seem obvious,
weve seen them compromised again and again.
Light, Air, Nature: An appropriate amount of natural
light, air circulation and live plants are excellent ways
to make a space suitable for human occupation.
Layout: People need to be able to face each other and
work beside each other. They also need a semi-private
space to have discussions or make phone calls. The
Page 14
Contents
walls of the space need to have large areas that can be
used for whiteboards.
Ergonomics: Good chairs, tables at an appropriate
height, and the fexibility to allow for individual
ergonomic needs.
Privacy: Everyone needs to be able to get away for
short amounts of time. Some organizations provide
separate mini-conference rooms or hotelling spaces.
Others allow staff to keep a private cubicle away from
the team room.
Personalization: The space a person occupies needs
to be fexible and personalized. People need space
for pictures, toys, plants, and other incidentals to help
them make a space their own.
Visibility to Outsiders: Other people in the
organization need to be able to see and hear what is going
on with the Agile work team. Open doors, open windows
or a bullpen formation of cubicles all allow this.
Convenience: Washrooms, coffee, printers and other
common services must be easily accessible. The team
should not be set off and isolated from everything else.
Noise: The team will be noisy. Make sure that people
outside the team room are far enough away or
isolated in some way from the noise. It can be hard to
balance this with convenience and visibility.
Support for Agile Modeling
Agile teams use a variety of methods to increase
collaboration. A common one is the move away from
formal intermediate documentation. This approach is
worth explicitly planning for: when replacing heavy
documents with models on whiteboards and other
information radiators, teams suddenly discover the
needs for lots of wall space or for electronic aids.
Scott Ambler has written in depth about specifc
factors teams should consider as they are move
toward Agile modeling. Here are some key points:
Signifcant whiteboard space: Place whiteboards
foor to ceiling wherever empty wall exists, even on
support pillars if theyre more than a foot (30 cm) or
so in width. Developers should have their own private
whiteboard space.
Digital camera: Teams need to take snapshots of their
modeling artifacts to display them on internal web
pages describing the project, to capture images of
paper-based models or simply to capture a permanent
copy of a diagram so it may be placed under version
control.
Modeling supplies: The Use the Simplest Tools
practice suggests that you work with the simplest
tool that will get the job done, therefore you need
ready access to whiteboard markers, Post-It Notes
in different colors and different sizes, index cards
(you may also want different colors and sizes as well),
writing paper, fip-charts, tape, stick pins, string, and
whatever other modeling supplies that your team
requires.
A bookshelf or storage cabinet: To store your
modeling supplies and reference books.
Large table: Some techniques, such as Class
Responsibility Collaborator (CRC) modeling, require a
large table to work on.
Computer: A computer in your modeling area can
often prove advantageous, particularly to access
previous models that have been placed under version
control. Make sure you get a good one because you
dont want a group of people waiting on a machine.
Wall space to attach paper: You need some place to
attach paper artifacts.
Projector: If you are going to have a computer in
your working area you should also consider having a
projector to display images on the wall. This promotes
communication because everyone can see the
information.
Toys: Something to play with can help you to get
unstuck when youre working.
A Real Example:
An Agile Team-Room Wishlist
Over time, organizations with many teams may want
to keep a list for the ideal team room, to help facilities
staff create more team spaces. Resist the temptation
to tightly defne this: constraints and team needs will
be different each time, and you must leave room for
creativity.Any formula you create should focus on the
goals, the needs to be met, not the means.
Page 15
Contents
Here is list compiled by Joseph Little Kitty Hawk
Consulting with a team of coaches for a particular
organization, based on lessons learned after a dozen
teams had struggled to create suitable spaces with
varying degrees of success. This is specifc to the
needs of a given business with its own hardware,
teleworking, and space constraints. Whats really
important on this list is the human considerations, not
the specifc details.
Note the phrasing: its intended as a basis for
discussion, not a ransom note. And it is critically
important to allow teams to participate in the design
of their own spaces, which will naturally lead to new
ideas and customized spaces. This last pointer is all
too often skipped over in the name of effciency, so its
worth restating. Involve team members in the design
of their own space, to eliminate obvious stumbling
blocks that will hamper their work in early iterations.
The gains in morale and productivity outweigh the
cost of their involvement.
Here is Joes list:
Our Agile Team-Room Wish list
Note that there are other ways of accomplishing the
underlying goals; we can pursue other alternatives if
we cannot have these ideal conditions.
1. Room Size: In one successful case, we had nine
monitors/docking stations (for laptops) set up in a
room with a maximum occupancy of 20 people.
The room is rather large and gives space for people
to live together for an extended period. This seems
about right and comfortable for a team that is almost
100% dedicated (i.e. in the room most of the day).

2. Team Privacy: Constant outside noise distracts
and stresses the team. This also suggests that team
conversations are carrying outside the team room:
not a good idea.

3. Individual Privacy: Ensure there is a place to make

personal phone calls or do sensitive work (e.g. fling a
health claim or writing a performance review).

4. Light, Ventilation: The needs for these are much

greater when the team is in the room all the time.
Fans: Teams want these for when the A/C goes
out, which has happened again recently.

5. Creative Space: This is hard to describe, but

important. At a minimum, the space should not be dull
and depressing. Ideally the colors and other aspects
should support creativity.

6. Docking Stations: The docking stations add value,
but also take up room. They need to work with all,
not just some, of the teams laptops, and must have
network connectivity. Think through exactly what the
new team will need in advance.

7. For teams using pair programming: we recommend
large (23-inch) fat screen monitors, connected to the
docking stations.

8. Whiteboards: The room should be covered with

whiteboards. Magnetic whiteboards are expensive,
but key. Obviously, whiteboards require markers and
erasers.
Need at least 300 tiny multi-colored magnets.

9. Flip-Charts and Stand: Preferably with large Post-

It Note paper, and space in the room for it.

10. Polycom Speaker Phone: Maybe two if its a large
room.

11. Land Lines: Several phones to allow people to
make and receive phone calls, with speaker-phone
capability.
Placement of phones should be balanced: at least
two of the phones should be placed on the center
table, others at the edges of the people space.

12. Cards: Start with 400 cards in multiple colors.

(25% should be 4x6, the rest 3x5)

13. Outlets: We need network access (via the docking
stations), outlets for land lines, and electrical outlets.
Remember that people will move around; we need
more outlets than people.
There are cheap ways to protect the team from
tripping on cords running to a central table.

14. Tables: A mixture of small and large tables (or
small tables that can easily be put together). Usually
arranged as one big table (for six to eight people) in
the middle, and several small tables around. One small
round table, for small ad hoc meetings of two to three
people.

Page 16
Contents
15. Large Wall Clock: So all can see when the stand-up
will start or when meetings will reconvene.
16. Wireless Internet: So visitors from other
departments can connect.

17. Printer: A good laser printer that can print up to
11x17 should be in the room, or very close.

18. Small Conference Rooms: Either: (a) A quiet space
within the team room for conferences (i.e. provide more
space or one adjacent with low walls) This works in a
large room with respect to team size. Or: (b) two small
conference rooms nearby that are dedicated to the team.

19. Place to hang coats and leave outer footwear (in winter).

20. Space for storage of personal stuff: This could be under-
desk fling cabinets or a large horizontal fling cabinet.
More of this is necessary with contractors or
other mobile team members who have nowhere
else to put their things.

21. Desktop PC: This can be used for miscellaneous
purposes (developer testing, integration of code, etc.).

22. Calendars: A few big calendars (monthly views)
that can be written on.

23. Digital Camera: Saves lots on documentation time.
Can be shared with another nearby team. Must be
easy to download pictures to the laptop.

24. Small Fridge: A small refrigerator in the room (or
nearby) to store cold water and soda.
Plan to Learn
Hopefully, managers, team members and other
leaders will collaborate to create the best team
space they can, given their resources and perceived
constraints. Of course, a month in the new space
is sure to reveal surprises and errors in judgement.
Dont forget to apply the Retrospective Prime
Directive when looking back on what youve created:
everyone did the best they could at the time.
Continue to consider your workspace when each
retrospective asks, What should we change? When
you discover a better way, act on it quickly, and dont
forget to celebrate your successful changes when the
retrospective asks, What worked well?
Remember that you dont need to imagine everything
up front; you can tweak it with each iteration. But big,
immovable and expensive items are defnitely worth
considering up front to allow lead time. Too often we
see teams ready to go long before their workspace is.
Be aware that what you learn might just include We cant
do this here. Be realistic, and be prepared to defend what
your team really needs to reach high productivity. If you
cant get it, you may need to design a hybrid, semi-Agile
process - but be sure to make it known that the full gains
of Agility probably wont be achieved.
Its just not worth it to have a high-performance team
hampered by a poor workstation setup.
-- Mishkin Berteig
Ive seen lack of basic resources such as decent chairs,
tables, food, drink, and top-notch workstations
dramatically hamper software development efforts. If
your project team is being nickel-and-dimed to death
then I have to question if your project is important to
your organization if it isnt, cancel it now and invest
your efforts on something more productive.
-- Scott Ambler
About the Author
Deborah Hartmann is an Agile practitioner,
trainer and coach based in Toronto and working
internationally. Deborah is passionate about making
work both valuable to the business and enjoyable
for the team. Shes coached both large and small
businesses in Agile adoption, has been lead editor for
InfoQs Agile Community since April 2006, and has
facilitated OpenSpace conferences for the XP and
BarCamp communities in Canada and the US.
SAN FRANCISCO 2013
SAVE $100 WHEN YOU REGISTER
WITH PROMO CODE
TEAMCOLLABORATION
READ THIS ARTICLE ONLINE ON InfoQ
http://www.infoq.com/articles/agile-team-room-wishlist
Page 17
Contents
IBMs Elizabeth Woodward
on Distributed Team Collaboration
Interview with Elizabeth Woodward by Dan Puckett
What are the main problems faced by
distributed teams?
I think the real problems faced by distributed teams
are communication and collaboration, being able
to work together across different cities, countries,
continents when you are not in that face-to-face
situation. Right now, I can see your reactions. I can
tell if you are totally baffed by what Im saying and I
can tell if were making a connection. When we have
a distributed team, they are missing that rich channel
of communication. They are basing their conversation
and understanding of off this other less rich channels,
off of just the verbal or just the text document. They
are making assumptions and trying to understand and
relate based on that less rich channel. So I really think
that out of all the challenges thats the biggest one for
distributed teams.
You mentioned some of the challenges
around communication. What about
collaboration?
Around collaboration - its one thing to be able
to go and sit next to somebody and both of you
be at the keyboard and youre working through a
diffcult problem. Maybe one person is working on
the keyboard and then you trade over to where the
other person is working and you have that discussion.
Walking up to a whiteboard and youre diagramming
and you are able to understand very quickly what the
other person is trying to communicate through those
very visual, tangible methods. When were working
in a distributed environment, those can be real
challenges if we dont have ways to overcome those
situations.
Lets talk about some of those
ways. How do you mitigate some
of the problems for example with
communication in distributed teams?
First of all, I think that the communication starts
with When is the time when we are going to get
together to communicate? We just start with that.
We have teams that are spread over continents
dealing with the time-zone issues. So, it can be really
easy to choose a form of communication where only
part of the team is really present to hear the verbal
side of it. Maybe you are communicating by an email
message with the rest of the team. It can be really
easy to say OK, were in a distributed environment,
this is how were going to handle it. Were going to
talk and well send you email and you can keep in
touch that way.
What that really does is it destroys the team working
together and feeling very close-knit and part of
a team. What we see is that teams that are really
effective take turns at maybe meeting at a time that
is less comfortable for them for the sake of teaming
and they really value the other parties and the other
team members contributions. They all make some
adjustments to their schedules and the other team
members in other areas will also make adjustments
and they are sharing the pain in that area, but it also
leads to a greater sense of teaming.
I have to tell you, with daily Scrums a while back, I
heard a team say, We have a tool: we click off our
tasks, so we dont really have to meet for the daily
Scrum and its hard and its inconvenient any way.
The tool makes it all better. I think what were
really missing there is the fact that we have to
communicate; we have to understand where each
other is coming from. We need that time when
were together, understanding What it this person
working on? How can I help you? How can you help
me and how can we together achieve these results?
So, when Im speaking to the daily Scrum its not
really about clicking off tasks, then allow me to
let you know what my status is, its really about
Page 18
Contents
collaborating, working together and understanding
how we can support each other to achieve our goals
for that sprint.
Can you give a specifc example about
a distributed team that made that kind
of compromise on time and had it really
work well for them?
Absolutely. In fact, I have to tell you our team
within Quality Software Engineering uses the same
practices and we have team members that are
spread across the United States. Were in Austin,
Texas, were in Raleigh, were in New York and
we have folks that are also in China and India and
Greece. We had a time where it was very diffcult
between China and the Central Time Zone in the
United States to fnd the time that really worked
well. There was more of this Ill put my notes some
place, if Im in the time zone that happens to be off
and somebody will read them and the rest of the
team will know whats going on.
We really found that we were disconnected during
those times. We felt less part of a team and I think
it was refected in how we ended our sprints. When
you get to the demos and not everybody seems
to be quite on the same page. Weve personally
experienced that. We feel closer and we know more
about each other and were able to really achieve
good results on keeping in touch in that way by
adjusting.
Lets talk about collaboration and how
you mitigate some of the problems
stemming from the need to collaborate
across a distributed team.
You have to understand Im very much focused on
the principles and practices. I think that in order to be
successful you really have to understand why youre
doing things. You have to have good fundamental
practices and the tooling comes second. That said,
when you are working in a distributed environment,
you really need to have the tools in place that will help
you to be successful. Things like a desktop-sharing
tool so that you can transfer control, so that you can
both be on the same page. Some of the cool tools that
are out allow you both to edit a document at the same
time or multiple people to edit a document.
Going to the task boards and being able to see the
user stories and the tasks all on a physical board is
really wonderful, but when we get to that distributed
environment, we really need to have an effective tool
where we can see our product backlog and we can see
what the prioritization is. And we can work together
when were getting ready to pull the stories up and
defne tasks and things where we can collaborate
together and work on those things and see where were
at together. The tools become important for that.
You mentioned the fundamental
principles being very important. Give
us a couple of examples of principles
that you fnd to be crucial for good
functioning with distributed teams.
I think in A Practical Guide to Distributed Scrum,
every chapter is focused on a different aspect of
Scrum. What weve tried to do is weve tried to say,
Here is this thing that you do, here is this meeting
and here is why you have this meeting and here is
what the purpose is. Out of that, you really have to
understand what those core principles are, why you
are doing this before you start making any changes or
we get back into that daily Scrum situation I described
to you, where If Im really only trying to tell you what
tasks Ive done, why cant I just click this off?
So every chapter, every point from what you need to
have in place before you go into sprint planning, why
you need to have those things in place, understanding
that before you start making changes in the name of
helping a distributed team. There are adjustments
that you have to make, but you really need to
understand what the trade-offs are before you start
making those adjustments.
Lets talk about some of those
trade-offs.
This isnt technically Scrum - well get into the
practices - but lets talk about estimating. Dealing
with Agile estimation and planning, the whole team is
going to be involved in estimation. We want to make
sure that everybody whos going to be involved in
that user story is part of the estimating process as a
good cross-functional group of people. Each of them is
playing planning poker and we come to consensus on
what the size of that story is. Thats the core principle
of what were trying to do and there are reasons why
we want to do that. We want to make sure that we
get input from all these different roles so we really
understand what has to be done.
We want to make sure that we understand all of
Page 19
Contents
those pieces and thats all included in the relative
size of what were doing. When we have a very large
team, the chances that were going to be able to get
everybody together at a certain time and everybody
together is going to play planning poker on this
particular story is probably not going to happen. We
have to understand that if were going to pull together
a subset of the people, what is the implication going to
be? If were going to take a representative approach,
we have 10 Scrum teams and we want to make sure
that theyre all in synch and in harmony and we can
include everybody in the estimation.
First of all we look at Can we break that apart,
smaller? but the other thing we do is we say, If I have
representatives coming together, the impact of that
might be that we dont have buy-in from the teams. So
lets make sure that, if were getting an estimate from
representatives, that there is the connection back to
the teams and that we have consistency and harmony
and then we take their input into account and make the
adjustments we need to make on that sizing. Thats one
example. We hear some very command-and-control
things, where not everybody could be involved, so certain
people went in and they said, This is what the estimate is.
You take that back to the team and you dont have
the buy-in. First of all, the estimate may not make any
sense and the second part of that is you may not have
the buy-in from the team thats going to be doing the
work. So youve not met some of those core principles.
Thats what I was getting at.
You mentioned the book you came
out with recently, A Practical Guide to
Distributed Scrum. I understand you and
your co-authors actually wrote that book
as a distributed team. What was that like?
We did. Ive been working with distributed teams
almost exclusively since 2002. I just recently moved
into a real offce near real people, but pretty much
everything that Ive done has been with distributed
teams. I know that there are people who say that
you cant really have a team if you are distributed or
you dont build those strong relationships. Im sorry,
thats not true, you can. Ive experienced some really
great teams like that. Steffan Surdek is back in Canada
and Matthew Ganis is in New York. The core three
authors on the book, we worked together having the
discussions, editing each others work by wiki or by
document and change tracking and things like that.
It was a really good experience. We built some good
bonds. On a broader level, this work really included
the thoughts and ideas from people across IBM and
outside of IBM, too. We made each chapter available
for people to review and comment on. We had a lot
of brainstorming sessions where we had people from
across the globe, across different business units
and brands, different perspectives from product
development over to application development sharing
their experiences and working together to develop
content. What I think is incredible is youre not bound
by one person sitting right next to another. You are
able to include people from all over to come up with
something thats better than what any one person
brought to the table. Thats what I love about working
as a distributed team.
Did you run into any speed bumps while
writing the book that were related
to the fact you were writing it as a
distributed team?
Always. But I think its not so much working as a
distributed team as working in a way that brings in
different ideas and perspectives and respects that,
and where its disagreement for the purpose of
creating something new and better as opposed to Im
right and youre wrong. Which one is the right? We
have to have those discussions and really understand
and see what the results are at the different actions
and from that we can say, All of us together agree
that this is probably a good way to proceed. The
speed bumps were more about just that creative
energy of the people with very different experiences
and opinions coming together and sharing their ideas.
I think thats one of the challenges of any sort of
teaming. If its a really good team, you have strong
people that are sharing their skills and experiences
and you are trying to create something from that.
Lets talk about Scrum specifcally with
respect to distributed teams. How does
the Scrum Masters role change when
working with a distributed team?
I really think you have to be an even stronger
facilitator. Facilitation is the key to that Scrum
Master role and when you get into the distributed
environment where were meeting together, I get
these visible clues from you. When you are on the
phone, you dont have those, you dont have the safety
net of being able to look over. Those Scrum Masters
Page 20
Contents
serving as facilitators and even other members of the
team that are helping with facilitation really have to
pick up some additional skills to be able to effectively
facilitate by phone or to fnd those places where, if you
have cultural differences, really understanding that and
drawing that out and addressing it so that it becomes a
positive experience for everybody on the team.
Those are the kinds of things. Silence on the phone
- how do you deal with that? If you have somebody
whos very verbal - if we are sitting face to face, I can
posture, I can turn my eyes to somebody else and let
you know its somebody elses turn to talk. But if were
on the phone, and in fact there are some phones that
wont allow you to interrupt if somebodys rambling,
how do you deal with these things? Those additional
facilitation skills are really important.
Lets get very specifc here. The phone
is a very basic tool. Can you give a
couple of ideas on how to use the phone
effectively when you are working with a
distributed team?
I sure can. I facilitate meetings all the time. I lead a
lot of different communities and this comes up really
often. But there are some people who will have more
trouble fnding a quiet spot to interject their ideas or
to share their ideas and opinions. It can be hard to
fgure out where to jump in. If you are sitting together,
it becomes more obvious when a pause is about to
happen, and you can ready yourself to be able to
interject your thought. If you are on the phone, the
facilitator needs to make sure that everybody is having
a chance to bring in their ideas or their experiences and
if people are not contributing, that facilitator needs
to open up that space and give that individual the
opportunity to share their thoughts in there.
I think that one of the keys is looking for people who
may have good information to contribute, but are
having trouble fnding that slot time-wise to share
their thoughts. Another one is when somebody is
tending to go on, giving them that pause and saying,
Those are really good. You had some great input
there. Mary may have some thoughts on that. Mary?
Providing that transition, making sure that the
person understands that they were heard, they you
understood what they were saying and at the same
time transitioning over to another person to give
them an opportunity to include their ideas. There are
so many things that we can talk about in that space,
but those are a couple.
We talked about the Scrum Masters
role a little bit previously. How about
the product owner? Does the product
owners role change in a distributed team?
I think it really does. I think fundamentally its the same,
but things like when were going into sprint planning
making sure that if the team has questions there may
be some time delays due to time zones and you want to
make sure that there is enough time for them to follow
up with stakeholders and bring the information back to
the team. The product owner may be in a different time
zone than where the team is, so there is doing some sprint
preplanning, making sure that you get the input that you
need so that the product owner can prioritize that backlog
and get it into good condition for sprint planning.
That may be a longer process, just because of the
different time zones. From a distributed perspective
you just have to recognize that there may be those
delays and expect that in how youre addressing things
like sprint planning. Then, of course we get to the part
where identifying who the stakeholders are going to be
for our demos, where you get into that whole question
of Are they a time zone that is going to be comfortable
for the team? or How do we need to schedule that?,
so those kind of things. Its a little bit different than just
walking over to somebodys offce or expecting that
theyre going to be available during certain times.
There are certain ritual meetings that
happen in Scrum, the demo being
one of those. Are there changes that
happen to those meetings that need
to be incorporated into your plans
for a distributed team? For example
doing the demo online perhaps or
something like that. Can you think of
any differences?
Thats one. The other thing, we havent talked too
much about this, but there may also be when we
start getting into a distributed situation, we also start
getting into some of the language situations and the
cultural differences as well. But were previously
maybe looking at lets have the person that developed
this piece or the person that was primarily responsible
or some key contributor to this particular piece
demonstrated this piece. Now we have the question
about the language skills: is it comfortable for this
person to be able to present? If not, what do we
need to do differently in order to be able to have an
effective demo? Thats one example.
Contents
And always, by all of these, the question too is
meeting times. Then, probably the third one that
Ive mentioned is network latency and performance.
Because you want to make sure that you have
reasonable performance to be able to properly
demonstrate what you are trying to demonstrate.
I have seen teams very effectively do captures of a
demo and made those available for downloads so that
its very obvious what it really looks like without some
horrible choppiness or diffculty getting to a server or
whatever the issue might be.
We talked a lot about the disadvantages
of distributed teams. Are there any
advantages that distributed teams have
over co-located teams that we should
know about?
Yes. I think the biggest is - and I mentioned this earlier
- is that you are not bound by how close amazing
talent is to you. Thats my favorite. Regardless of
where somebody sits, you can have access to that
persons amazing creativity and talent and experience
and expertise. I think that will make your products
better. I think it makes really anything that youre
doing better because you have access to skills that you
otherwise might not have. So, for me thats my absolute
favorite of working with distributed teams. The other
thing is that, besides the experience and the expertise
and all of that, its the perspective.
When you are looking at working with people like we
do, from different backgrounds, from different parts
of the business, different parts of the world, there is a
richness and perspective that either adds to the ability
to be really innovative, that if you are always working
with the people that are just like you, you dont have
access to that. From a competitive perspective, I think
you kind of want to have that sort of access to that
richness and expertise and experience.
Bio
Elizabeth Woodward is a senior software consultant
with IBM Quality Software Engineering under the
Corporate Headquarters Offce of Innovation and
Technology. She has served as the project manager
or development leader on more than 100 projects for
IBM and other development companies. She coaches
distributed software development teams to improve
the effectiveness of their development practices.
THE ANNUAL
INTERNATIONAL
SOFTWARE
DEVELOPMENT
CONFERENCE
SOFTWARE IS CHANGING THE WORLD
AND HERE ARE THE DATES:
qconferences.com
for more info go to
QCon Shanghai 2013
November 1-3, 2013
QCon San Francisco 2013
November 11 - 15, 2013
QCon Shenzhen 2014
January 9-11, 2014
QCon London 2014
March 3-7, 2014
QCon So Paulo 2014
April 9-11, 2014
QCon Tokyo 2014
April, 2014
QCon Beijing 2014
April 17-19, 2014
QCon New York 2014
June 9-13, 2014
QCon Chengdu 2014
July 17-19, 2014
QCon Shanghai 2014
October 16-18, 2014
QCon San Francisco 2014
November 03 - 07, 2014
READ THIS ARTICLE ONLINE ON InfoQ
http://www.infoq.com/interviews/elizabeth-woodward-scrum
Page 22
Contents
Jean Tabaka on Team Collaboration
and RAPID Management
Interview with Jean Tabaka by Deborah Hartmann Preuss
Im here with Jean Tabaka, the author
of Collaboration Explained: Facilitation
Skills for Software Project Leaders.
Jean, could you tell us something about
yourself?
I have been in the software industry for over 25 years.
I started out as a programmer, eons ago, with the
punch cards, etc. Back in those days and even through
my life as a consultant, I never had contact with
customers, and I did a lot of my work sitting by myself
and receiving tasks instructions from my project
manager. And at some point around 2000 or so, I was
touching into the Agile world and realized that I felt
completely fipped on my ear, and it felt good. And
what I started paying attention to what was that my
passions were moving a little bit from writing code to
more about what sits around writing code.
I was part of a book on physical database design for
Sybase Sequel Server, believe it or not, and that is
when I really started caring about what it takes to
actually do work versus specifcally doing the work.
So my work with and being a programmer, and then
touching into Agile all around this methodological
view, led me to caring about facilitated, highly
collaborative, decision-making. I came into this
work of caring about collaboration from being a
programmer and watching what happens when you
have really facilitated and collaborative environments,
so that became something so important to me that
I wrote a book that came out in January 2006 in the
Agile Software Development Series, for Addison-
Wesley, called Collaboration Explained. The whole
time I was writing it, I thought, I really care about this.
I dont know if anyone else will, but I will write it down
and see what happens. So the book came out.
You have written about and you are
thinking about teams and collaboration.
Is that where your focus is right now?
I am doing a lot of work with teams and the book
really gave me some sort of life force around moving
into OK, let me go and work with teams more and
more around collaboration and see if the things that
I brought into the book really have legs, if they really
stand. It still amazes me in this day and age the
number of command-and-control environments I go
into, and what I have to do to help people believe in a
different way of doing things.
Two very odd discoveries have come to me while
I have been talking about collaboration and how
important it is. One is that I am discovering that there
are people who actually, on teams, dont want to
make decisions, and the new Agile coaches or Scrum
Masters are coming to me and saying, Ive got people
who dont want to make decisions. So thats one very
odd situation. I had no idea that happened.
The other one is that I am discovering in the work I do
with product owners that they are actually learning
that decision-making for them is becoming very
complex in that they have to be collaborative and
negotiating with the team when they are planning
their iterations or their sprints. And yet, behind the
scenes, they have to have reliable, effective tools for
coming up with their backlog, their ordering, their
ranking and their priorities. And this is actually a new
world for them - it is a brave new world! I now actually
go into groups and talk about these. I think the
hardest job in Agile is being the product owner and it
is all this decision making.
The frst point that you mentioned was
team members whod rather not make
decisions. Can you tell me more about that?
Yes, unbelievable to me. We were moving into an
Agile approach, thinking that people would just fall
Page 23
Contents
over themselves thinking, I fnally get to own my
task, I fnally get to own my estimates; I get to decide
which things I am working on, based on my expertise,
my availability, etc. I have run into teams across the
world, across cultures where brand new Agile project
managers or Scrum Masters would come to me and
say, Jean, we have the complete opposite problem.
We have people who will not self-assign, who will not
decide the tasks or decide the estimates or assign
themselves tasks - pick up tasks.
When you ask them to do that is it
anxiety-producing?
Apparently so. I was with a group, just a week or two
ago, where the project manager said, What do we
do, Jean? People are not self-assigning. They refuse
to decide the tasks. Dont I have to at that point just
go ahead and decide for them? I said, No, and he
said, Then what do I do? I said, You stand there
with patience and conviction that they own these
decisions. He said, Well, how long do I stand there?
I mean it came down to that, and I said, I can
stand someplace for a minute and it can be very
uncomfortable for the people, but the minute lets
them know I really am serving to you, I really am
turning this over to you and then, if the team still
feels they cant step up there is something deeper
going on. That is when I actually counsel project
managers that they have to stop and do what I call a
mini-retrospective. So we need to stop right here and
fnd out what is it that is pulling you away, feeling not
safe enough and making you not have enough trust in
the environment, that you feel you cannot step up and
make a decision and take ownership of something.
What kind of things do you fnd?
And how do you help them?
I have discovered that retrospectives are an amazing
tool for managing these situations. So what is
underlying a teams refusal to commit, refusal to
make decisions or for any individual in the team to
self-assign, is that there is something deeper going
on. As a retrospective facilitator, I make a very safe
environment and fnd out things like Our architect
or our technical leader has always made the decisions
and we get mocked if we do something wrong. We
are afraid of being mocked. We are afraid of getting
it wrong, so wed rather have someone else make the
decision.
Or, I have also found that they are used to not making
the decision because then they dont have to be held
accountable. So we have to end up talking about
the safety of making a decision wrong, and that is
OK, because we are on short iterations and we are
amplifying learning about our decisions and also the
safety of taking on ownership; that actually the fact
that you are taking on ownership is in service to the
team and it is not about someone looking at you like
How could have you possibly done that?
So the retrospective at the end of every iteration is
important and then, even when I go in and just fnd
out that this is occurring with teams, I stop and have a
retrospective. I was with a group of programmers who
were fresh out of university and they said, We dont
know what a task would be. We have never done this
before, so we need help. Again it is necessary to dig
under the covers, to fnd out. The project manager
should not step back into a command-and-control
mode of decision-making, but should rather move into
this mentoring role, and helping the individuals make
the decision so that they gain more and more a sense
of what the right things are to do, and not just have
someone else decide it for them.
Your second point about a surprise
that you had, while you have been
processing all this information about
collaboration, is that product owners, as
decision makers, really face challenges
with these Agile teams.
Yes. Again, my background is computer science so
here I am now, working Agile and helping mentor
Agile teams and discovering that the product owners
are raising their hands and saying, This is good,
here in our iteration or sprint planning meetings,
I get it. What do I do outside the meeting? I have
stakeholders, I have user communities, I have
conficting priorities of other product owners; we are
fghting with one another for resources.
And here is one example I had in particular which just
surprised me so much that I was startled: I was with
a group of people trying to help them think about
release-planning and iteration-planning, about 30
people with this one organization and I said, Now,
who is the product owner? and the people in the
room pointed at this one woman and said, She is
the product owner, and she said No, I am not. I will
not be the product owner on this project. Delving
in and fnding out what was the truth underneath
Page 24
Contents
all that, I found out that it was extremely dangerous
in this organization to step up and say, Ill own the
decision, because there were so many conficting
stakeholders. Some of the work I have been doing
was to try to learn a little more about product owners
and decision-making, so that when they come in to an
iteration-planning meeting, they are very clear about
the ranking of what should be happening and what
they would like as value delivery, to know where is the
value defnition in priority.
They need to know that: the value and
the priority, before they come into
the meeting, dont they? And the frst
couple of iterations, say, have it then it
starts to slip, doesnt it?
Yes, it does. The frst couple of iterations, they still
have got a lot of nice documentation that they had
built up coming in, and then, it is somewhere around
the fourth iteration where they fnd out that Oh,
God, I am falling behind the development team and
I dont know what I am supposed to be doing with
all these people barking in my ears about priorities,
because we didnt use to worry about priorities when
we built projects. We threw everything into the kettle
and said It will all come out eventually. Now they
have to learn Yes, I will listen and yes, that can be
part of the soup, but these are the priorities.
What happens to a team when the
product owner becomes less and
less effective at bringing them solid
decisions?
Some of the symptoms I have seen have been that
the product owners show up at the sprint /iteration
planning meeting and they actually dont have
information rich enough for the programmers and
testers, the entire delivery team, to build what they
think are useful tasks and estimates, items that they
really feel they can stand up and commit to. And so
the commitment to tasks and estimates starts to
erode over time because they are being asked to
commit, and yet, there is not enough information
sitting and being carried in and brought in to the
meeting. The product owner has some sense of what
he wants but the team now is watching their morale
go down, because they are still being asked to commit,
they are learning how to be faster, but the product
owners information is not staying in a fow with them.
Does it affect their estimates? Does it
affect their willingness, their ability to
commit?
It affects all those. It affects the estimates with regard
to the fact that they know less and less what should
be delivered in this time box. There is not enough
information, so then it affects their confdence in
the process, it affects their morale and it affects the
whole thing that I call the rhythm of value delivery.
The rhythm starts to fall off and we see it getting
choppy; it has a lot of turbulence in it. And when teams
feel that chop and turbulence, that is a classic symptom
that the product owner has not been able to really
come into the meeting ready with the juicy useful
information to help the team commit to its work.
Have you found tools that can help
product owners prepare so that they
really can serve the teams well?
There are a couple of things I have been working
on. One of them is that Agile methodologies seem
to focus primarily on programmers and the delivery
team, the development team. If I look at Lean - a lot
of Lean principles are guiding me in making decisions
about Agile practices - there is in the Lean principles
a notion of fow and rhythm, and a term I used earlier,
turbulence and non-turbulence, smooth fow. What
I realized was that product owners actually need
some very similar guidance about fow, so teams are
supposed to be engaged in smooth fow of value.
So, I am learning that I have to go in and talk with
product owners to create teams that gather useful
information in priority order, so that they have
smooth fow of value defnition. That is one of the
things I am doing: really working with them about
their own fow of meetings, their own fow of the work
that they do and the teams they do it with. That leads
to my second item, which is how do they pull together
potentially conficting, fghting, competing priorities,
organizations, business units - how they pull them
together to show up with one prioritized backlog for
the planning meeting. And this is some stuff I have
read in the Harvard Business Review.
What did you discover in the Harvard
Business Review that gave you insight
into how to help the product owners?
First of all, what gave me insight about was that I
needed to look outside of the Agile books and really
look at business and things that business is paying
Page 25
Contents
attention to about decision-making. This was in the
January 2006 Harvard Business Review, dedicated
entirely to decision-making for business owners,
executives, etc. In one article about evidence-based
management, the authors went into the use of a
model called RAPID, and they said that they found it
very effective for businesses to very explicitly decide
the roles that are involved in effective decision-
making models.
RAPID, I guess, is an acronym; what
does it stand for?
RAPID is an acronym of the fve roles that - these
people believe - need to be very explicitly articulated
and defned before business moves into decision
making. Each of the letters of RAPID is one of the fve
roles that a group needs to agree upon when they go
into decision making.
Tell us about the fve roles that make up
RAPID.
There is R which is the recommender think about
the product owners as having to be someone who
pays attention to lots of recommendations coming
in, so there is the recommender role. Recommenders
in Agile need to pay attention to the fact that they
better have scooped up good information about their
idea, and yet, they dont own the decision because
that is the D all the way at the end of the RAPID
acronym. So a recommender can bring information
in, but they are fully cognizant of the fact that they do
not own the decision.
A is an agreer. This is some who has, lets say,
subject-matter expertise and can actually hold a veto
to a decision, so there is a decider, but think about
a product owner in an Agile organization who has
executive sponsors or who has very trusted advisors.
I think they would fall into that agreer role.
The P in RAPID is the actual performers. Once a
decision has been taken - think about the delivery
team showing up at the planning meeting decisions
have been made about the priorities, negotiations
have been held with architecture, with various user
communities, with competing product teams, that
have led to this moment of this planning meeting for
this one group, that says, These are the decisions of
the order and now you, as delivery team, we are going
to take on the decisions and decide the work. So that
is the performer role.
The developer, or the doer, actually
has a role within this RAPID approach,
which at frst I thought you are going to
talk only about something that happens
in the product group, but there is a
crossover to development.
There is, in fact. I can see them showing up in three
areas: you can think of a developer even being a
recommender, there will be a performer for sure
because they are delivering I refer to the value that
has been ranked so they are defnitely in the P
role, the performer. But development and technical
individuals on teams can be recommenders in what
should be in the product backlog. I think they can be
recommenders in two approaches, so I will say that
a developer can show up and be a recommender, can
be clearly a performer and then there is a third role,
which is the I- input. When I am mentoring brand-
new teams, I talk with the product owners about the
fact that they indeed own the product backlog, they
own the priority of what they want delivered, but it
would be criminal and negligent, at the very least, to
make these rankings without getting input, without
discovering useful information or recommendations.
So I very often talk about the fact that, as you are
prioritizing, when you have your smooth fow of
meetings about making your decisions you should be
getting technical input. So a developer could also be
in the I role the input role. Then fnally there is the
D, which is the decider.
Who is the decider?
Who gets to make the decision?
Well, gets to and has to - its a double-edged sword.
The decider is, in our Agile world, the product owner,
the person who owns the money, who owns the
belief and the conviction around the value, is the
ultimate arbiter, the ultimate decider, and that is so
important for that person to recognize, I own the
decision, but I have recommenders, I have agreers,
I have performers, I have input, and so I wont
make decisions in a vacuum, in a silo, without any
information.
So the decider doesnt feel so much like
he has been hung out in the wind?
No, hopefully not. To go back to my example, I was
in this large group and this one woman would not,
although everyone was pointing at her, be the product
owner. So I wish I had these tools back when I was
talking with this woman, because I would have wanted
Page 26
Contents
to say, OK, lets stop and fnd out. Pull your business
community together and lets have explicit discussions
about who are the recommenders, who are the
agreers, who are the performers and then who are
the people who represent the input. And when you
have all this alignment and understanding, you are
explicit: names are put with these things. Then being
the decider shouldnt make you feel left alone and
hung out in the wind. There really is this model that
we have all signed up to, about the importance of
having one decider.
Is this foolproof?
Actually, one of the good pieces of information I got
in the article was that there are two major roadblocks
to having beneft derived from adopting this model.
The frst one that they mentioned was, in fact, the
one that I had run into, where there was no decision
maker so no one would stand up and say, I will own
the decision, I will own the value defnition, the value
proposition. The other roadblock, which I have seen
too many times in my life, is that there are too many
deciders. So there has not been an explicit recognition
of who will ultimately own the decision. This is a
tricky slippery slope because it can start to look like
command and control.
As we are in the Agile world, as we are working with
collaborative teams and wanting participation in all
these different new ways, and then trying to help
product teams do the same, paying attention to your
decision modes is so important, because for me, in
my passion, the easy fall back is command and control
and I just dont want that to happen.
In 2006, you were thinking about teams
and collaboration and leadership inside
the self-organizing team, and now
you are realizing that there is another
bottleneck outside which is in the
product-order domain, so where do you
go from here?
Its a wonderful journey of watching collaborative
teams and helping them with becoming more and
more participatory in all the work around that, and
then discovering the poor product owners are sitting
out there, trying to fgure out how to get their things
done. Im becoming more and more passionate,
at this point actually reaching back into the real
fundamentals of Lean - the notions of fow and pull
and innovate.
To me, those sit out around and cradle and hold the
whole Agile movement; they help me understand
the business imperative around Agile: smooth fow
of value, the ability to pull value, and to have the
business be a truly innovative business. My work
with collaborative teams has helped me see what
is happening with the poor product owners. I want
to help them and that means that, once we have
all of that in smooth fow, I really want to watch,
organizationally, how we have decision-making that
responds to change, invites change and then drives
change. To me, that is when the decision-making is
really working.
Bio
Jean Tabaka is an Agile coach with Rally Software
Development in Boulder, Colo. Jean is a Certifed
Scrum Master and Practitioner, a Certifed Scrum
Master Trainer, and a Certifed Professional
Facilitator. She holds a Masters in Computer Science
from Johns Hopkins University and is the author
of Collaboration Explained: Facilitation Skills for
Software Project Leaders.
READ THIS ARTICLE ONLINE ON InfoQ
http://www.infoq.com/interviews/Agile-Jean-Tabaka
Page 27
Contents
Linda Rising: Prejudices Can Alter
Team Work
Interview with Linda Rising by Amr Elssamadisy
We are here at Agile 2008 with Linda
Rising. Thank you for joining us, Linda.
For those of us who dont know you,
can you tell us a little bit about yourself,
please?
Ill be happy to do that. I live in Phoenix, Arizona,
where the temperature now is about 113 F, so I am
very happy to be in Vancouver. Im an independent
consultant. Ive been working independently; Ive run
my own company since about 1999. Im interested in
patterns, in retrospectives process and how change
happens, and recently, for some strange reason, Ive
developed an intense interest in how the brain works,
how people solve problems and how they look at
the world. That has led me to cognitive science and
evolutionary biology and even remote interest in
other primates. I mean - we are primates, of course -
apes and monkeys.
You are interested in cognitive
psychology and I believe your talk this
year at Agile 2008 was one of the series
on that subject. Can you tell us a little
more about it, please?
This was the third in a series of weird talks that Ive
been very privileged to give at the Agile Conference.
Every year I submit, every year I wonder, Well,
will they take a chance on me? Will they let me give
another in the series of weird talks? So far, so good
and it seems to be OK. They seem to be well received,
people seem to be interested, so maybe these are
good ideas.
What are you on to?
I am looking for the connection between what
cognitive scientists and evolutionary biologists are
telling us about the way we have evolved to be and
what that means for Agile software development. I
am a believer - I believe it is sort of a religion, in a way.
You have to have faith that it will work, and those of
us who are enthusiastic are a bit evangelical about
Agile software development, so I believe there must
be connections to the way we are. I believe there must
be some hardwiring that makes it all work, and I am
happy when I fnd those connections and its possible
that others are happy to fnd that connection as well.
Can you tell us a little bit about these
connections and specifcally what
connection where you talking about
this time?
This time I was looking at stereotyping. The title of
the talk was Who do you trust?, and the abstract
tried to explain what I meant by that by saying that we
are hardwired to be very judgmental. We categorize
people all day long, based on sometimes the most
trivial characteristics. I think most of us are pretty
familiar with stereotyping in terms of race, religion,
sex, height, the color of your hair or the lack thereof,
but most of us dont think about some of the trivial
stereotyping that we do and we are totally unaware of
it and we are not even sure that we are doing it or why
we are doing it. Maybe its just because you remind
me of someone that Ive forgotten, but that was a
good experience or a bad experience, and so I am
immediately biased in your favor or not and then that
becomes a stereotype for me and all my interactions
with you. Everyone does it. We do it all the time and
the second part of that is that we do it unconsciously,
so we dont think we do it.
Once weve done that, those stereotypes become
self-fulflling prophecies and thats the bad part. I
was talking to a manager about the talk, before I
gave it; he wanted to know a little bit more about the
subject. When I explained it to him he said, Of course,
Page 28
Contents
managers do that. I know that we do that when we
interview, we hire, when we move people around,
when we promote or not, its because weve made a
very quick decision about someone and someones
ability to do the job they are asked to do. And I said,
Well, then you agree, and he said, Yes, but thats
not a bad thing, because we are always right. They
[managers] are always right! And I felt, Of course
they are!
So managers, by stereotyping, are
always right and of course they are?
Of course they are, because suppose someone hires
me and they believe that I have certain qualifcations,
but that I have certain defciencies. Now, when they
look at my performance, what do they see? They see
what they want to see, based on that stereotype.
In fact there have been experiments that show the
same behavior can be evidenced by someone whos
considered competent and someone whos considered
incompetent, but what a manager - remember, we all
do this - does is say, if this is a good behavior, Well,
of course this is a smart person. Yes, thats what I
expect. If its an atypical thing, if its a stupid behavior,
the manager will explain it away: Linda must be
having a bad day. So it doesnt matter - you know we
talked about reality - what really is out there; well
distort it to ft our stereotype.
Our beliefs, our stereotypes are
unconscious and they affect how we
see the world, so thats why managers
are always right. Are we really that
naive about who we are?
I think it is kind of scary. We have an image of
ourselves as carrying around a little video camera in
our heads and that we take pictures of whats really
there. We record the sounds that are really out there,
and what we get is a little tape that we can store in a
library and we can refer to it whenever we need to
and we call that memory. We think that thats an
accurate representation of the event. I once talked
to a couple who were having diffculties celebrating
a signifcant anniversary. And the argument was
between the husbands and the wifes memories of
how they met, because those memories were very
different. The wife was very upset because she said,
That was an important day for us and he doesnt
even remember! and so she recounted the way it
really happened. Of course, his memory is completely
different and she interpreted that as it wasnt the
same for him, it wasnt as important to him, Maybe he
doesnt really love me.
In reality, his picture of that time is just as real as hers
and if we went back, if that was possible for us to time-
travel, wed fnd that both of those memories were
distortions and that each had interpreted everything
that happened: time of day, what they were wearing,
what he said, what she said - neither picture is
accurate. Over time, they bring those memories out
and they re-examine them and every time they do
they change it just a little bit so that, after 20 years,
its not even close. Its nothing to get upset about; its a
natural, normal thing. We all do it, but we live with the
delusion that that memory is accurate.
Memory isnt accurate?
No. You wouldnt want to be in front of a jury that
was listening to an eyewitness account, someone
saying, Yes, this is the guy who killed or robbed or
committed whatever the crime was. I remember it so
clearly. I can identify this individual, I can pick him up
from a lineup. I dont think so!
There have been experiments. I know
that cognitive psychology in general is
an experimental science.
It is an experimental science, but, as my husband
says, the reason why I am interested in it now is it is
becoming a hard science, because we can take MRIs
of the brain and we can actually look at what part of
the brain lights up, lets say, in an interview. What part
of my brain is working right now? Am I afraid? Am
I happy? Am I sad? Youd be able to get an accurate
representation, no matter what I said, because you
know I might not even know how I feel.
So this is really accurate stuff?
Its becoming more accurate. I think the way we
characterize the feld is that its exploding, which is
why its so exciting. Its very diffcult to keep up with it
and Im not an expert in the area, but I do try to read
abstracts of all the latest published material. Just
even looking at abstracts is an enormous amount of
work, let alone trying to track down those articles
and see Do they have anything for me and my special
interest? Its just amazing what we are learning, very
exciting.
We do the stereotyping, we do the judging. I began
the talk with a story thats really an experiment. It
was an experiment that happened in the 50s, so its
Page 29
Contents
a classic. Its an experiment thats been recounted
numerous times. Every beginning psychology student
knows about this experiment. It has to do with some
boys who lived in Oklahoma. They were all 11 years
old, with similar backgrounds, and they were loaded
onto two separate buses and hauled off to a Boy
Scout camp in Robbers Cave State Park in Oklahoma.
The experiment was being run by a fellow named
Shariff who was brilliant. He was very innovative and
he was interested in the kinds of things weve been
talking about: stereotyping, how that affects how we
get along, how that could be manipulated.
So the two groups of boys were put in two separate
parts of the camp. During the frst week, they were
just allowed to be boys and bond, and have fun
together. And what happened in that situation was
they began to develop an identity: one group became
the Eagles - that was their name, they chose it - and
the other group was the Rattlers. By the end of the
week they were a team; they had their own special
rituals, their songs, their secret signs, the Rattler way,
the Eagle way and they did it all on their own, without
any coaching. This is what we do when we hang out
with a bunch of others, we sort of say we become
an us. By the end of the week, that was pretty well
established. The goal of the research for the frst
week was How quickly can that happen? and that
happens pretty quickly.
Step 1: Form the group.
Step 2
There was some manipulation on the part of the camp
counselors who were also researchers. They began
to make the two groups aware of each other, just by
bringing them close enough so that they could hear
each other. What happened was each group began
to be aggressive and antagonistic even though they
hadnt seen each other. They began to call the other
group names based on racial characteristics - so some
bad words - even though they hadnt seen the others.
Those people are intruding on our space. They must
be stupid, incompetent. Lots of other bad names.
And it happened very quickly. Then they introduced
the two groups and they were already feeling pretty
aggressive toward each other and they forced them
to eat in the same mess hall and they sat on different
sides of the room, threw food at one another - you
can imagine, they were 11-year-old boys. They set
up some competitive games: baseball, tugs of war,
etc. They were always in competition, the Eagles vs.
the Rattlers. By the end of that second week, they
were raiding one anothers cabins, throwing rocks,
burning each others fags. So things have gotten to
almost outright war by the end of this second week,
encouraged by the researchers, of course.
They wanted them to compete - Who is better?
We are better than they are! They are the ones who
intruded on our space. We were here frst!
So Phase 2: all-out war! It didnt take very long. So, it
didnt take very long to form the two groups, it didnt
take very long to have war between two groups
of very similar boys, all of similar age with similar
backgrounds, similar religion, all middle class, all
white, but they were ready to kill each other.
Phase 3: Can we bring them together? So they
started showing movies in the mess hall. Maybe
enjoying the same kinds of things: Lets all go
swimming together, no competition anymore. They
stopped the competitive games. They tried lots of fun
activities: Lets all have fun together! It didnt work.
The two groups still hated each other, still the Rattlers
and the Eagles. So lets take a break for a minute
and well leave them there, pondering us, because
what they didnt know at the time - this was a very
innovative experiment - is what weve already talked
about: we are just hardwired to do this, even small
children, just as they are learning to talk, so that they
can tell you about it.
They are already dividing the world up into us and
them, based on obvious characteristics, based on
trivial characteristics, and they are already saying
disparaging things. Thats when they frst learn to use
bad words to talk about other people, just when they
are talking to others - them. These 11-year-old boys
have probably been doing it all their lives. They were
hardwired to do it. The psychologists didnt realize
what they were up against. So it was discouraging,
I think for them, to see how quickly they became
aggressive and it didnt seem like it was going to be so
easy to bring them together. What did they do? They
said, Well, this is an experiment so they decided that
they would create a project that required the input
and the talent of everybody.
No one team could do it alone?
No one team could do it alone, and something that
they all cared about, something for which you could
Page 30
Contents
say the Eagles and the Rattlers would have a shared
goal, shared vision, it affected them all. The frst thing
they did was they caused a problem in the water line.
It was about one and a half kilometers. They said, I
dont know why, but suddenly the water supply has
been cut off and we need all of you to help us inspect
the water line. We all have to do this, because its
too big for any one group, certainly too much for the
counselors. We all have to spread out. We all have
to look at whats going on here - see if we could fnd
this problem. They all set to work about it and they
noticed immediately that, all of a sudden, it wasnt
Rattlers over there, Eagles over here. They all just
jumped to it.
A shared goal thats bigger than either
of the two teams and something
important to them, not just a shared
goal that was given, something that
they cared about.
Yes. And that nobody knew how they were going to
solve this. The counselors, who were also researchers,
didnt know. They just said, This is a problem. We
are in trouble. We have no water. If we cant solve
this, well have to go home and this will be the end
of your time here. So what are we going to do? And
all the boys immediately jumped to it. It took them a
while, but they found the problem and when they did,
they all celebrated. It wasnt the Eagles said, Yes, the
Eagles did it and the Rattlers said, No, the Rattlers
did it. It wasnt any fghting, any taking credit. It was
We all did this.
This is beginning to sound familiar.
It was a turning point. The researchers thought,
Were on to something. Can we do that again? What
would happen if we did it again? So, the truck that
brought in supplies, including food, suddenly broke
down the next day. They couldnt get it out. It was
stuck in the mud, caught behind some trees. They
didnt have any equipment, so they said to them,
Boys, you know we solved that other problem. What
are we going to do about this? Do you think we could
all together pull this truck out? It is a really big truck
and youre just little kids, what do you think? Yes,
we can do it. Lets get some ropes! and together they
started to work on the problem. Nobody told them
what to do. There were ropes there available, they
just jumped on it and they did it together. It was their
food and they all celebrated together.
So you bring up the celebration in the
end - signifcant?
Yes, I think so. Its the time for recognition of What
we did and how important it was that we were all
together working on this. And we couldnt have done
it with just the Eagles or the Rattlers - we all had to be
there. We dont even know who solved it, we all did it.
It wasnt even a matter of I did this and you did that.
It was We did it. Nobody ever said, Our team was
the strongest/the biggest/the smartest. There were
a series of those little experiments or projects and by
the end of the week they were sitting together in the
mess hall, talking about You know, that was really
tough, we were all in that truck and we all had to get
out. You know, 11-year-old boys just talking about
what they had done.
The last thing they did was decide maybe they would
have a movie together but there wasnt enough
budget, couldnt afford it at that time, in the 50s. He
had to go rent that movie: It would have been fun
to have a movie. What can we do? We should go out
and buy one. Any ideas? And all the boys said, Well
all chip in! Everybody put 50 cents on the table, so
together they paid for Treasure Island and they all
watched it together.
This is the same group that, when they
tried to get them to swim together
before or watch a movie together, they
wouldnt do it?
Didnt want to do it. Now they sat together, had
popcorn, watched Treasure Island. The next morning,
when they packed up and were ready to go back
home, they had all gotten on the bus and they didnt
sit Eagles/Rattlers. They just got on the bus and on
the way back, they sang some Eagle songs, some
Rattler songs but it was mostly about all the things
we did. It was a turning point. That story has been
repeated, there have been lots of other experiments
because the frst objection to it was But these boys
were similar - all 11, all white, all Protestant, similar
backgrounds. What would happen if you really tried
to mix it up? So there was a follow-on done in the 60s
in Beirut, little boys, 12 years old this time, Christians
and Muslims - a lot of tension at that time in Lebanon.
15. Tensions between Muslims and Christians in
Lebanon have always been tense.
Yes. So, Phase 1 - divide them up into two teams.
These groups were Red and Blue. In one week they
were ready to go. But when they started making the
Page 31
Contents
two groups aware of each other, things got out of
hand. One small band broke into the kitchen, stole
some knives and went after a member of the other
group. When you frst hear about that, you think OK,
maybe there is no way to trump some really serious
religious differences, because almost all the boys had
been either part of or spent some time in a religious
school, so it wasnt just like I go to church on Sunday
occasionally. This was serious business.
16. And in Middle East, religion is part of their lives.
The teams were Muslims and Christians, but what I
forgot to mention was that each team had the same
number of Muslims and Christians. Its not what you
expected, is it? So each team was half Muslim, half
Christians. And the ones whove broken to the kitchen
and stole the knives were all Christians and the guy
they went after also Christian.
You caught us all with stereotypes,
didnt you?
Yes. Group trumps religion. The loyalties within those
two groups were stronger. The Christians were going
after the Christians because it was Red against Blue.
Us against them in that particular case was not
about religion, it was about We have spent a week
together swimming and having fun and the people in
this group are now more important to me than the
people who are in my religious us. So there have
been variations on that with political ideology, just
about any kind of severe categorization you can name,
and its always the same: the group trumps the other
category. The category that you would think would
be really deep or more essential is overcome by just
being together in a small group, working with a shared
goal together.
Now, the psychologists have categorized that, called
it collaboration or social interdependence. Groups
that have it work together well because they have a
shared vision, a shared goal and each member of the
group realizes that its not just his/her contribution
that will enable the group to make - it will be all of us
together. What I do really depends on whether you
are able to do what you need to do, and therefore its
incumbent upon me to also help you, to be available
to you, to support you, to do what I can to make your
job possible, and that when we get to the end it will be
because we all contributed, we all did it and then we
celebrate.
Does that sound like an Agile team to you? A real
Agile team - thats the message! Maybe thats the
heart or the essence of Agility - that we allow that
to happen. I started looking at the practices - they
really stand up. All of a sudden we are aware, when
in many teams we are not. We are aware what others
are doing; we become aware of how we might help or
support in some way what someone else is doing, to
enable their success because we know our success
is tied to their success. Pairing. When I sit down with
someone else and I open myself up to say, This guy is
really pretty smart, maybe I didnt realize that, maybe
I had stereotyped him, maybe I had thought He is
all right, but he is black/Hispanic/tall/short/wears
funny clothes/picks his nose or whatever it is, and it
was hard for me to get past that, but sitting with him,
somehow now I see: we are on the same team and it
trumps all of those other things.
So, what the psychologists tell us is that, yes, we are
hardwired to do that; yes, we do it all day long. We
cannot not do it, but when we are in a collaborative
setting, that context trumps those other stereotypes.
Its a way around some natural tendencies. You know,
when we say something like hardwired that was
essential for survival. If we didnt have a group we
wouldnt have made it this far, so its not always a
bad thing. It has enabled us to overcome some pretty
severe obstacles. Thats why we are here today. We
will always probably have that, but now we realize
that whats more important is to work together. Thats
how we can maybe have world peace.
So you are not talking just about Agile
development?
Im not. And of course, I might as well throw in some
primate studies. I wont talk about apes, Ill talk about
monkeys. There are some interesting experiments
that have been done with capucin - very cute little
monkeys. They can be taught to collaborate to haul in
a very heavy framework because it has treats on it.
They start by giving each of the monkeys treats. So
two monkeys work together and they pull in a very
heavy framework, because neither monkey can do it
alone.
Then they get to have the treats - the apples and
oranges. Thats good, but suppose we take away the
treats for one of the monkeys. Now, its still important
that they both pull in the heavy framework, but there
is only a treat available for one of them. What will
happen? Will we still get collaboration? What will
Page 32
Contents
happen with the treat? What they learned was that
yes, they will both collaborate and when the monkey
that gets the treats, gets the treats, hell go over and
sit by the other one who helped him and hell share.
So they still collaborate? And the
monkey somehow realizes that its in his
self interest to share?
We cant interview him, so we dont know what he is
thinking. Maybe its to his best interest in the future.
He thinks This could happen again. If I dont share
maybe he wont help me. Maybe he is thankful,
maybe he knows that gratitude is the way to a long
and healthy life. But whatever the reason, monkeys
do it and there is a close connection. When you see
that behavior in primates other than ourselves it sort
of gives us a sense that Yes, this must make sense for
us to do this. It must make sense for us to collaborate.
Some monkeys are better at this than others.
For instance, the stump-tails are very collaborative
and they are not as friendly as the bonobos, but
they spend a lot of time grooming and a lot of time
just being together, whereas the rhesus monkeys
are just nasty and they fght a lot and they are very
aggressive. They dont do a lot of grooming. They
are strictly hierarchical. So they are a little like the
chimpanzee model. What theyve never done with the
chimpanzees and the bonobos is to put them together
to see which one would win out. Is it possible that one
could teach the other about a better way?
They are awfully strong, chimps and bonobos. I would
be afraid. I mean they could kill each other. It would
be risky. They actually did an experiment: they took
a collection of little rhesus monkeys and a collection
of little stump-tails and they put them together in the
same cage.
Are the rhesus monkeys the aggressive
ones and the others very collaborative?
Yes. At frst they stayed on either side, they didnt
really interact too much. But over time, the rhesus
came over and they were going to attack because
they are so aggressive. So they tried to attack the
stump-tails and the stump-tails either ignored them or
started grooming them. The stump-tails had no tails,
hence the name, and the rhesus had long, beautiful,
black, soft tails. So the rhesus monkeys dont spend
much time grooming, but the stump tails loved
grooming the rhesus monkeys because they loved
playing with those tails.
After a while, the rhesus got to like that and they
thought, This could be a good time. So the rhesus
monkeys started grooming, they stopped being so
aggressive, they all began to eat together and sleep in a
little pile together, stopped biting one another, stopped
arguing over who had what. It took a few months and
when they separated them, the rhesus were still less
aggressive, even when they went back. I hate to say
that world peace hangs on something like a monkeys
tail, but I fnd that it gives me reason for hope.
Linda, this is a very strong message,
but how have people reacted to this
message when listening to it and trying
to think how to apply it to their Agile
teams?
If you had asked me that question before I came here,
I would have had one answer, which is I have no idea.
And it could be that this is just too weird and it may be
that Ive gone too far. I wondered about the bonobo
and the chimpanzee talk before I gave it. I thought,
Maybe Im going too far, but what I learned from
there was Ill be surprised at what people think.
Since Ive given the talk, which is only been a day and a
half now, so many people have come up to me and said
something like the following: I think you are right,
and you know, I tried that.
I tried actually shifting my emphasis. I tried to say
All right, Im not going to call them the trouble team
anymore. Im going to go in with something that Michael
Hill said in his talk: Managers rule should be Catch
them doing something good. I heard his talk right
before I gave mine and it caused me to actually change
my talk to address your question, which I couldnt
have done before that. If a manager really has that as
Rule #1, or a consultant, or anyone else who interacts
with the team, think what that does: it causes a shift
in your stereotype because now you are doing what
the manager who hired you, who thought you were
very smart, is doing all the time. Anything you do he
interprets as OK or as something a smart person would
do. His stereotype affects how he sees your behavior.
So, if a manager says, My job is catch them doing
something good, thats what he is looking for. That
shifts the way he interacts with the team, that shifts
his stereotype from trouble to lets fnd all the good
things. We have a pattern in the Fearless Change
Page 33
Contents
book that is called Fear less and it basically says
when someone comes at you with a negative attitude
or a skeptical response to your initiative, one of the
best things to do is acknowledge that to respect it, to
turn it to your advantage in a way just by listening. All
of a sudden, the person feels honored and respected;
it shifts his perspective. The stereotypes that we have
change us and they also change the people that we
interact with.
There was a very famous experiment that was done
with women and mathematics - I feel pretty close
to that: I was a mathematician for a while. There is a
stereotype there: women arent good in mathematics.
They gave a lot of women in various settings a math
test. In some settings they said to the group of
women, Dont forget to check that box. There is a
box at the beginning that has Gender. And that was
enough to lower the score for that group of women a
signifcant number of points, just by reminding them
to check that box. The stereotype not only affects
the behavior of the person who has it, but the person
who is on the receiving end. I know that the world
believes Im not any good at math and my behavior
then conforms to that.
That team knows whether hes saying they are trouble
or whether he is looking for the good. We pick that
up. Then, my behavior is modifed accordingly. If it
can happen because of a subtle thing like checking a
box, that now my score is lower, I do that to myself, I
react to that stereotype. How powerful that is! What
are we doing to whole groups of people? What are
we doing to teams? We think that by calling them
trouble, my behavior toward them doesnt affect
how they are. Thats the startling thing about this.
What you are telling us is, if we are
aware of our stereotypes, we can have
control over them, to some degree. If
we have a positive stereotype, that not
only affects the way that we see things
happen, that actually affects the people
that we work with because, whether we
say it in their face or not, its felt?
Yes, because it changes our behavior. Theyve
actually observed that in a number of research
studies, that looking at the interaction between two
people of either different sexes, different races,
different religions, and people can be just dressed
up. We believe this person is Protestant, Catholic,
Muslim, Jewish and then our behavior changes. That
stereotype that we have - many times we dont realize
we are carrying that around with us - changes our
behavior, which affects our interactions with those
people, which, in turn, changes their behavior and it
just spirals. If we can turn that around by reminding
ourselves to look for the good, I thought What a
powerful thing! Ive heard that so many times, it
never really had this signifcance. Maybe it was just
hearing Michael say that or maybe I was getting ready
for the talk, but I altered my slides to put that in, so
that other people might have the same revelation:
Go in to your teams looking for the good and that
will change your behavior, which will change their
behavior.
Bio
Linda Rising is an independent software consultant
with a background in mathematics and a Ph.D. in
object-based design metrics. A proponent of patterns
and their application in the workplace, Linda and
Mary Lynn Manns are the authors of Fearless Change:
Patterns for Introducing New Ideas, and editor of
Design Patterns in Communications Software, The
Pattern Almanac 2000, and The Patterns Handbook.
READ THIS ARTICLE ONLINE ON InfoQ
http://www.infoq.com/interviews/Prejudices-Linda-Rising
Page 34
Contents
ENGINEERING
CULTURE@
SAN FRANCISCO
NOVEMBER 11-15, 2013
Building an awesome engineering team is challenging. What many engineering leaders dont realize is
that the investments made in spending time defning & developing an awesome culture can become a
massive magnet in attracting better engineers than you ever thought possible. This track explores case-
studies from top engineering teams, small and large, and explains real-world ways that theyve created
an awesome engineering culture. Talks in this track will inspire you to push forward with the tools and
information you need to defne your own unique engineering culture.
SAVE $100 WHEN YOU REGISTER WITH PROMO CODE TEAMCOLLABORATION
ATTENDEES CAN EXPECT TO SEE TALKS LIKE
Scaling engineering culture at Twitter
Growing GitHub to 250
Building a Culture Where Software Projects Get Done
Synergistic Effects: A mixed remote/inhouse team can be better
than the sum of its parts
Lean Apart: A Case Study in Agile UX Design for a Distributed Team
Culture and Tooling in Virtual Teams
The Culture Engine: Exploring the Social Side of Software
Development to Accelerate Team Performance