Collaboration vs Increment?

When I was blurting about the Increment as the most important thing, just the other day, GeePaw Hill mused about collaboration as the most important thing. Today, I’ll muse on that and his notion of makers-making-made.

It’s certainly no secret that I believe that producing a running, tested, working, shippable, …, version of the product, in every single Sprint or iteration, is a critical component to success in a Real Agile or Faux-Agile situation. I’ve written about it incessantly, including recently.

As I was doing that, my colleague GeePaw Hill wrote a couple of his Twitter muses on collaboration. He pines for the days when those of us learning / doing / creating “Agile” worked closely together, when we all knew each other, and, as he put it “our collaborations then were energetic, energized, opportunistic, warm, and sometimes hot”.

GeePaw rightly values that kind of connection, that kind of energy, and wants that sort of thing for himself and for everyone. He closes with this:

And it’s important to say that collaborations like that are both how I want to change the world and what I want the world changed into.

Today, I want to try to reconcile, in my own mind if not yours, the importance of collaboration with the importance of the Increment. In so doing, I need to try to express some differences between my focus and philosophy and GeePaw’s. I will freely state here that what I say about either of us is only my current guess, and I deeply respect all the views I’ll express here.

My focus is on Real Agile, the ideas that have grown out of the Agile Manifesto, and on the use of those ideas in software development.

GeePaw doesn’t even like to use the word “Agile”, I think because he feels that it has been contaminated in at least a couple of ways. It has been co-opted by the money-changers in the temple, so using the term might wrongly connect ideas to the wrong agencies. But I think there’s more: GeePaw seems to have less faith in just doing things than I have. Let me try to talk about that.

I believe that mindful practice of things like TDD and refactoring, mindful use of retrospectives and planning meetings, mindful execution of various “agile” practices teaches us what we need to know. For example, if we really pay attention to Beck’s four rules of simple design¹ as we program, we learn how powerful they are, and we learn better design.

I believe that for the best of reasons: it has worked for me. I’ve spent many hours TDDing, refactoring, coaching, and paying attention to what has happened, and I’ve learned a thing or two. So I assume that others can do the same.

But that viewpoint is … how can I best put this … very instrumental, very focused on doing (with lots of associated thinking). This gives me great confidence that if a team’s interest can be sparked in TDD/Refactoring, they can and likely will learn to build sustainable code.

That is a big leap of faith, let’s face it, and I believe that GeePaw doesn’t make that leap. He certainly teaches those things, surely better than I do, but I think he doesn’t believe good things will just happen in the way that I do. And I think … though he’s not here to ask … that part of his focus on collaboration is the recognition that without a whole team focus on matters, there’s not likely to be much learning going on.

Put that way, I have to believe it. My “easy answer” is that one of the things we learn to do mindfully is pair programming or the more modern mob programming. Both of these are of course exactly about collaboration. So when I coach a team or teach a course, collaboration is an integral part of what I work to bring about. A team of good TDDers working alone isn’t a team at all.

Makers Making the Made

GeePaw has also written many times using the terms “makers”, “making”, and the “made”. This is a lovely construction, not least because it resolves the biggest flaw in XP and Scrum, the apparent separation of the “Product Owner” or “Customer” from “Development”. We all know that the best work happens when the “business” people and “developers” collaborate: the Manifesto demands it. But those processes, as defined so many years ago, perpetuated a divide between business and development.²

In GeePaw’s model – as I understand it, mind you – the “makers” are all the people who come together to create the product, the “made”. They are business people, analysts, programmers, testers, lawyers, trapeze artists, whatever it takes to make up the cross-functional team that’s needed in order to build the “made”.

And, of course, the activity in which those people engage is “making”. It’s the meetings, the programming, the testing, the conversations, the arguments, everything that goes into building the “made”. It is, in a word, collaboration.

Done right, it is radical collaboration, far more complete and intimate than a couple of refinement sessions, a planning meeting, a review, and a retrospective. It is full-on working together.

Collaboration.

I’m convinced

So, yes, I’ve convinced myself. Whether I’ve fairly represented GeePaw’s ideas, I cannot say. I’ve pretty fairly represented the ideas that are in my head, formed by 8 decades of input including a few words of his.

The thing that makes Agile really sing is a full-on radical collaboration between the makers, who are actively making the made.

“But Ron, what about the Increment? You said that was all important.”

Yes, and it is. This is the proverbial three-legged stool. Its purpose (I imagine) is to get the product, the made. To do that best, we need the makers, fully and actively engaged in the making. Let’s explore each of those just a bit, and connect them back to Real and Faux-Agile ideas.

Makers

These are the people who make up what XP calls the Whole Team, what Scrum calls the Scrum Team. For best results, you need to have all the skills needed to build the made on the team. Otherwise, you really can’t make it, you’re waiting for someone else.

The makers are Product Owner, Customer, Tester, Programmer, DBA, Analyst. Better yet, they are people with product knowledge, user knowledge, testing knowledge, programming knowledge, database knowledge, analysis knowledge. They are the people you need. They are the makers.

Making

These are the activities, large and small, that you engage in as you build the made. They are meetings, conversations, mobbing, pairing, coding, testing, designing, analyzing, writing, and so on. Making encompasses the actual application of all the skills you need in order to create the made.

the Made

The made, when you’re done, will be the product you set out to produce. And for best results, I hold that you can’t just build and build and build and have nothing for six months and then Voila! on the 180th day have a product. Things go best when you have a little bitty baby product in the first week, and a better one the second, better the next and the next and the next. Things go best when that little made thing is entirely ready to go, with each of the features done so far fully operational and able to be used.

My life experience has taught me that this is the most important thing – for me.

I’ve always had good luck getting teams fired up and ready to collaborate, and I know more about how to do that than I used to. Where I got in trouble always seemed to be that because the product was only going to come together at the end, everyone’s confidence tended to degrade over time. Sometimes we got the product out before confidence ran out and we survived but with a lot of bad taste in everyone’s mouth. Sometimes, confidence ran out first, and there I was, demoted again. I never did come to like that.

TL;DR

We need three things to thrive with Agile: Makers, Making the Made. Without any one of them we have nothing. Makers are the skill-bearers; Making is the intensely collaborative process of doing the work; the Made is the growing product we’re creating.

We need all of those. If only one is missing, of course we’ll work to get it. If two or more are incomplete, we work on that.

My personal interest is mostly in the Making of the Made, the actual programming bits, and I want us to see the Made all the time. GeePaw’s focus is a bit different, I think. But I think we agree on this:

Makers, Making the Made, in deep, radical collaboration. That’s where it’s at.