Balancing Skills For Agile Team Success


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 quot;tie breaker,quot; 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.
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 quot;elegant solutionquot; 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


AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.