The previous post listed a bunch of Agile tribes – those I could name off the top of my head. That order wasn’t meant to convey importance or precedence, but merely the approximate order in which I recalled encountering each of them. Since my first encounter with Agile was in the context of Extreme Programming (or XP), that’s where I’ll start, even though some may argue that the XP tribe has taken something of a back seat to the Scrum tribe in recent years (or even question whether there’s still such a thing as the XP tribe anymore – I’ll come to that).
While Extreme Programming itself was first formulated in 1998, as a tribe it reached a critical mass in 2000. It formed around a number of venues, such as the first few “XP Immersion” workshops run by ObjectMentor, the Extreme Programming mailing list (still active, though participation has dropped off sharply in the past three years), an international conference first held in June 2000 in Sardinia (still active), and perhaps most importantly Ward Cunningham’s C2 Wiki . This was seen as pivotal event for C2:
Before the ExtremeProgramming community moved in, this place was known primarily as the PortlandPatternRepository. Discussions about DesignPatterns were predominant, and a number of members of the patterns community were regular contributors. But the volume of ExtremeProgramming discussion quickly obscured the purely pattern-oriented discussion, and a number of the pattern contributors gave up on this wiki, moving off to form their own wikis (e.g. PatternStoriesWiki) or email/usenet discussion groups.
Extreme Programming discourse was characterized by vigorous rejection of entrenched divisions of labor in software development work, and equally vigorous insistence that a small set of tactics – the famous “twelve practices” – were a sufficient starting point for any team of competent software developers. (This wasn’t meant to imply dogmatic adherence; rather, the reasoning went that these practices provided “ground rules” that would guide the team in adapting to its specific circumstances.)
The XP tribe can still be said to exist today. I, for one, still identify as an XPer! More to the point, perhaps, I know of a number of development shops and startups who, while they don’t tout their adherence to XP (the time when that was a marketing advantage is past), still very much enjoy competitive success from applying most of the original practices.
However, its “jurisdiction”, so to speak, has shifted quite a lot from the early days. The early “Extreme Programmers” tended to be, as the name implied, senior technical people, sometimes with one foot in management responsibilities. This latter aspect was reflected in the “project management” side of XP. As you can see from the “subway map” visualization, though, these were largely shared with Scrum.
As its brand name lost ground to Scrum and Agile, the tribe lost the exclusive custody of many practices, such as User Stories, iterations, velocity, and so on – even refactoring, once a distinctive element of XP but nowadays considered “just good software development practice” (though, unfortunately, honored perhaps more in the breach). To the extent that it persists today, its jurisdiction has arguably narrowed down to:
This is perhaps even an overstatement, since custody of the last two is now “disputed” (in a friendly rather than a hostile sense) by other tribes: TDD by the newer Behavior-Driven Development subgroup, continuous integration by both the very active CITCON community (though I’m not sure the term “tribe” is appropriate, as the group has no rallying point, that I know of, beyond the CITCON event itself) and DevOps (which tends to fold it into the broader topic of continuous delivery).
With this first post in the “tour of the Agile tribes”, you are getting a better idea, I hope, of where this series is going: developing the idea that “Agile”, an umbrella term, is best understood by inspection, by looking at which groups of people consider themselves to be part of “Agile”. Each such group is, in turn, characterized by its efforts to develop some set of ideas that it thinks valuable and cares about, often (but not always) called “practices”.
In this view, Agile is something of a stone soup, with the Manifesto serving as the stone: maybe not particularly nourishing in itself, but remarkable in how it served as a starting point and then, as various ingredients got thrown it, blossomed into something both substantial and delicious.
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.