author and publisher.
Getting Past Agile Advanced Beginner
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
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
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
“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 interactionsover processes and tools Working softwareover comprehensive documentation Customer collaborationover contract negotiation Responding to changeover 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
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,
Suppose you need to accomplish a particular 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.
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
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
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.
Paperback, hardcover now available
September 25, 2017
New Book Almost Ready
September 14, 2017
- List All News...
Fixing the Stress of Designing, Forecasting, or Planning
July 9, 2017
Stop Practicing and Start Growing
July 11, 2016
January 25, 2016
- List All Articles...