New Framework? XP Revisited? No ...

Revision: Replaced “Style” with “Spirit”

I’m really not going to “Revisit XP”, and really not going to define a new framework, but I have been thinking a bit about what I currently believe and feel about Agile, XP, Scrum, and all that jazz. One thing I did was to post this sketch, done at the BAR on Saturday:

Now this picture just represents some random notes, and I do not claim that my views day after tomorrow will be consistent with it, nor even that it reflected my views as of last Saturday. But here are some thoughts about it:

Main Topics

Well, right then, I’ve come up with four headers, so far, under which to group ideas: Product, People, Time, and Spirit.

Product

Product is probably the central idea in my view. Kent Beck once said that all methodologies are based on fear, and my big fear is that we’ll be doing good work, that deserves understanding, support, and guidance, and that no one will know it.

So my preferences are arranged around producing a “Product Increment” frequently, and showing it to everyone who matters. We focus on frequent small releases, and continue to drive the interval between releases toward zero.

For that to work, we need to rely on and work toward simple design, which is supported by, indeed requires, as far as I know, Test-Driven Development and Refactoring. Since the system is changing all the time, I believe that it needs to be supported by automated “checks” (née “tests”). Some of these show our stakeholders that the system still works. Some of them are used to help us find defects when they do inevitably crop up. The programmer tests mostly fall out of the TDD process: we just keep them.

People

People are more important than Product, even though my view centers on the product as the focus of our work, attention, and communication. We’ll follow the XP Practice Whole Team, or the Scrum dictum that the “Dev Team” includes all the skills necessary to build the desired product increment.

We’ll surely move beyond that. We’ll want to address a connected business-side responsible person, where that’s needed. (XP Customer, Scrum Product Owner) In most companies, that’s always needed. We’ll want to address the need for real customer contact, a close connection to the real people who need to use the product or who will be impacted by it in important ways.

There’s no inherent limit to who needs to be on the team, nor to who needs to be connected. Does the product have medical implications, tax implications, legal implications? Then we need medical, tax, and legal expertise on hand. Are they in the team or auxiliary to the team? You get to decide that. There will be issues of availability, delay, the need for the team to understand details, and so on. In principle, closer is better. In practice, we can’t all marry a doctor, a lawyer, and a tax expert.

The People share Collective Ownership of the product, as collectively as possible. Within the team, the developers share the code responsibility. No “my code / your code”: all “our code”. Everyone can and should improve everything that needs it, when it needs it.

Naturally, for this to work, we need an approach to working that keeps us from standing on each others’ feet. Pair Programming and Mob Programming surely come into this. We may need a Coding Standard of some kind, maybe written, maybe just de facto.

Time

On the one hand, our Small Releases focus aims to drive the delay between having an idea and having it in the hands of the users down to zero.

But time, someone said¹, is what keeps everything from happening at once. To keep everything from happening at once in my never-to-be-written framework, I recommend Cadences. We humans use days, weeks, months and so on, as markers of events. In our framework, we’ll use those intervals for Daily Coordination, Product Review, Planning, Retrospectives, and so on.

What about Iterations (Scrum’s “Sprint”)? I personally believe that a time box, used well, provides some important learning, especially in early days. I’ve often said that if a team can’t get a solid release done in two weeks, they should do it in one week. If they can’t do it in a week, they should do it in a day. If they can’t do it in a day, they should go home and rethink their life. Well, maybe not that last thing, but the point is, learning to complete a small bit of work, really complete, inside a time box, can be a valuable way to learn.

That said, a time box surely has waste associated with it. Not everyone wants to go out drinking at noon on Friday if they’re done, and not everyone wants to start something new either. I believe, but do not know, that the right thing to do about Iterations is perhaps to start with them, but to drive them to zero length, so that folks are just pulling the next story, getting it done, and releasing it, day in and day out.

However, that grind will probably get really boring. We’ll use our Cadences for the necessary punctuation that keeps us all from going bats.

Spirit²

To me, “Agile” isn’t a set of practices. It’s what we described in the Manifesto, using Values and Principles. It’s a way of thinking, a spirit or manner of behaving. It focuses on letting responsibility and authority reside where the work is done, with support and true leadership coming from “above”. (We can debate elsewhere whether there should even be an “above”. For now, in these times, there is an above, and will be, most places, for a long time.)

For other views on this, we can look in part to Alistair Cockburn’s Heart of Agile, and Joshua Kerievskys Modern Agile.

Heart of Agile:

Modern Agile:

I note here the difference between these two names, and it is one that troubles me. To me, Heart of Agile says “Hey, amid all the confusion, here’s what it’s all about”, while Modern Agile says “Hey, Agile’s old hat, here’s a new hat”. I prefer the former. That said, both of these ideas bring out some important issues.

Of those eight items, I want to emphasize “Make Safety a Prerequisite”, as I think it is by far the most important recent addition to the spirit of Agile, and I commend Joshua and his people for it. If an organization is going to become effective using Agile approaches, people have to be safe. (Not SAFe, by the way. Just safe.)

But I digress … where we we? Oh, Spirit …

There’s more to say about “Spirit”, to draw out XP’s notion of “Sustainable Pace”. There’s of course a great deal we could say about collaboration, how to review progress and process in an environment of safety, and so on. Perhaps, in due time, if I decide to define a framework³, I’ll have more to say about “Agile Spirit”. I’ll probably have more to say even if I don’t. For now, that’s all for “Spirit”.

All The Rest

What about how to estimate value, what about how to predict when you’ll be done, what about how to test your code, what about how to lead people, what about 300 ways to run a retrospective, what about remote programmers, what about diversity, what about compassion, what about people who want anchovies on their pizza, what about the ten thousand details that are part of being effective? I have in mind that on some magical four-dimensional diagram, we might fit them all in. We might connect these to specific skills that the team may need, and we should certainly always address the Style needed to apply those skills. Let me sketch one example here, not definitively but just to start us thinking:

Our company has someone from Marketing whom they’ve placed “in charge” of the product. This person has a role called “Product Owner”, because we are Scrummish. How should they interact with the development team?

First of all, this expertise should be part of the team, not separate from it. The PO’s main job should be to help everyone on the team begin to understand what the PO does, in terms of user needs and desires. The PO should bring actual users, with real needs, to visit with the team as often as possible, so that the team can begin to understand what’s really needed. While the PO may have the authority to tell the team what to do, they should never use it. Instead, they should build a common understanding of the needs, and help the team devise valuable and creative solutions to those needs.

Summing Up - For Now …

I just wanted to say a few words about the picture I tweeted last Saturday. I can’t boil down “Agile” to four bullet points, and frankly I don’t want to. I think it is more rich than that, more nuanced. But it’s not all about practices and canned methods, either.

For now, it’s about People, Product, Time, and Spirit. Tomorrow, who knows? Stay tuned!