 Often, our agile teams are made up of junior and senior people. Some of these people tend to be more domain focused, such as understanding financial services, while others are more engineering focused, with expertise in software architecture and programming languages. While this mix is generally beneficial from a synergistic point of view, it can also create friction during development - friction that requires active management attention and a proactive balancing of the relative "skills scales."
Many contend that agile can work only when all team members are senior. If we apply this reasoning to any group, e.g., a practiced sports team or a well-oiled jazz band, we find that this basic tenet holds - a set of senior players is generally more effective than a similar group of less experienced ones.
While this is true in the general case, {sidebar id=1} there are several problems with this line of thinking when it comes to agile software development. First, it's nearly impossible to staff all of your agile teams with experienced people. You simply do not have that many to go around. Solid performers with a track record of success are rare. In any organization, you know who these people are. They are the ones whose names come up again and again when you're trying to solve your toughest problems. Second, this promotes a very short term view of the organization. You need your experienced people to cross-train with your more junior staff, ensuring a deep technical bench. Third, this generalization fails to recognize the two skill vectors that are important to any agile team's success: domain knowledge and technical expertise.
Balancing Essential Skills
Failure to recognize the two skills vectors at once is a common source of problems for many projects, agile or otherwise. Most organizations have a broad range of talent. For our purposes, these people range from being experts in the domain, with little to no technical knowledge, to those who are guru-level developers with only a grim understanding of the domain in which they build software (they use requirements to fill the void). We can illustrate this on a simple matrix, as shown in Figure 1.
Figure 1: Domain versus engineering expertise
Agile teams work best when all of the developers are seasoned engineers who are proficient in the domain. For all practical purposes, however, it's nearly impossible for most teams to realize this mix; therefore, senior technology managers need to adapt and help create effective balance.
In an ideal world, you would build your agile team almost exclusively with people from QI. These people possess both deep domain knowledge and have demonstrated profound technical competency. They are, for the most part, quite senior. If these people work well together, and you have the luxury of building such a team, do it! You are very lucky! Luck notwithstanding, in most cases, you'll build a team using a mix of people from QI, QII and QIV. Avoid putting those from QIII on an agile team; they will more than likely weigh the team down relative to whatever contribution they might make.
In addition to domain and technical knowledge, when assembling your team, make sure to consider each individual's personality, ego emissions,[i] the need to be right, team spirit, sense of humor, empathy, work ethic, and professional integrity. In other words, strive to create a team rich in self-motivation and in emotional intelligence . On an agile team, emotional intelligence is as important as hard abilities.
Once you have assembled the team, your next job is to balance their skills. Given our graph above, we want experienced programmers working with less experienced programmers, and those that possess deep domain knowledge working with those that don't. To realize this mix, the team can employ various techniques including pair programming, peer reviews, formal mentorship, and group education sessions, where an expert in a given area takes some time to educate the rest. While trying to maintain this balance is extremely important, it can lead to some serious inter-team conflicts.
These conflicts arise out of misperceptions, misaligned goals, and a true understanding of the problem at hand. In my own experience, I have seen junior developers with deep domain knowledge argue vehemently with very senior developers over Java best practices. They figure that since they know the domain the best, they are entitled to make carte blanche decisions regarding implementation. I have also seen the opposite, where expert engineers choose elegant implementations that fail to address the underlying complexity and needs of the problem space. Neither position advances the team's goal of delivering high-quality software and can impede its velocity dramatically.
Adding a Tie-Breaker
Agile practices would suggest that everyone leave their ego at the door and let the best idea emerge; however, the best idea is not always apparent, and the group at large may not be able to reach a governing decision. What you end up with is deadlock, or worse, a wishy-washy compromise that falls short. In many cases, the person with the most aggressive personality, or who can speak the best, wins. Thus, the most politically savvy personality may affect the outcome to suboptimal effect.
In these cases, I think it is very important for each team to have someone from QI to act as a Master Developer or Chief Engineer. This person serves as a "tie breaker," and takes responsibility for moving the team in a positive direction. On some Scrum teams, the ScrumMaster tries to play this role. I think this is a mistake, since often the ScrumMaster is not someone who lives in QI. ScrumMasters may have good intentions, and act to remove the logjam impediment, but they are generally not qualified to make these decisions.
Self-organization notwithstanding, there are times, inevitably, when a dynamic group of individuals will arrive at a serious technical or political impasse. To effectively overcome this situation, we need a senior team member, with recognized authority, to arbitrate and make a thoughtful and experienced decision. If you do not have such a person assigned to the team, the resulting compromise can seriously affect long-term product stability and quality.
It's important, also, for all team members to understand the skill sets they bring, and where they need to learn more. Those steeped in the domain have an obligation to share their knowledge, and those expert in technology need to mentor those less experienced. The real key here is that people need to be willing to be taught. A closed mind and a closed heart is a recipe for ignorance.
To help open and educate, the proactive technology manager needs to move his or her best people towards QI. For those in QII, make sure to have them take classes in a modern programming language, TDD, and refactoring. For those in QIV, ensure that have adequate in-house or industry training, and access to relevant materials. In most instances, it's more difficult to train someone in a specific domain than in a horizontal technology, such as Java or C#, so apply your efforts accordingly.
Conclusion
This is a call to all of you agile practitioners out there. Domain experts, share your knowledge in a clear, concise manner. Make it part of your job. Document the hard stuff. Learn from the technology experts, and let them help you realize your solutions. Technology experts, listen to those with domain knowledge. Really listen, and do not jump to an "elegant solution" too quickly. Understand the dynamics of the problem space, and work hard to explain your thought processes and decisions. To all - know what you don't know and listen to those who do. Open your mind, put down your ego, share what you know, and learn from others.
About the author
John Puopolo currently serves as Vice President of Engineering at TeleAtlas, a worldwide leader in digital mapping. John has been developing enterprise and shrink-wrapped software for over 16 years, and has enjoyed applying agile practices (Scrum) to his teams' development. John lives with his wife Jill and their three children in Sudbury, MA.
[i] "Ego emissions" is a term I learned from my colleague, Mark Winberry. He believes that the success of agile projects is dependent on the amount of ego emitted within the team. Low is better.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form