learning and provide a base level of quality. While the expert won't correct all the style errors, she may prevent the worst from making it into the end product.
Here are four ways you can ensure your team has feedback as they practice a new skill or learn a new technology:
Hire a coach who will be part of the team, but have specific responsibilities around supporting the team to build skills. Extreme Programming has provided us with a good model of what a software team coach does. An XP coach works with each team member in pair programming and assures that good practices are being followed.
Use technical reviews to support learning. If you have access to people who are experts or are highly competent in the new skill, bring them in as part of a regular review team. Include other "learner" team members who have knowledge in the domain as part of the review team. The author will gain specific feedback to improve the product, and the less expert reviewers will learn new techniques and improve their abilities without having to admit ignorance.
Leverage a team member who has substantial experience. If one member of the team has substantial experience, that person can help the rest of the team learn the new skill. Having a team member coach can be more economical than hiring an outsider, but realize that time spent answering questions and coaching others means that the "on-team expert" will not be able to carry a full-time load using his skill directly to build the product. One way to manage the time is to have open-door days, or even open-door afternoons, but leave some part of the day dedicated to quiet, concentrated time for your
resident expert to contribute to the product.
Hire experts either as employees or contractors to high-leverage roles on the project. Make sure that they understand that increasing capability and transferring knowledge is part of their job, and that they have the interpersonal skills to do it.
When you provide feedback to go with practice you will manage the risk associated with climbing a steep learning curve. It may look expensive; but think back to the project at the beginning of this article. That team delivered two years late on what had been sold as a one-year project. That team is still fixing major bugs and is on the verge of burnout. Which seems more effective to you?
Pages
About the author
A regular StickyMinds.com and Better Software magazine contributor, Esther Derby is one of the rare breed of consultants who blends the technical issues and managerial issues with the people-side issues. She is well known for helping teams grow to new levels of productivity. Project retrospectives and project assessments are two of Esther's key practices that serve as effective tools to start a team's transformation. Recognized as one of the world's leaders in retrospective facilitation, she often receives requests asking her to work with struggling teams. Esther is one of the founders of the AYE Conference. She co-author of Agile Retrospectives: Making Good Teams Great. She has presented at STAREAST, STARWEST and the Better Software Conference & EXPO. You can read more of Esther's musings on the wonderful world of software at www.estherderby.com and on her weblog at www.estherderby.com/weblog/blogger.html. Her email is derby@estherderby.com.
