/\ndy

It's an Experiment

In my last blog post questioning the state of the agile movement, I asked “What happened to the idea of inspect and adapt? What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand?”

According to a 2014 survey on agile development by VersionONE, 56% of the teams they surveyed use Scrum, some 10% use a Scrum/XP mix, and 8% are using a mixture of agile methods (including XP, Kanban, Lean, etc.). To me, that says that maybe 18% of the survey respondents are possibly doing the right thing. The rest, perhaps, are merely doing a stand-up meeting and calling it “agile.”

Okay, perhaps that’s overly cynical of me, but another question on that same survey shows only 26% of the teams are set up for continuous deployment. I think that’s a telling statistic. It’s one thing to have a build machine running in the background and call it “continuous integration,” but you actually have to know what you’re doing to take that to the next step and be prepared for continuous deployment. I consider that a hallmark of an actually effective, agile team. It doesn’t matter if your design is awesome and you’ve figured out the customer’s needs if you can’t then actually get software out the door consistently, reliably, and automatically.

And look at that 8% figure. I think those are the teams that might be truly effective, and are able to embrace change. They aren’t fussed over whether a practice is canonical Scrum, XP, Lean, or whatever. They are mixing and matching what works for them. That is what it means to be agile, and that isn’t some thing you achieve by merely following static Scrum or XP practices.

The problem, I think, is that while agile methods invite you to inspect and and adapt as necessary, that idea isn’t represented as a first-class part of any method. There is no Scrum practice whose purpose is to create new practices. The same is true of Extreme Programming. The heart of becoming an agile practitioner, as Dave Thomas wisely points out in this blog post, is to:

• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned
• Repeat

Easy to understand, but perhaps much harder to actually do. Just because you read the driver’s ed manual (an agile book) and maybe even got your driver’s license (or some silly certification) doesn’t mean you’re ready for Formula One racing, Le Mans, or rush hour in Manhattan. And that’s a big problem with agile adoption, as Jared points out in this post.

So I’d like to try an experiment. I’d like to propose a method that features an Experiment as a first-class feature of the method. Beginning with adoption and last through your own unique local evolution, you can be guided by actual outcomes under your own actual conditions from experiments (beginners start off with very concrete, unambiguous steps/ checklists, and move away from those as skill progresses).

Rather than relying on what might have worked somewhere else with different people, you can inspect and adapt in the proper context: yours.

You can use experiments to take back control. Let’s see how this might work.

Put your Egg In

In general, folks don’t like change. There’s a saying that only wet babies like change, but even then there’s a lot of crying and wailing involved. So really, no one wants change.

What folks want is new and different results. Preferably for free, without having to change anything significant. But most of all, folks really don’t like to be changed. For any chance of success at all, change needs to come from one’s own desire. It’s like the old joke where the lightbulb has to want to change.

That means that people need to be shown a very personal, direct upside for them. Abstract notions such as “higher quality code” or “improve our time to market” just aren’t compelling. As a developer, I probably don’t care about these issues; any benefit to myself is indirect at best. As a customer support rep, I may have much more of an interest in code quality, because that affects me. As a VP of sales, time to market may be critical to me. I may not give a rat’s hat about “code quality.” So for me to buy in to some new approach, and it requires me to do something differently, then I need to see how it specifically benefits me. And then maybe I’ll consider trying this new, wacky thing you’re proposing.

The GROWS idea of better adoption goes something like this:

First, everything is paced according to your skill level. Since we’re talking about adoption here, then everyone is a novice at GROWS—they have no experience with it yet. As a novice, there are some practices you want to try, and there are practices that GROWS says you need to start with.

In GROWS, you adopt a practice by running an experiment. Each practice comes with its own experiment, which helps you identify the conditions for the experiment, the feedback to look for and how to evaluate it. For novices, the feedback and evaluation are very concrete and unambiguous, with no judgment required. That part comes later.

Experiments are time-boxed, which limits commitment and risk, unlike the more amorphous “change,” which is permanent and open-ended. It’s very clear all involved that you aren’t yet adopting this practice or committing to it. You’re just going to give it a try.

Everyone participates in the experiment and in evaluating the outcome, which gives the participants a chance to “put their own egg in,” as the saying goes. (When Betty Crocker first came out with an instant cake mix, it was a failure. All you had to do was add water to to the mix. They changed the formula so you had to add an fresh egg and water, and now consumers felt like cooks again. That version was a success: level of participation makes a difference!)

Learn to Use Feedback

