After Andy's article last week, many people (including quite a few I have an enormous amount of respect for, and many others I haven't met) announced that they much preferred to simply keep doing what they've been doing. One of the leaders in our industry said she preferred to "keep improving how we deliver value at sustainable pace". And you know what? She's right.

That's an idea… it's a great value. But it's only that: an intangible; which requires someone with a great deal of experience to correctly interpret and apply that advice. Someone who's been working with software for a while, and has invested the effort required to become skilled, understands exactly what she meant. The technical guru who has 10 years of experience (not 1 year repeated 10 times) can take this advice, and it's useful.

Unfortunately, in my experience, that describes very little of our industry. We do have a talented core of skilled individuals in development, testing, and various flavors of management. Sadly, we have a much larger number of people who haven't reached that level, and don't know how to get there. Some just don't care, but others are struggling to get improvement, and when they get advice like "keep improving", they don't know how. As the old saying goes, they don't know what they don't know.

I frequently get emails asking which books they should read, which conferences they should attend. People want to improve, but they're often drowning in information and have no idea which information is good, bad, or ugly. For years we've been telling people to try harder, to read this book or that, attend this conference or that, and it's helped a lot of people. But many more have given up and turned into 9 to 5 wage slaves. They've retired in place and have given up seeing code as anything more than a way to pay the bills. We, as the enlightened priesthood, mock these people and talk about them at our conferences, with our enlightened friends. We're satisfied knowing that we're better, smarter and destined for greater things.

But what if these co-workers and friends want to be better but don't know how? What if offering them principles and ideas frustrates them and they want… no, NEED concrete steps. They're begging for explicit guidance, but instead we offer them values that are so nebulous as to be useless to them.

If this sounds like a scathing indictment, then good. It is. It's an indictment not of any individual, but of the industry. Most of us have fallen into the expert's trap. We've worked within a small bubble of smart, experienced people for so long that we've forgotten how to teach beginners. Let's face it... the person who knows who Martin Fowler or Andy Hunt is, and wants to bring them into their shop, is probably already very far along.

I've been lucky in my career. Many of my clients were in bad shape by the time I became involved. I've heard horror stories, time and again, about requirements, morale, quality, and so many other problems. I've worked with many talented people who didn't know anything about effective agile processes. They'd taken a Scrum class or two, read a book or two, but when things didn't work quite right, they didn't know what to do.

When Andy Hunt presented at several local user groups, during the time he'd started researching material for his Refactoring Your Wetware book, I first heard about the Dreyfus Model of Skills Acquisition. It was an eye opening view of how experts often lose touch with how people learn, and how beginners become frustrated with how experts teach.

Read my previous blog entry on the Dreyfus model for a description of it's stages.

A Solution

So what's the solution? Those of you at the Proficient or Expert stages must work very hard to relearn how to teach in steps. Precious few will ever rise above the Competent stage until we learn to teach in both steps and values. Start with steps. Show them how to work effectively, but then transition into values.

This isn't a new idea, but, as an industry, we've traditionally shunned it. Experts and Proficients are hobbled by the rules that enable workers at the lower stages. Managers, who don't really understand what we're doing, especially when we're moving in the intuition realm, are desperately trying to manage projects. They, being beginners, love steps. So if we, as experts, provide steps, we're terrified those steps will be written down, canonized, and used against us… because they have been again and again.

GROWS is an effective way to manage this problem. It provides steps for lower stage teams, but explicitly discards those steps as your teams move up the Dreyfus Model. It clearly explains to managers what the Dreyfus Model is and why their teams will require fewer steps as they become increasingly effective.

Some companies will not want their teams to operate at the highest stages. They'll want to get to Competent and stay there, and that's okay. It's not a shop most of us would want to work in, but if they're using GROWS, you can understand their operating model during your interview process instead of after you take the job.

GROWS is much more than a process-oriented application of our interpretation of the Dreyfus Model, but it does harness the model in an effective way. We must, as an industry, find a sane path to provide steps to beginners while not hobbling our experts. We can make it possible to have meaningful conversations about skill stages (especially with management) and relearn how to effectively teach others. There may be other ways to do this, but so far, I've found that GROWS, and it's use of the Dreyfus Model, extremely effective.