when relevant content is
added and updated.
Agile has never been anything more than a set of guiding principles. That is both a blessing and a curse. Teams that are trying out something new have very little guidance on where to go without an experienced person to give guidance. Others that have been ‘doing agile’ for some time see deviating from the popular frameworks and practices (TDD, BDD, KanBan, Scrum, automate all the things) as being less agile.
If you missed part 1, where I introduced Andy and the GROWS method, you can find that here.
It seems that GROWS is skill focused. Without giving away the secret sauce, how are you training and developing skill in different parts of the teams you work with?
Yes, GROWS is very much focused on individual and team skills. I suppose the ideas are rooted in Kolb’s Experiential Learning Cycle, or more generically in the idea of leveraging feedback to minimize risk and grow.
The default way most companies develop software is based on a misunderstanding of Royce’s original paper outlining what we call the “waterfall” method. Royce’s paper said you had to have feedback between all the stages of development, otherwise you’d fail. Well no one paid attention to that whole messy “feedback” thing and the dangerously naive approach of modern waterfall became predominant.
In fact, many modern organizations that claim to be “doing agile” are in fact merely doing smaller waterfalls, with all the attendant risk and poor results. The way to mitigate that risk is with feedback: small activities with near-immediate feedback to guide the process. That’s the soul of agile, if you will.
And that’s the same mechanism used to guide skill growth. Experiential feedback: small activities with near-immediate feedback to guide the process. That’s what Kolb was getting at back in the 70’s, and that’s what good educators have always known. The trick, however, is in that whole “analysis of feedback” part. It turns out that novices can’t do it at all; that’s only an ability you get later on. So true feedback response is itself a skill that must be grown. As with training wheels, GROWS helps in the beginning stages until you can do it for yourself.
Is there anything else you would like us to know?
GROWS promotes the idea of an experiment to a first-class methodological element. You use experiments to answer technical questions, but also to adopt new practices suggested by GROWS or others. The idea of an “experiment” is critical for both. No experiment fails; all experiments provide data to inform the next experiment. That’s the heart of growth in GROWS.
For adoption, framing a new practice as an experiment lets you participate in the adoption, not be a passive or unwilling observer. And the data may suggest this practice isn’t appropriate, or that perhaps the team needs to invest in their skills more before attempting it.
For technical questions, a true experiment also moves away from a rubber-stamp approval of some dubious technology, and requires a minimum of three valid alternatives to consider.
Because the fundamental truth is that we don’t know the answers. But we know how to find out.
My personal point of view is that GROWS, or at least something like it, is the way forward. Right now we have process and development methods that are more or less taken for granted. Instead of getting a set of practices, GROWS seems to leave people with the ability to make decisions for themselves.
Skill and independent thinking is a hard sell, but it is always the way to better work and better software.
Thanks for your time, Andy, and good luck growing GROWS.