There's an online Agile Alliance panel coming up, the topic is "A New Age of XP."

I'm looking forward to hearing what others have encountered, but I also realized that they may influence my opinion. So, before that happens, I wanted to write down some older observations of what I like to call "Doubly Extreme Agile."

A few notes before I get into describing Doubly Extreme Agile:

1. My friend and colleague Peter Green came up with the name on the spot, after I described these observations to him.

2. These truly are observations from a handful of disparate clients. I've not invented this flavor of Agile methodology by running thought-experiments in my head, or by cramming every great “Agile” idea into a big box and slapping a logo onto the side. I don't claim to be its inventor, and I have no plans to promote or license it like some sort of off-the-shelf one-size-fits-all solution.

3. I'm not trying to market this as The One True Agile, or take over the hearts and minds of the Agile community, or replace Scrum as the dominant framework. (Though, as you'll see, it's often the product of starting with Scrum, and adhering to well-known and oft-quoted Agile principles.)

I have built a course/coaching curriculum that could be used to give teams the practices and experiences necessary to implement Doubly Extreme Agile for themselves (see Whole-Team Essentials for details). As of today, it's never been run, but it was cobbled together mostly from my Behavior Driven Development Essentials course, and bits and pieces of other courses (e.g., the Kanban flavor of my old Essential Agile Principles & Practices course). So, I'm fairly confident it would be beneficial to a team or small shop of multiple teams. However, I do have prerequisites…

4. "Does it scale?" Probably as well as any other Agile framework. Having twice worked with an XP team of 6-12 people who were able to accomplish what 100+ overpriced and underpaid Big-Consulting-Firm contractors could not, I really have to wonder if scaling teams is really in anyone's best interest. If you want to increase the throughput of value, then sure, I can likely help with that.

5. I’m using mostly Scrum terminology, below, because most people are familiar with Scrum. E.g., PO = Product Owner (aka Product Advocate), sprint (aka iteration), PBI = Product Backlog Item (aka user story or work-item), Backlog (aka queue).

How Doubly Extreme Agile was Born

I first started teaching Behavior Driven Development (BDD) with Richard Lawrence, author of Behavior Driven Development with Cucumber. In his course, the whole team (dev, test, BAs, the PO, ...) eventually sits together and works through one Gherkin scenario at a time. And when I say "works through" I mean they get it passing via the system under test before moving on. Sometimes they split up into pairs. Typically the pair is comprised of a tester and a developer. Sometimes two developers will pair up on a more challenging scenario, and use Test-Driven Development (TDD) to build up the code required to get the scenario to pass.

As part of the BDD training "package" we would return a month or six later, to help out with any challenges the teams had encountered. Often, these teams were still operating in a similar fashion: Often pairing up, often as a whole ensemble, to build new features. This whole-team approach is called "Mob Programming," but Maaret Pyhäjärvi & Denise Yu have proposed “Ensemble” because it translates much more politely into most languages and cultures (including US English!)

I also had two other clients, who were already Ensemble Programming, and who wanted training or coaching in something besides BDD. One wanted to learn TDD, but then saw value in using Cucumber to create their business-readable product specifications, so we “pivoted” to BDD. Another wanted some brief training in refactoring and Design Patterns, and they shared with me that they had been exploring BDD, and already had a long history of using TDD.

So it seemed that all these clients had decided to combine Ensemble Programming & BDD for the long term.

The Gradual Dissolution of Scrum

It's important that I convey just how “intrusive” a healthy BDD practice can be. If done well, BDD takes over most of your sprint. (That’s a good thing, which is why “intrusive” is in quotes. I checked a thesaurus, but could find no word that put a positive spin on this.) The whole team collaborates closely to identify and refine scenarios (aka examples), to get small scenarios working immediately, and to experiment with the deployable-quality product in creative, exploratory ways.

Apparently these teams—usually when this coach wasn't looking—found that they no longer needed much time for planning or backlog refinement. They're continuously prioritizing, working on the most important stuff, analyzing and breaking down feature requests as they go.

