Uncharted Waters

Jan 18 2016   9:03AM GMT

Andy Hunt on the GROWS Method – Part 1

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
Agile

Agile started out as rebellion. A group of people who were tired of the routine, structure, and lack of flexibility in software development got together in Snowbird and decided to do something different. Some might say that agile is now that routine, structured, ‘do this, not that’ software methodology that some were rebelling against in the 90s. Andy Hunt is one of those people, and he is doing something about it with a new method he is calling GROWS.

Andy was kind enough to talk with me about GROWS, his experience with agile, and what differentiates his new method from everything else.

Let’s get started.

Let’s start with an intro. For those that don’t know, who is Andy Hunt?
I’m a programmer, consultant, author, and publisher who dabbles in music and woodworking. I’ve worked and consulted at behemoth companies and microscopic start-ups. I’ve written nine books on software development, including best-sellers, award-winners, and the seminal classic The Pragmatic Programmer (with Dave Thomas). We’ve published hundreds of books, and read maybe some hundreds more of proposals that we didn’t accept, which itself offers a lot of insight into the world of software development thinking.

I’ve been programming professionally since the ’80s, and I’ve seen a lot of Next Big Things come and go, a lot of “best practices” fade, and a lot of bad habits stick to us like glue.  I’ve always been interested in the sort of “inner game” of programming — what goes on in our heads; why do we think the way we do? What can do to improve on that? After all, software is created in our heads, not in an IDE.

I was fortunate enough to be one of the 17 folks who got together in Snowbird to coin the word “agile” and launch the modern agile movement, such as it is 😉

GROWS

What made you want to diverge from the agile movement and create the GROWS method?
Frustration.  The agile movement encompasses a lot of great insight into how people work and think, and how to effectively create software.  But there’s a growing disconnect where people have lost sight of what it means to be agile, and instead sink into the mire of merely slogging through several popular, but poorly-adopted practices.

What are some of the fundamental differences between GROWS and agile right now?
I think the biggest difference is that we’re trying to move away from the central idea of “here is a canonical set of practices you must do,” and go back to the fundamental notion of “try it, see what happens, fix it and move on.”  Agile has always promoted the idea of “inspect and adapt” but of course that’s a lot harder in real-world practice than it is in a book.

The key is that people (and teams) change as they grow in skill.  So you have to start beginners off in a certain way that works with their lack of experience, but you can’t keep them there. By the same token, you can’t start off at a high level and expect good results.

One of our big mistakes in the agile community, I feel, is that we showed the world how a professional driver takes turns in a finely-tuned sports car, and then showed them to their 3-cylinder mini cars and said “have at it.”  Driving is a pretty good analogy here: you start off on a bike, perhaps, with training wheels.  But you don’t stay there.  You take off the training wheels at some point, maybe move up to a motorized bike or motorcycle, then a lengthy period of training and exams, a graduated license system, and finally you can drive on the highway with other people.

But you haven’t even started your race car training yet. And which kind? Formula One, NASCAR, drag-racing? Or are you driving a school bus or long-haul trucking? This are all very different, and require very different skills. We haven’t been good at addressing that.

With GROWS, we want to start people off with a solid, training-wheel beginning, and help them grow their skills and grow their software. We want to promote the support for beginners and the guidance for more expert practitioners that maybe is out there already, but getting a little lost in the noise.


That’s just the beginning on the story of GROWS. Next week, I’ll return with part and go deeper on the details of GROWS and how it actually works. See you then.

1  Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • EBaldwin

    Having seen the transition from traditional waterfall to early Agile methods (e.g. RAD) to Scrum, Kanban, modifications (e.g. Scrum-Ban), DevOps, and now GROWS I see three key points:

    1) Humans tend to prefer regular and safe ways to move through life.  This means what is new must be put into a pattern.  Remember the old Japanese proverb; 'the nail that sticks out shall be hammered down'.

    2) People who look for ways to improve will always challenge the current status-quo or pattern, in this case for SW development it's Agile.  This means the bulk of the community will initially reject the new method; change brings uncertainty and fear.

    3) Good people supporting proactive enterprises in business, government, or academia will look for ways to improve, in this case from waterfall through Agile to either DevOps or GROWS.

    Summary; the more things change, the more they stay the same.

    130 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: