· Individuals with strong personalities changing the way in which the ecosystem works
Everything affects everything: the chairs, the seating, the shape of the building, whether people share a native language, even the air conditioning. Lizards and Penguins
At one company, moving from our old building to a new one nearly caused fights. In the old building, we each had a private office, and each office had its own thermostat. In the new building, we would still have private offices, but there was only going to be one thermostat for every two offices. Each adjacent office pair had to use the same temperature setting.
Suddenly, the work force polarized into those who liked warm offices (the "lizards") and those who liked cold offices (the "penguins"). People were jockeying for positions, so they could share the thermostat with someone of similar temperature preferences.
In some work situations, it is hard for people to change companies. In other situations, people change jobs every few months. The two situations create different attitudes and behaviors in the work force.
Every job role and every person affects every other. Key individuals play a more significant role in shaping the ecosystem than others. They focus, or more frequently, block conversations. When they leave, the entire network of relationships changes.
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.
Understanding some key characteristics of humans and of methodologies, the team can look around, introspect, and construct a best first guess as to what conventions and policies might work well for them, suiting their own strengths and weaknesses.
Mapping Methodology to Ecosystem
The people on the teams will naturally reexamine and adjust their conventions over time, periodically or whenever a major event changes their ecosystem (as when a particularly influential individual joins or leaves the organization).
The set of conventions and policies I refer to as the team's methodology. As we shall see in the next chapter, a methodology is a personal thing, "a social construction" to quote Ralph Hodgson.
Considering the methodology as the team's own social construction is useful. It highlights that no boxed methodology will work straight out of the box. The team will have to adapt both themselves and the methodology to work together, to create their own, local, effective ecosystem.
Ecosystems and methodologies have this interesting characteristic in common: If the team constructs many, complicated rules for themselves, they tie themselves to a narrow ecological niche.
However, narrow ecological niches are notoriously fragile, and the market has a nasty habit of changing the terrain around a company. The many rules that give effective behavior in one ecological terrain are ill-suited for another terrain.
In biology, we use the word "extinct." In bursiness, the phrase is "go out of business."
If, on the other hand, the team creates and periodically updates a few, well-placed guidelines, they can draw on the intelligence, pride-in-contribution, communication and spontaneity of their members. The people will adapt those guidelines to the situation at hand, achieving robust behavior in the face of technological, social and market surprises. Dee Hock, designer of the highly-decentralized VISA system in th 1960s and 1970s, wrote (Hock, 1999):
"Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple,stupid behavior."
Walk around your place of work. Notice
· The convection currents of information,
· The drafts
· The information radiators
· The separate communities of practice
· The background conversation complimenting or denigrating other groups in the organization
See
· How you can improve the flow of information and reduce the erg-seconds required to detect and transmit critical information
· If you can colocate your team, or
· If you can partition the project so that teams are located around their communication needs
Try
· Removing partitions between people
· Pair programming
· Arranging for daily visits between programmers and business experts
· Micro-touch intervention (people making small changes that they don't mind making, but which result in their pulling more in the same direction)
· Listening to the words of someone in a different professional specialty according to their cultural norms, not your own
· Translating between two subcultures in their own cultural terms
Observe the interaction between your methodology's rules and your project's ecosystem. Note the fits and the misfits, and the influence of a few, key individuals.
Consider what conventions or policies might improve the way in which your group gets things done. They may be conventions about seating, tools, working hours, process, lighting, meetings, anything.
Do this, and you are half-way to tailoring your methodology to fit your organization.
The purpose of this chapter is to discuss and boil the topic of methodologies it until the rules of the methodology design game, and how to play that game, are clear.
"Methodology Concepts" covers the basic vocabulary and concepts needed to design and compare methodologies. These include the obvious concepts such as roles, techniques, and standards and also less-obvious concepts such as weight, ceremony, precision, stability, and tolerance. In terms of "Levels of Audience" as described in the introduction, this is largely Level 1 material. It is needed for the more advanced discussions that follow.
"Methodology Design Principles" discusses seven principles that can be used to guide the design of a methodology. The principles highlight the cost of moving to a heavier methodology as well as when to accept that cost. They also show how to use work-product stability in deciding how much concurrent development to employ.
"XP under Glass" applies the principles to analyze an existing, agile methodology. It also discusses using the principles to adjust XP for slightly different situations.
"Why Methodology at All?" revisits that key question in the light of the preceding discussion and presents the different uses to which methodologies are put.
"Methodology is a social construction," Ralph Hodgson told me in 1993. Two years went by before I started to understand.
Your "methodology" is everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.
All organizations have a methodology: It is simply how they do business. Even the proverbial trio in a garage have a way of working—a way of trading information, of separating work, of putting it back together—all founded on assumed values and cultural norms. The way of working includes what people choose to spend their time on, how they
I use the word methodology as found in the Merriam-Webster dictionaries: "A series of related methods or techniques." A method is a "systematic procedure," similar to a technique.
(Readers of the Oxford English Dictionary may note that some OED editions only carry the definition of methodology as "study of methods," while others carry both. This helps explain the controversy over the word methodology.)