There are no simple steps to follow that will guarantee a smooth transition to agile. True success with agile methodologies requires a true change in behavior and outlook.
-- Dafydd Rees
Much has been published regarding agile methodologies. A large body of literature addresses the technological issues of agile approaches-things like test-driven development and continuous integration. Similarly, another large body of literature discusses the application of agile methodologies: issues like release planning, tracking velocity, how to "tune" your process using metrics, and even how to convince businesspeople in your company to adopt a particular method. Reading the existing literature on agile methods, one easily could gain the impression that agile methods such as Extreme Programming and Scrum can be adopted simply by purchasing a set of tools and following a series of apparently simple practices. Real-world experience, however, suggests that successful agile adoption is more complicated than that. It involves fostering a set of attitudes that build trust, encourage communication and collaboration, and ultimately allow people to become more adaptable and productive.
Agile methods are often described as people-centric rather than technology-focused, and with good reason. Yet, although the Agile Manifesto highlights the importance of "individuals and interactions over processes and tools," it isn't always clear how to handle this important social dimension. In a technology-focused business it's all too easy to overlook the powerful effect that individual attitudes have on a project team. To learn which attitudes help (and which hurt) agile adoption, we need to ask the question "what behaviors can we observe among successful developers and managers?" and more importantly "what are the underlying attitudes that drive those behaviors?"
Growing Agile Developers
Many developers are accustomed to working individually, spending most of their time reading specifications, working through designs, and coding. In pre-agile environments some developers even choose to listen to music on their headphones, further isolating themselves from office noise. Developers adopting Extreme Programming find themselves immersed in a much more social environment where success depends on close collaboration with peers and customers. Additionally, classical, pre-agile development often involves code and designs that are exclusively "owned" by individuals. In an agile environment, work allocation is decided collaboratively by a team: no individual has complete control over a section of the code base. This attitude adjustment can be especially challenging.
Developers new to agile development probably are used to working on projects where the programming effort was divided by subsystem. They are likely accustomed to having sole responsibility for the design of individual subsystems, based on a higher level specification interconnecting each subsystem. Developers new to collective code ownership often are overwhelmed by the amount of code that they have to learn. This can be exacerbated by the fact that there's little or no technical documentation and that the code base can undergo rapid changes. Even the names of familiar classes and methods can change at short notice. Yet, while agile methodologies, Extreme Programming in particular, require programmers with strong coding skills. It's clear from observing both inexperienced and experienced agile developers that it isn't simply a question of skill but also one of attitude.
| Conventional Team | Agile Team |
| Subsystem ownership | Collective code ownership |
| Single design | Incremental development |
| Complete subsystem understanding | Exploration, investigation |
| Big design up-front, "consequence management" | "Spike solutions," experimentation |
| Comprehensive documentation | Automated tests |
| Quality by analyzing a complete design | Quality through Test-Driven Development |
| Requires a complete analysis | Seeks to limit relevant information (e.g., code coverage, small tasks, prioritization, etc.) |
| Individual design decisions | Forming and respecting team consensus |
| Size/complexity as an achievement | Size/complexity as a burden to be reduced |
| Decide up-front, try not to change the design | No final design decisions, changeability, change as a learning opportunity |
Figure 1: Some of the differences that can be observed between a conventional team and an agile team.
The table in Figure 1 illustrates a number of code-level differences that can be observed between a conventional team and an agile team. Experienced agile developers approach coding differently. They tend to treat code fluidly rather than as something that can be tackled only after the entire design has been perfected. They also tend to treat coding as an opportunity for learning and exploring. For example, when confronted with a problem, they tend to make the problem concrete by coding it as a small, proof of concept or "spike solution" rather than building a complex model or trying to capture rich behavior in a natural language description. Similarly, agile programmers are more likely to want to read third party code: sometimes they want to make some sustainable improvements; other times they do it just to learn a new design. Finally, long-time agile developers tolerate having only a partial knowledge of the code base by trying to isolate the classes, methods, and potential chains of method calls that are relevant to the task at hand rather than mapping an entire subsystem or application. All of these differences have much more to do with how the developers approach the problem of coding, rather than how skilled they are at actual coding tasks.
Take pair programming for instance. Pair programming is one of the most problematic issues for teams adopting agile methodologies, especially Extreme Programming, as it requires that all production code be written by a pair of programmers. Although a developer may have excellent design skills and a solid grasp of the development platform, an effective XP developer needs to be able to communicate ideas, collaboratively explore tests, suggest implementations, and agree on some implementation strategy. Many developers struggle with pair programming, not because they don't know how to code, but because programming in pairs is such an unfamiliar way of working. One developer wrote in his blog that pair programming forces developers to show the real state of their knowledge and skills. When coding alone, other people only see the result of coding sessions. When pair programming, your false starts and early mistakes are visible to others. That certainly can be intimidating, even for very skilled developers, and does take some getting used to. It's worth remembering that it gets easier as you get to know other team members and gain a clearer understanding of the personalities involved.
Most successful Extreme Programmers show considerable interest in programming languages, learning new designs, and most importantly reading existing code. These successful developers will tend to "practice" coding by trying out small exercises. They may well experiment by writing small tools and contributing to open source projects. It's important to emphasize the role of "practice" here. Good agile developers usually are driven to do something to gain understanding or skill rather than to merely know about it by reading.
"Extreme Programming is communism...". That's how one developer explained his reluctance to pair program. He referred to the fact that coding is a shared experience in XP. He jested about the "collective code ownership" and the fact that all developers are to be rotated around all the areas of work so that any developer can work on any part of the product. After talking to this developer for a while, it became clear that his real concern was with competitiveness and job security. He was concerned about the competitive issues within and between different teams. To work with another person meant allowing them to see how he tackled a problem and what tools he used-it presented an opportunity for them to learn his tricks. His reluctance to pair program reveals the need to address professional development and job security issues in agile teams. Pair programming naturally involves being open with colleagues, sharing domain knowledge, and being prepared to explain your approach.
An overly assertive developer can also throw off a pair programming session. Sometimes this happens when velocity slips and one of the programmers takes over to "get it done faster." Sometimes if outsiders are in a pairing room, one developer will begin "pushing" the pairing session to show off. Other times, one of the developers is impatient to see a task completed because he's taken personal responsibility for completing the user story. Perhaps the most obvious reason is ambition: trying to demonstrate technical strength perhaps to get a team lead position, or some other promotion. Such an attitude can easily cause a pairing session to degenerate into a point scoring match, in which the objective is to see which developer is going to "win" rather than to work out how to do something useful and do it.
Too little assertion also can be a problem. It's possible for a developer with a low level of motivation to care very little about the pairing task at hand and to allow himself to be led around by his pair. In this scenario, the developer is abdicating much of the responsibility for the design and for code quality.
Creating Agile Coaches
Thus far, we've only considered the practical day-to-day issues among developers. Creating and sustaining a development team with an agile attitude is for the most part the responsibility of coaches and other leaders. These leaders must set a good example for their team and be true coaches, rather than team members in a coaching role.
One of the most effective leadership techniques is to set a good example. Setting ground rules for a development team such as "all production code needs to be written in a pair" or "all production code is to be written test-first" will only work if the team members believe these rules matter. It's all too easy to state one thing and to demonstrate the opposite-sometimes within minutes. For example, one team leader announced to his team, "The build is broken. Our most important task is to fix it." That seemed credible until he followed up with the following: "I did notice it first and normally would fix it myself, but I'm too busy." The message to the team that "it's the most important thing" is totally undermined by an action that demonstrates the opposite. The build either is the most important thing happening right now or it is not. It's not at all unusual for a team lead to keep people waiting while he or she pairs up with a developer to fix the build. Taking the time to do that is one way to reinforce the message that the build is very important in a development team.
The role of a "coach" in Extreme Programming is a support role in much the same way it is in sports. Sports coaches are judged by the performance of their teams rather than on their personal performance, knowledge, or technical merit. Unfortunately "XP coach" has become a fashionable job title to which many developers who see themselves as "alpha-geeks" aspire. It's important to remember that coaching is a people-centric, service activity rather than an elite status to be achieved. People skills and the need to earn and retain respect are integral to success in this role.
Good coaching isn't simply about knowing enough to teach developers how to perform techniques. It's also about inspiring developers to think pragmatically and to get along productively with each other. This is somewhat akin to Ken Schwaber's description of the ScrumMaster role as being one with no authority yet with responsibility for encouraging the team to work together. It's a bad sign when a coach refuses to explain something, uses technical knowledge to "beat down" an alternative idea, or tries to lead by "command."
In my opinion, it's better for someone with the formal title "coach" to be an outsider brought in to help the team, rather than a permanent team member. A coach that is a permanent member of a team has a conflict of interest: Part of his or her role will involve helping people improve their performance and work better as a team, and at other times he or she will be subject to team appraisals and competition between developers within the team. As Kent Beck mentioned in his book "Extreme Programming Explained," a coach should be comfortable with the idea that a team can develop to the point where it no longer needs the coach. An effective coach needs a good degree of personal confidence and emotional security as well as technical knowledge and experience.
Weeding Out Hidden Problem
There are several hidden factors that can adversely affect a team's attitude. Some team members fear that their leaders are innovating only to further their own personal goals, rather than doing what's best for the team. Others have personal roadblocks to change that they are afraid to express. Another particularly troublesome problem is the tendency we all have to boast and criticize rather than accept and learn in humility.
The software field offers personal rewards for innovation. Writing papers and presenting at conferences obviously raises the profile of individuals. Lead developers, coaches, and people in similar roles are in a position where they can introduce change. It's important to realize that although there's an incentive to innovate, there's also the potential that a change could disrupt or place some stress on a team that's already productive. Better to hold a retrospective with the team to find a solution than to try to "sell" a strategy already devised by someone in authority.
It's important for people in a position of authority to motivate the entire team to embrace change rather than press through some change that may benefit only themselves and the business. As one developer confided, "... all this does is give us more grief. They're just trying to go to conferences and big it all up..." His concern was that a particular innovation was being imposed on his team in order for one or two people in authority to look good even if it made his daily job of delivering working software on time more difficult. It's important to realize that there's a personal need for stability and security and that too much change too quickly can be destabilizing.
Other times, it's obvious that people have deep-seated objections to a particular change that have yet to be uncovered. This is often the case when, no matter how many individual concerns raised are neatly addressed, more concerns continue to surface. It may well be the case that the people raising the concerns have a personal or motivational problem with the improvement but don't feel comfortable voicing it. For example, many people are likely to raise technical and business objections to Extreme Programming. Fewer people are likely to be brutally honest about what's truly troubling them. For instance, you're not likely to hear: "Implementing XP means rigid work hours, so I won't be able to pick my daughter up from school."
A similar case occurred when one team looked at the possibility of adopting a new technology platform for some products. A number of developers objected quite strongly based on a number of technical concerns, such as scalability, training, maintenance costs, the quality of tooling, and so forth. Months later, it emerged that the real concern was that many developers didn't wish to invest time in the proposed platform because they felt that the skills market for the new platform didn't justify the personal learning commitment. In a professional context it can be difficult for individuals to raise such concerns even though professional development, employability, and work-life balance are legitimate issues.
The last hidden factor in cultivating an agile team is a simple need for humility. Humility confers a number of benefits in an agile team. Among other things it reduces the potential for counterproductive "point scoring" contests. It's a mindset that's compatible with the XP concept of "do the simplest thing" and as Steve McConnell points out in Code Complete, it encourages developers to write more understandable code. A good time to practice humility is when you're tempted to criticize other people, even when they're making a valiant attempt to adopt an agile method. Although other people have failings, it's important when you think you've seen a shortcoming to ask "do I ever do that?" You may not be able to correct other people's failings but you're certainly free to learn from them.
Conclusion
Fostering productive attitudes and behaviors in an agile team is a complex yet essential activity. Many people attempting to start an agile project may focus on the business case. Although the business case is important, remember that all the stakeholders involved are, first and foremost, people. They have their own personal needs and concerns. A successful self-organizing project team requires each participant to be genuinely motivated to make improvements. Agility can't be mandated, but it can be cultivated by motivated team members given the freedom to self-organize.About the Author
Dafydd is a software developer specializing in agile methods and object-oriented development. He welcomes feedback at www.dafydd.net/feedback.php.