Recently there have been a number of posts which challenge the way agile methods have been applied in industry and present some ideas on improving adoption and outcomes by tackling the underlying problems. Andy Hunt proposes a completely new approach branded The GROWS Method(tm) and Dan Greening suggests clarifying the core concepts which underlie agile approaches as a set of agile base patterns and describing them for use. Both of these commentators are challenging the poor outcomes which have come about from a lack-lustre approach which relies on rote-learning and adherence to rules rather than adapting to the context of the specific organization and environment.
In his post "The Failure of Agile" Andy Hunt, one of the original authors and signatories of the Agile Manifesto, states that
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.
He goes on to say
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.
Rather than just complain, however, he proposes a new approach which he calls the GROWS Method(tm):
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.
In a similair vein, but with a different approach, Dan Greening has begun work on an Agile Canon, intended to be a description of the various patterns of agile adoption, using the scientific method to examine and help determine what is needed to achieve the value-based outcomes organizations are aiming for when adopting agile methods.
He says that
While agile has zealots, it is not a religion. Agile is a scientific method that converts economic chaos to profit.
However
In fairness, agile advocates can behave religiously. The popular Agile Manifesto for Software Development, used by many to define “agile”, leaves much to interpretation. The Manifesto does not explicitly discuss measurement, experimentation, or limiting work-in-process, all essential characteristics of all agile methodologies (and science, by the way). The Manifesto is not testable. The Manifesto focuses on software, yet when people outside software ask us for an agile definition, we still offer the Manifesto (and their interest immediately declines). We advocate agile methodologies as a panacea for production and market problems. We don’t proactively discuss agile’s costs, tradeoffs and sweet spots; worse, most of us don’t know them. We defend the hypothesis at all cost. Religion.
He challenges this approach and goes on to say
Though critics and friends alike spiritualize agile, agile methodologies are scientific frameworks that optimize creativity for chaotic economies. We can study these things. To be recognized as a scientific field, rather than a religion, agilists must describe their activities as science. The scientific method teaches us to observe, hypothesize, test the hypothesis and repeat. Guess what? In well-managed Scrum, Retrospective meeting participants observe and hypothesize the effects of process specifics (such as Definition of Done), Sprints test the hypothesis, and then we repeat! Every agile methodology has similar practices
He has identified a number of "Base Patterns" which are foundations for effective adoption of agile methods and has started publishing the base patterns, drawing on a wide range of branded approaches:
Agile methodologies adapt incrementally to improve chaotic economies. In analyzing this field, I am taking a “big tent” perspective on agility: if a methodology “feels agile,” I try to incorporate it. If conflicts arise, they help mark the boundaries of agile. Scrum and Lean/Kanban optimize creative production economies in general; XP (Extreme Programming) optimizes software economies in specific; Lean Startup optimizes customer marketing economies; GTD (Getting Things Done) and Pomodoro optimize personal production; Toyota Production System and XM (Extreme Manufacturing) optimize complex manufacturing; Hoshin Kanri optimizes executive strategy; the Rockefeller Habits optimize executive leadership.
Examples of his Agile Base Patterns include:
- measure economic progress
- adaptively experiment for improvement
- limit work-in-process
He says that
These three agile base patterns, present in every agile methodology, transform chaotic economies into complex adaptive profit systems.