Climbing the Learning Curve

[article]

A few weeks ago I worked with a project team on a project retrospective. The project finished very late, though it did finally deliver part of the original scope. We examined the project history to understand what they'd done well, and what they would do differently. As the story of the project unfolded, a familiar pattern emerged.

The team had significant experience making incremental improvements to the company's core product. The time had come to re-architect and rebuild the system using newer technologies and an architecture that would enable the company to expand into related product lines.

This project required the team to learn new technologies and skills as they moved from COBOL to C++ and object design, relational databases and SQL, as they took on designing a system from the ground up.

Looking back, it seemed obvious. The team was facing the prospect of building significant new skills while building a new product.

"I wish we could have found a way to learn how to think in objects before we designed the whole thing," said Eric.

"Yeah," said Sara. "If I'd known at the beginning what I did at the end, I would have designed the databases differently. We lost a lot of time redoing things once we actually learned how to use the new DBMS."

You may not face this set or this many "new to you" challenges on your next project; but with the pace of technology change and the push for innovation, it's likely you'll be facing a steep learning curve on a project sooner rather than later.

What can you do to manage the impact to delivery when your team needs to learn a new skill? Here are some strategies that will support learning and help deliver a product.

Practice with Feedback
Many of us start learning out of a book or a week-long seminar, but to really master a new subject we need practice.

If you've ever taken up a new physical skill such as riding a bike, dancing, or playing golf, you have probably had this experience: you believe you are doing something right, but you are not achieving the results you anticipate. You lose your balance, step on your partner's toes, or hit into the rough. The results tell you something is not right, but you don't know exactly what to change. So you try sitting up straight, looking down at your feet, or lowering your shoulder. The adjustment may or may not improve the results. If not, you try something else.

One way to obtain more targeted feedback is to view yourself on videotape as you practice the new activity. As you watch the tape, you will obtain more information on how far away you are from proper form, but you may not know how to correct the problem.

When someone else who is an expert in the activity observes your performance, you receive specific feedback that tells you what aspect of your form is not correct and what you need to do to improve.

I've tried all of these methods: book learning, self-modification by trial and error, and videotaped feedback. I can learn a skill with any of them. I achieve the best and fastest results when I practice the skill and have feedback from an expert.

The same is true for learning a new technology, language, or design construct. We do receive feedback from the environment—the code doesn't work, the tests fail, the program won't compile or build. These feedback mechanisms give us information, but they are slow and painstaking.

Practice with expert feedback will increase the rate of 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?

About the author

AgileConnection is a TechWell community.

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