Those requests sometimes translate directly into examples/scenarios. One can imagine that business-facing PBIs (e.g., user stories) dissolve away into well-written Gherkin (Cucumber's testing language) examples/scenarios. Planning thus becomes a true "pull" practice: when ready, the team asks for the next request(s). The PO or BAs are right there to respond to questions. The time needed to plan goes from hours-per-week to minutes-per-day.

Each feature or set of changes can be reviewed and explored immediately. Alterations to the way the team is operating can be tried out for half a day, with a mini-retrospective occurring at lunch, or first thing each morning. Or every couple of hours. Or, whenever the team wants to try something innovative.

If your whole team is, for the most part, sitting together (or on a continuous Zoom or Teams session) all day, do they need a formal "daily scrum"? The Ensemble teams I've talked with tell me that they all know how everyone else is doing vis-à-vis stories and tasks. All the time.

The Scrum ceremonies are all there, they've just become nearly continuous; just like how the XP developer-practices made testing, designing, coding, code reviews, and integration extreme-ly continuous and collaborative.

Is it Kanban or Scrum?

Our work-lives naturally have two significant timeboxes built in: The day, and the week. So Kanban teams already have a timebox, known as a day. (Some teams are in such different timezones that they cover the whole 24 hours, but—optimally—different geographies are represented as different teams, and perhaps different columns on the Kanban board.)

And Scrum teams can have day-long or week-long sprints without losing any of that Scrummy goodness. My very first XP team in 1998 had day-long iterations (sprints). My first coach, Fred George, liked to go all-in on the whole "eXtreme" thing!

Another old practice that ends with the Ensemble is assigning tasks or (worse!) stories to individuals. “Agile” has always been radically team-centric. The team’s goal is to complete stories. Tasks can be used as reminders to the team of specific things that have to happen for that story to be completed. Tasks are of, by, and for the team. No one but the team needs to track them. In fact, tracking tasks reduces their effectiveness as reminders. Kanban coaches suggest we look at the board from right to left, then in priority order (usually top to bottom). In that way, teams finish stuff.

I suppose Doubly Extreme Agile is a blend, but if you take it to its extreme (asymptote? limit?), it would be easier to model the whole value-stream as a Kanban board. Then the whole, cross-functional team can see what needs to be done today; plus look for columns that are getting stopped-up with too many tickets/PBIs. They can adjust their “way” and try new “ways.” They’ll “inspect & adapt.”

Doubly Extreme Agile, Served Deconstructed

To summarize the ingredients of Doubly Extreme Agile: It’s primarily Behavior Driven Development & Ensemble (née “Mob”) Programming, with an overarching Kanban framework. Also included were:

• Frequent retrospectives: This is the defining Agile practice! These teams didn’t balk at having them. Retros were brief, and informal. The team examined the way they build things, what challenges might be holding them back, and what experiments they could try in order to increase the flow of business value. These events were never boring, blamestorm-y, or sickly-sweet.

• Buffer Time: You may remember this as “slack,” but that’s another word that carried too much heavy baggage. Also known as Google’s (sadly cancelled) “20% Rule.” I took the term “Buffer Time” from two sources: Greg McKeown’s Essentialism; and the Star Trek: Lower Decks episode entitled “Temporal Edict” (S1E3). Both sources are highly recommended as study guides for what can happen when this practice is neglected.

• TDD as an as-needed inner dev loop within the whole-team BDD cycle.

• Diligent refactoring (also included in the BDD cycle) as the principle software design activity.

• Pair Programming as part of Ensemble Programming: There are very few rules to Ensemble, but typically there is a driver, navigator, and “the mob.”

• Collective stewardship of the code, and the stories.

• Trunk-Based Development: The team pushes their completed work to the repo trunk very frequently. This is also known as XP’s Continuous Integration (CI), but that latter term is often misunderstood, seems to imply (incorrectly) that a tool will take care of everything, and isn’t as critical when there’s only a single active branch at any given moment. In other words, CI without any risk of merge conflicts is simply Trunk-Based.

How is it Doubly Extreme?

When Peter Green said that phrase, I think we both assumed he was just being funny and clever (as he is frequently both of those things). That would have been good enough. But the phrase eventually seemed more appropriate than expected.

As Kent Beck said when explaining the "extreme" part of the "Extreme Programming" name, we're taking a good practice and turning the knob all the way to 10.

In Doubly Extreme Agile, not only are the XP development practices such as TDD, pairing, refactoring, and CI all present; but collaborative practices are also taken to the extreme. If we embrace whole-team/ensemble techniques, then all traditionally discrete Scrum/XP events and activities—such as planning, refinement, review, and retrospective—are also nearly continuous. Essentially, good communication and collaboration practices have been “turned up to 10.”

The One True Agile?

Nope. Because we never stop improving. Think about the state of "Agile" 20 years ago, and how many practices have since been dropped, improved, [abused, misused,] or introduced?

Since what I've described here are emergent behaviors that I've observed in a handful of my most innovative clients, I'm assuming that someone will eventually supplant this “methodology” with something even better. I’m looking forward to that day.