Postmodern Agile: A Story of Collaborating Beyond Buzzwords

The product owner (PO) arrives in the team room first thing in the morning. The team is already all there.

“Yesterday you delivered the ability to start capturing date of birth for our library patrons,” the PO says to the team. “It looks like it works great; thank you. We now want to make this feature useful by adding the ability to prevent minors from borrowing restricted materials.”

“OK, and when you say ‘materials,’ you mean movies only, right?” asks Marco, a tester.

“Right,” says the PO. “We may end up extending that later to other material types, but I wouldn’t worry about that.”

“Remember, we have both the self-scanner system and the librarian’s desktop app,” says Juna, a programmer, “so we’ll need to know what you want them each to do.”

The PO pulls up a document on the screen with the following:

Feature: age-restricted materials
Restrict minors from borrowing movies so that we don’t end up with angry parents or lawsuits

Background:
Given Johnny, age 16, a registered patron
And Sumiko, age 23, a registered patron

Scenario: Librarian restricts underage patron from borrowing materials
Given Johnny has scanned a library card
When the librarian scans the movie “50 Shades of Grey,” rated R
The system displays an error message containing the phrase “Patron underage”
And “50 Shades of Grey” is marked as available to check out

Scenario: Self-scan restricts underage patron from borrowing materials
Given Johnny has scanned a library card
When the librarian scans the movie “50 Shades of Grey,” rated R
?

“So, yeah, I’m not sure what should happen with the scanner when Johnny scans an adult flick,” the PO says.

“We could have it beep — that’s about all the noise those machines are capable of,” suggests Juna.

“We could also have it notify the desktop app, though that’s a good deal more work since we don’t have a notifications scheme built into the app,” adds Marco.

“And by ‘a good deal more work,’ you mean ‘unlikely to ship today,’ right?” asks the PO.

“Right.”

“OK, let’s come back to that. For today, just worry about the librarian app. Are there other scenarios I’m not thinking of?”

“What about the movies that aren’t rated?” asks Marco.

“Let’s stick with the status quo and assume they aren’t restricted,” says the PO. “But maybe we want a way of flagging those items as they’re checked out so that we can get some ratings on things as we go.”

“Sounds like a good discussion for another day,” says Sumir, another programmer.

“Sure, but you can do the default thing today, right?”

“Sure. This seems small enough that we should be able to ship today,” says Juna. “Let’s give this scenario the title ‘Allows underage patrons to borrow unrated movies.’ We’ll spend a few minutes later fleshing out the given-when-then steps and run it by you, but it seems fairly obvious.”

“Sounds good,” says the PO. “Just ping me if you have any questions.”

After 10 minutes, the team has a clear sense of what to work on. The product owner sits in a quiet corner of the team room, and the rest of the team gravitates toward a large monitor and camps out. They pull the latest version of the code, load the application in an IDE, and ensure all the tests are passing.

The team spends five minutes scanning through the existing feature tests around patron borrowing. They add the PO’s new “happy path” test (the one in which Johnny gets rejected from borrowing “50 Shades”) and spend 15 minutes writing the support code for it — the “glue” code that tells the testing tool how to drive the actual library system using the given-when-then verbiage. They run the test in Cucumber and note its failure.

“Fantastic; we have a failing test, we’re ready to go!” says Marco. “Let’s look at what we have currently.”

The team spends five minutes reviewing related tests at the unit (code) level.

Juna says, “Well, we already support scanning library cards and materials. Mostly we just need to worry about whether the material is restricted, whether someone is underage and how to reject a book from the checkout attempt. Those sound like the three small units of behavior we can focus on. How about we start with the age check?”

“I’m newest to the team and to test-driven development,” says Sumir, “but since you all will be driving, I’m OK with getting in the hot seat first.” Sumir grabs the keyboard and asks, “What’s our first test?”

Marco says, “Let’s start with a unit test that assumes a patron is not underage. Do you think you know how to write that, Sumir?”

“Sure,” says Sumir. “I can code most of it. But how do I write that using fluent assertions?”

Someone from the mob provides an answer to Sumir. A few minutes later, Sumir demonstrates a fleshed-out, failing test. “Your six minutes are up,” says Cressida, another tester. “I’d like to go next and get it to pass.”

The team indicates to Cressida where the change needs to go. She spends a few minutes coding and gets the test to pass. “Hmmm, that doesn’t read too well,” says Juna. The rest of the team nods in assent. Marco suggests a better phrasing of the code, and Cressida quickly makes the change, showing the unit tests passing.

The team continues to work in this manner. Everyone rotates through the hot seat for six minutes and listens as the mob tells them what to do. Their job in the hot seat is simple: Listen, and translate what the mob is saying into code. Despite calling it the “hot seat,” the stress level is low: The person typing isn’t expected to have the answers; they’re expected only to be able to translate. Newbies fare just fine because initially they are told the low-level details of what to code, and they can rapidly improve to being able to understand how to translate at a higher conceptual level.

Every once in a while someone in the hot seat gets a brilliant idea, and then the mob reminds them of the rule: They must get up and explain their idea, as part of the mob, to someone taking the hot seat.

People come and go as needed — to the restroom, to other meetings or just to take a breather. The mob manages to retain enough folks at any given moment to continually move forward with coding. The team has learned to trust each other well enough to depart from time to time or to let a team member or two represent them elsewhere. They take a break when it’s clear everyone needs one.

Eventually, after mob-test-driving in this manner for a while, the team feels like they have a complete solution. They run the feature test and aren’t surprised when it passes. They push up their code to the central repository and wait for the continuous integration server to confirm that all the tests are still passing with the changes they integrated. They run a script that pushes their changes to all the library branches.

“It’s deployed!” Juna tells the PO.

“Great,” the PO responds. “I have another related scenario for you to consider. Let’s discuss.”

The team stands up to chat with the PO about what to do in the next delivery cycle. After working this way for a few hours, the team gets together at the end of the day to discuss any nagging concerns, as well as what they thought went well.

Note what the team is not doing: They’re not trading status reports in a standup meeting. They’re not figuring out who’s pairing with whom or whose work might affect others. Beyond the rough assessment that they’ll deliver code to meet a couple new scenarios today, they’re not investing time in detailed estimation. They’re not reading documents. They’re not reviewing code produced by some subset of teammates, fixing defects found in such meetings, dealing with tracking defects or using Jira. They’re not wasting time figuring out what the existing library system code does (because they built it, made the code clear and clean when they built it, and ensured that the unit and BDD specs-by-example clearly document the existing library behaviors). They’re not hunting down QA folks engaged with other teams and other meetings. They’re not waiting for a business analyst to track down the PO to answer a question about what the system should do. And they’re not waiting for the PO to approve shipping the software. They have enough confidence in the tests. They’re not doing too much talking about “agile” or “scrums” or “stories” or whatever… they’re just doing.

Overhead and ceremony are at a minimum. Instead, the team embraces a collaborative, productive process that emphasizes delivering a quality product. “Postmodern agile” is the title of this article, but the process itself doesn’t really have a name — because it doesn’t need one.