At the early stages of adoption, the recommended practices are oriented toward practical “hygiene” and safety, and are not controversial, abstract, or rely on delayed gratification. These first practices are immediate and useful, and chiefly serve to introduce the idea that you can try stuff before committing to it, and build and deploy reliably. This approach establishes a baseline environment where you have control over adopting practices, modifying them, or rejecting them—and are even encouraged to do so. (Oh, and as you might guess, the recommended practices themselves change as the team and organization gain skill and grow; it's not static).

We want to help teach people and get them used to the idea of expecting and acting on feedback, with a short feedback loop. But that’s the easy part.

The harder part comes in evaluating feedback. At these early stages, GROWS specifies very concrete, unambiguous feedback to look for. Later on, at higher skill stages, that process gets a lot more interesting, and a lot more difficult. But by then the team and other participants have built up trust and a familiar habit in seeking and applying feedback, which makes it easier to work together when the harder issues come up.

This is an Experiment

The idea of GROWS is, itself, an experiment. Any or all of these ideas may not work in any particular context. And that actually is the whole point. We have tried some of this and are trying more and more. We’ll be publishing more information on the method itself, the practices and the experiments shortly.

We’re gathering feedback, evaluating the results, and adjusting. We hope you’ll join us at growsmethod.com.

“Do not be too timid and squeamish about your actions. All life is an experiment. The more experiments you make the better.” — Ralph Waldo Emerson

(See the first part of this series, The Failure of Agile.)

—Andy Hunt

The Failure of Agile

I am proud to be one of the 17 founders/authors of the The Agile Manifesto back in 2001. I think it provided a jolt of energy, hope of a better way of doing things, of creating software and making the world work better. It was a pivotal turning point.

But in the 14 years since then, we‘ve lost our way. The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they've forgotten their aim.

And worst of all, agile methods themselves have not been agile. Now there‘s an irony for you.

How did we get into this mess?

The Joy of Rules

The basis of an agile approach is to embrace change; to be aware of changes to the product under development, the needs and wishes of the users, the environment, the competition, the market, the technology; all of these can be volatile fountains of change. To embrace the flood of changes, agile methods advise us to “inspect and adapt.” That is, to figure out what‘s changed and adapt to it by changing our methods, refactoring our code, collaborating with our customers, and so on.

But most agile adopters simply can‘t do that, for a very good reason.

When you are first learning a new skill—a new programming language, or a new technique, or a new development method—you do not yet have the experience, mental models, or ability to handle an abstract concept such as “inspect and adapt.” Those abilities are only present in practitioners with much more experience, at higher skill levels (see my article Why Johnny Can't be Agile for more).

The only way for beginners to be effective is to follow simple, context-free rules; rules of the form: ”When this happens, do that.” And since agile methods conveniently provide some concrete practices to start with, new teams latch on to those, or part of those, and get stuck there.

So instead of looking up to the agile principles and the abstract ideas of the agile manifesto, folks get as far as the perceived iron rules of a set of practices, and no further.

Agile methods ask practitioners to think, and frankly, that‘s a hard sell. It is far more comfortable to simply follow what rules are given and claim you're “doing it by the book.” It’s easy, it’s safe from ridicule or recrimination; you won’t get fired for it. While we might publicly decry the narrow confines of a set of rules, there is safety and comfort there. But of course, to be agile—or effective—isn’t about comfort (see my article Uncomfortable with Agile).

And if you only pick a handful of rules that you feel like following, and ignore the hard ones, then you’ve got it made! You are ”doing agile” if anyone asks, and you can focus your energy on enforcing a small set of largely useless rules. Everyone feels better. Until it’s time to actually ship something.

Stuck in a Concrete Rut

Following a rigid set of rules limits your performance to that of a novice (see my book Pragmatic Thinking & Learning: Refactor your Wetware for more). So teams find themselves unknowingly stuck in a rut: blindly following the concrete rules, not gaining the experience they need to get to the point where they know they need to move beyond the rules.

It’s all too common these days to see arguments on Twitter or mailing lists with these rules-bound zealots arguing that ”you’re not agile” because you aren’t following the rules to their satisfaction.

What happened to the idea of inspect and adapt? What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand? The canonical agile practices of popular methods have remained essentially unchanged for over a decade. We are stuck in a rut.

And as I’m fond of saying, the only difference between a rut and a grave is the dimensions.

A Way Forward

Now there have been many folks complaining about the agile movement, some quietly, some loudly, and none of these complaints are novel. But here‘s a new twist: let‘s fix it. Right here, right now. Together, we can fix the inherent problems in agile adoption and evolution and help move the industry forward.

First off, we need a name. A loose collection of good ideas doesn‘t generally get much traction in the world. There has to a be a name, a brand, to hang it on. Let's call it:

The GROWS™ Method.

GROWS in this case is an acronym, for GRowing Real-World Oriented Working Systems. It's an idea Jared Richardson and I (Andy Hunt) have been working on.

These seem like important concepts: software is not designed and built; that’s far too a deterministic, linear model that doesn’t work here. Growing is a better metaphor, because with growth comes change. Real-world oriented is a nod to the idea that we need to base all our decisions and direction on actual evidence: feedback from the real world, under actual conditions. Anything else is just some unfortunate combination of a fantasy and wishful thinking. And of course, working software, our ultimate deliverable. But not at the expense of a working, functional team and overall organization. The software, the team, the users, the sponsors all form one system. And we need to make sure the whole system works, for all the participants.

So let’s base our ”new” method on four foundational ideas:

1. Evidence-based
2. Dreyfus Skill Model
3. Local Adaptation
4. All-Inclusive

That is, every team should be able to inspect and adapt based on actual evidence, on real-world feedback. But to get them there, we need to use the lessons of the Dreyfus Skill Model to provide support for beginners and latitude for more advanced practitioners. With that framework in place, we can position every team to adapt themselves to local conditions, safely, based on actual evidence. And finally, whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors. There is no ”us” versus ”them.” There is only us.

In the next post, I'll take a closer look at each of these foundational ideas.

If you find this sort of thing interesting, please join us at growsmethod.com and sign up for our mailing list.

With your help, we can fix this thing.

—Andy Hunt

Now read Part 2 of this series: http://blog.toolshed.com/2015/05/its-an-experiment.html

L-mode/R-mode and the Default Mode Network (DMN)

My book Pragmatic Thinking & Learning was published back in 2008, and I'm delighted to report that I still receive letters from readers ever week, reporting how that book has changed the lives for the better.  That's pretty cool.

 

And occasionally I get asked questions about how the book came about, and what's changed since then.  Here are a few answers.

 

Like many programmers and other technical workers, I have no skill whatsoever at visual arts such as drawing or painting.  The book Drawing on the Right Side of the Brain has long been highly recommended for novice artists, so one day I started reading it.  One of the main premises of that book is that the interference between linear and rich modes in the brain is why so many of us technical types have trouble drawing, and in general have trouble accessing our rich-mode, pre-conscious, asynchronous mental processes.

Now that book has been around a long time, and draws on Sperry's original research from the 1960's, so it refers to these mental processes in the original "left-brain/right-brain" parlance, which is not technically accurate: these processes are not strictly hemispherically divided.  But the observation of interference between these modes remains valid, as we continue to better understand the underlying mechanisms.

 

Drawing on the Right Side of the Brain made the critical observation that L-mode interferes with and suppresses R-mode, which inhibits your ability to "see" due to excessive symbolic reduction from L-mode processes.  Now the book explains this in terms of a bilateral, hemispheric distinction which we know is not physically correct.  But that doesn't change the outcome: that book has helped perhaps millions of people learn to draw and to be more creative.

So I came up with naming these mental processes "linear-mode" and "rich-mode", which had the advantage of retaining the L-mode and R-mode abbreviations, while moving away from the misleadingly simplistic right/left brain, hemispheric duality.

 

Since Pragmatic Thinking & Learning was first published, research has continued and I'd like to think we have a better overall understanding of the brain. In particular, the original, crude idea of "left and right brain" thinking is better explained by looking at cooperating regions of the brain that activate together as a network.

 

There are some 7 or more identified networks in the brain, including the Executive Attention Network (EAN) and the Default Mode Network (DMN).  The DMN consists of some 10 or so distinct areas of the brain and yes, they are spread all over both hemispheres.

 

The EAN is associated with focused, linear thought.  The DMN is more of an "idle loop", if you will, that takes the mental stage when the EAN is inactive.  Based on current literature, it seems pretty clear that the EAN/DMN distinction is a better physical explanation for the observed phenomena I've been calling L-mode and R-mode.

 

It's possible that what we observe and name "rich mode" might encompass more than just the DMN, and involve some of the other non-EAN networks in the brain. As research continues, I'm sure we'll continue to get a better and better understanding of how the processes in the brain coordinate to handle different cognitive demands.  So along the way we may well need to adjust our terminology and our thinking.

And some people get really hung up on that.  But the fact is that no, we really don't have a firm idea of how the brain actually works.  It's a complicated, self-modifying mess. We've got a good start on it, and we're learning and researching more all the time.  But clearly we can take advantage of what we know of the brain already, even as the explanations become more refined and more robust as we go along.

As far as my own creative process goes, I'm a big fan of doodling and mindmaps.  I like to leave a mindmap open on my desk, so that when the asynchronous, background mental processes decides to throw something over the fence, I can capture it and begin working with it.

Henri Poincaré's method works well for me: push the problem out of your foreground mind, and just "hold it lightly."  Then go for a walk, etc.  That's when insights and breakthroughs come to me.

Having authored nine books and tons of programming code over the years, I have to say it really does work ;)

/\ndy

Author, Publisher, Speaker, Programmer.