Getting Past Agile Advanced Beginner

—Andy Hunt

06/01/2011
Published in PragPub Magazine

Again and again folks tell me that they’re stuck. They embarked on the journey to become agile practitioners, but despite the best intentions, they can’t seem to break through to function as a true, self-directed, self-correcting agile machine.

Instead, they are stuck. Stuck following published “best practices” that someone else came up with for a magazine article. Stuck following a plan that was handed down to them, due on a deadline negotiated by lawyers they’ve never met or spoken with.

The team is practicing some agile methods, but they aren’t agile. Left to their own devices, nothing will change that. They’ve reached the Advanced Beginner stage, and it’s going to take some care and attention to move past this to become a competent practitioner.

To understand this, let’s look at the Dreyfus Model of Skill Acquisition.

The Dreyfus Model

The Dreyfus Model is a helpful way of looking at how people acquire and grow their skill sets. It defines five levels that you experience as you gain abilities at some specific skill (for more, see Pragmatic Thinking and Learning).

Here are the levels, with some key features of each:

Novice - Rules-based, just wants to accomplish the immediate goal
Advanced Beginner - Needs small, frequent rewards; big picture is confusing
Competent - Can develop conceptual models, can troubleshoot
Proficient - Driven to seek larger conceptual model, can self-correct
Expert - Intuition-based, always seeking better methods

Most people, in most skills, never get beyond Advanced Beginner. This certainly seems to be true for would-be agile practitioners. At the Advanced Beginner stage, you’re comfortable enough to sort of muddle your way through. And for most folks, that’s enough. It kind of looks good on the outside, and you can list it on your resume. But that’s a hollow victory. You won’t reap the benefits that an agile approach can provide. In terms of productivity, you might as well be coding in COBOL with a pencil on a yellow legal pad.

Fortunately, we can do better than that.

There are five levels in the Dreyfus model, but not all of the levels are equal sized or as easily traversed. For instance, it’s easy to go from Novice to Advanced Beginner, but the jump from Advanced Beginner to Competent is much harder.

What we need to do is to see how, specifically, to make the jump from agile Advanced Beginner to becoming a Competent agile practitioner. If you look at the levels above, one big difference between an Advanced Beginner and a Competent practitioner is the Competent’s ability to develop and use conceptual models.

So it seems the first thing we need to do is to establish some kind of a mental model about agility.

An Agile Mental Model

Agile is all about taking small bites and focusing on continuous, not episodic, development. You want to do a little of everything all the time, and not face big lumps of major events. That’s the “constant” part in this definition:

“Agile development uses feedback to make constant adjustments in a highly collaborative environment.” (Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt)

The idea of correcting based on continuous feedback is key, but in order to do that successfully you’ll need to ensure that all the following are true:

All of your development and management practices generate continuous, meaningful feedback.
You are able to evaluate that feedback appropriately, in context.
You are able to change your code, your process, your team, and your interface to the rest of the organization and the customer in order to respond to the feedback.

That’s just the mechanical portion. To be agile, you need to start off with an agile mindset. Look at the agile values from the Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

...and review the definition above. If you can proceed in a fashion that honors these values and adheres to that definition, and you’re able to respond as needed, then you’re headed in a more-or-less agile direction. You’ve got the basic model of agility in your head, and by asking questions and constantly reviewing what you’re doing in terms of this model, you’ll make progress.

Put it in Practice

That’s the theory, anyway. But theory does you no good unless you can put it into your practice. And practice means trying, failing, learning, and trying again.

Embrace the idea that there’s no one here to tell you what to do next. It might seem nice to have someone hold your hand at this point, but that’s a luxury few can afford. You’re on your own.

Familiar and comfortable ways of doing things may look attractive, but that’s a trap. Don’t fall for it. You’ll need to venture into the unfamiliar and uncomfortable, and lose a lot of mental baggage while you’re at it. Think of the XP maxim and ask yourself, what’s the simplest thing that could possibly work? What’s the least you could possibly get away with? That question works for code, process, documentation, training, QA, and more.

Suppose you need to accomplish a particular goal, XYZ. How can you accomplish that in a lightweight, low-ceremony, agile fashion, and still fully accomplish the goal?

For example, take testing (please :-).

You’ve started a new agile-based project and have been getting everyone up to speed on this new “agile stuff.” Now you’re tasked with bringing the QA staff into your fledgling environment to do testing. How can you do so in an agile fashion?

Let’s clarify what it is they’re doing—which is always a fine idea when starting out. We’re not talking about Unit Testing. Unit testing is mis-named; it’s a coding practice, not a testing practice. Yes, developers need to do it, and no, it doesn’t negatively impact your QA staff. So perhaps your development team is doing Test-Driven or Test-First Development. That’s great, they should be writing unit tests on an ongoing basis, keeping it continuous and episodic.

So now you need to bring QA into the fold to do more comprehensive testing, maybe focusing on acceptance testing, performance testing, other non-functional requirements, and so on. Are you going to wait for the end of a major release to give them code to test?

Of course not, that’s thinking of the event as a large, discrete episode—that violates the model. You don’t want episodic development, you want continuous development. Are you going to wait until the end of an iteration? Perhaps, but that’s still waiting and making a bigger event out of the situation than is needed.

Give QA the ability to pick up a testable version right off your continuous build machine. Every build that passes all the automated developer tests is eligible, and QA can grab the latest functioning code base and have a play. They have the opportunity to grab releases every hour, every half-hour, all day long. Or they can wait and grab it once when done (in a non-agile fashion), but the choice is theirs and they can change that choice at will.

Does it Work?

How does this simple example stack up to our mental model?

You’ve implemented a policy that’s lightweight and easy to maintain. You’re delivering value Continuously, and you’re delivering actual Working Software. Like the Hungry Consumer Model (see The Pragmatic Programmer), QA can make their own decisions about when and what to test. You can experiment with feedback to the development team based on both team’s needs. So you’re honoring Individuals and interactions over some rigid process. You’re able to Respond to Change easily, without affecting the development rhythm, as the two teams are loosely coupled.

Of course, things rarely go exactly as planned. That’s just how the world is. Maybe this scheme doesn’t quite work out for you. That’s great! Evaluate the feedback on where the problems are cropping up, and make constant adjustments to try and fix it. Just as with novice drivers, don’t overcorrect, or you could slam into oncoming traffic (metaphorically speaking). Tweak a little, check the feedback, and tweak some more. Even corrections to code or process shouldn’t be big, major events. Change a little, all of the time. And now you’re practicing agility.

Something to think about.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.