I couldn't help but notice that people from different cultural backgrounds
seemed to react differently to suddenly finding themselves in a self-organizing Scrum team.
My interpretations are subjective though, and my sample size small, so I did a
bit of research in an attempt to better understand this delicate topic.
It's worth noting that Agile software development practices originated principally in an American cultural setting,
while Lean thinking
originated in a Japanese cultural setting.
Hofstede found that these five dimensions varied considerably
between countries. The United States, for example, rated highest on Individualism,
while Russia and India rated highest on Power Distance.
Japan scored the highest on the Masculinity index.
Russia and Japan have high Uncertainty Avoidance, while Denmark has a low score.
Japan, South Korea and India have a much stronger Long-term Orientation
than Canada, the UK and the USA.
This interesting topic is discussed in greater detail by the Poppendiecks
When it comes to forming effective and harmonious teams, the "cultural frame that we grew up with" is only the tip of the iceberg.
Other factors potentially affecting team effectiveness and harmony include:
They're malleable, and you know that's what I like really, you know.
I don't like people who come here: 'Ooh, we did it this way, we did it that way'.
I just wanna go do it this way. If you like. If you don't...
Team playing--I call it team individuality, it's a new, it's like a management style.
Again guilty, unorthodox, sue me.
-- David Brent (from The Office UK, Series 2, Episode 3)
Steve McConnell lists some characteristics of high-performing teams:
- A shared, elevating vision or goal. This goal, for example, is hardly inspiring: "Create the 3rd-best database product and deliver it in an average amount of time with below average quality".
- A sense of team identity.
- A results-driven structure.
- Competent team members.
- A commitment to the team.
- Mutual trust.
- Interdependence among team members.
- Effective communication.
- A sense of autonomy.
- A sense of empowerment.
- Small team size (less than ten).
- A high level of enjoyment.
and continues to identify team leadership roles:
- Driver. Controls team direction at detailed, tactical level.
- Coordinator. Strategic. Makes best use of human and other resources.
- Originator. Leadership in ideas, innovation and strategies.
- Monitor. Practical problem analysis.
- Implementer. Converts concepts into work procedures.
- Supporter. Emotional leadership. Builds team spirit. Leverages team member's strengths.
- Investigator. Explores and reports on ideas and resources outside the team.
- Finisher. Ensures all necessary work is completed in all details. Maintains group focus and sense of urgency.
De Marco and Lister offer a number of
interesting suggestions for improving team harmony:
- Interview Auditions. When hiring a new team member, the candidate is asked to give a technical presentation to the whole team and the whole team decides whether to hire or not.
- Allow individuals to form their own teams and "bid" for projects. For example, developers who are friends and get along well together could form their own team and bid for a project.
- Encourage teams to develop their own distinctive personality. e.g. IBM's "black team" used to wear all black clothing.
- Give project teams a power of veto over release of a product they feel is not yet ready. Put another way, this is following Philip Crosby's advice of allowing the builder to set the quality standard.
McConnell classifies the different kinds of teams as:
- Problem-resolution. Solve complex, poorly defined problems. People: trustworthy, intelligent, pragmatic.
- Creativity. Explore possibilities and alternatives. People: self-motivated, independent, creative, persistent.
- Tactical-execution. Carry out a well-defined plan. People: sense of urgency, more interested in action than intellectualizing.
and further enumerates various team models you might try:
- Business team. Peer group headed by a technical lead. Can work on all kinds of projects.
- Chief-Programmer team (what Brooks calls a "surgical team"). Improves conceptual integrity and avoids "design by committee". Needs a brilliant individual. Can work ok with creativity and tactical-execution.
- Skunk-works team. Take a group of talented, creative developers and put them in a facility free from the organization's normal bureaucratic restrictions, freeing them to create and innovate. Suitable for creativity.
- Feature team. Cross-functional, empowered team used to develop product. Commonly used at Microsoft (see Dynamics of Software Development by Jim McCarthy). Well-suited to problem-resolution and creativity. Too much overhead for tactical-execution.
- Search-and-Rescue team. Focus on solving a specific problem. Best for problem-resolution.
- SWAT team. High productivity through specialization. Usually permanent teams. Best for tactical-execution.
- Professional Athletic team. Manager clears obstacles and enables developers to work efficiently. Best for tactical-execution.
- Theatre team (like making a movie). Director maintains product vision and assigns people responsibility for individual areas. Producer handles non-technical aspects: funding, schedules, ... Developers audition for, then accept a role. Perhaps best suited to teams dominated by strong personalities.
There is a trade-off between productivity and flexibility: permanent, specialist teams tend to be more productive than generalist teams.
I'm interested to hear of your experiences with different team structures.
Believing that workers will automatically accept organizational goals
is the sign of naive managerial optimism.
The mechanism by which individuals involve themselves in the organization's
objectives is more complex than that. ...
Organizational goals come in for constant scrutiny by the people who work
for the organization, and most of these goals are judged to be awfully
-- Peopleware (p.124)
while cautioning that you're never guaranteed of success,
prefer to use the term "team growing" rather than "team building",
and offer some tips for making your organization more likely
to grow healthy teams:
- Make a cult of quality.
- Provide lots of satisfying closure.
- Build a sense of eliteness.
- Allow and encourage heterogeneity.
- Preserve and protect successful teams.
- Provide strategic but not tactical direction.
Conversely, they further provide a list of "teamicide" mistakes, likely to inhibit the formation of effective teams:
- Defensive management.
- Physical separation.
- Fragmentation of people's time.
- Quality reduction of the product.
- Phony deadlines.
- Clique control.
- Those damn posters and plaques.
Fast, Good, Cheap. Pick any two.
Here Fast refers to the time required to deliver the product,
Good is the quality of the final product,
and Cheap refers to the total cost of designing and building the product.
-- Project Triangle
During my first Scrum planning meeting, the ScrumMaster asked each individual in turn to personally "commit" to achieving the Sprint's goals.
I felt embarrassed by this strange, quasi-religious ritual and insulted by being asked what I perceived to be a low trust question.
Is the ScrumMaster really implying we are not currently contributing our best efforts and will not do so without making this public display of commitment?
Perhaps the word "commitment" frightened me due to my past personal experiences and (male) gender.
Update: I now feel vindicated by a recent "clarification" made in the latest Scrum Update (2011) namely:
"Development Teams do not commit to completing the work planned during a Sprint Planning Meeting".
Moreover, the Sprint goals seemed arbitrary and uninspiring to me, and the deadline phony.
What will happen if we don't deliver those features by that date?
Personally, I'd prefer to be inspired and convinced of the importance of the Sprint's
goals by the passion and enthusiasm of someone who truly understands and believes in the product --
not by a bureaucratic (certified) ScrumMaster following rules recently learnt on a two-day course.
As you might expect, our first Sprint hit some unforeseen difficulties and it was becoming
increasingly clear that we would not meet our committed goals. What to do?
I could work more hours to try to catch up, yet that would break my commitment to
sustainable pace and 40 hour work week. I could cut corners on quality, yet that would
break my commitment to quality and "Definition of Done". Seeing no way out, I asked
the ScrumMaster for advice. He solved the problem simply by removing some features
from the Sprint.
Well, I couldn't see the point of being ceremoniously
asked for commitment if such a commitment could be so easily broken.
I might add that the team worked very hard and made good progress,
but without meeting their commitments due to unforeseen problems and overly optimistic
Despite that, this episode made us feel sad and humiliated because
we'd made a public commitment, then broken it.
A job situation that hurts your self-regard is itself "sick".
-- Peopleware (p.144)
Specialists versus Generalists
This InfoQ article
provides a good overview of this frequently debated topic.
My view is that the appropriate "specialist" versus "generalist" versus "generalizing specialist"
team balance varies considerably, depending on the specific team and project.
For example, if writing a Windows-only in-house accounting system in C# and SQL Server,
you may well be able to get away with a team of "interchangeable" generalists, where
any member of the team can perform any task.
Writing a large and complex product in multiple programming languages, running on multiple
operating systems, supporting many different third-party databases and other middleware,
is a different kettle of fish, however.
Specialists are required whenever the size and complexity of a system
grow to a point where they exceed the capacity of a single cranium.
One Size Fits All Teams
Each project's ecosystem is unique.
In principle, it should be impossible to say anything concrete
and substantive about all teams' ecosystems. It is.
Only the people on the team can deduce and decide what will work in
that particular environment and tune the environment to support them.
-- Communicating, cooperating teams by Alistair Cockburn
As outlined above, building effective and harmonious teams is a daunting task,
there being many individual, team-specific and cultural subtleties to be considered.
I certainly don't have all the answers, yet
I contend that forcing all teams in your organisation to
uniformly follow the same process for all projects is a strategic mistake.
Curiously, when I expressed this opinion, it was felt I didn't properly understand
Scrum and accordingly would benefit from attending another Scrum training course,
perhaps even gaining a prized "certification".
I will be discouraging individuals from taking such courses, and HR people and clueless managers from
looking for such certifications, particularly demanding them to be considered for an application.
I will continue to work hard with my clients and my fellow contractors to have actual
track records be considered, not some test one has managed to pass and pay for.
...what matters to me, as a trainer, is that my students can perform and think differently at the end of the class,
to be more effective and useful. No piece of paper makes that better or worse.
... there's no need to balkanize the workforce into those who have taken a particular test vs those who haven't.
-- merlyn on certification, Nov 23 2010
Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes
it worse still with their armies of trainers--some good, some not--issuing dubious "ScrumMaster" certificates
to people who demonstrated competence in connecting butt to chair for two days.
Or maybe we need to stop selling Agile. Maybe we need to say, "Agile is hard, and you can't master it by sitting
through a two-day course". Maybe we need to be firm and say, "Sorry, if you don't use agile engineering practices,
if you don't have high-bandwidth communication, and if you don't include a strong customer voice, you're not going
to succeed. Try something else instead."
-- The Decline and Fall of Agile by James Shore
Other Articles in This Series