While it seems to me that an individual bears final responsibility for his or her own happiness, in the team or out of it, when it comes to Oppressive Agile, I think the community could help out more than we have. I’m getting a glimmer of a new understanding. (Or, possibly, a new mistake. We’ll see.)

Fundamental needs

Let’s consider a few things that seem to me to be fundamental to all the “Agile” approaches I know about.

Must improve process!

The Manifesto says:

  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The team must look at its past behavior and results, and work to improve its process. No one in the business imagines that a team will start off with perfect results. “Agile” is a game of continually perfecting, not a game of perfect.

Even the most specific, detailed, and demanding “Agile” method (DSDM, SAFe, DAD, pick your favorite) only describes a framework of activities within which the team actually does it work. Inside that framework, you still have to do important, unspecified technical things, like write and test the software. You also have to do important, unspecified human things, like work effectively as a team, and that includes working effectively with your Customer, Product Owner, stakeholders, management, and everyone around you.

The team cannot thrive if they do not continually work to improve.

Must deliver!

The Manifesto says:

  • Early and continuous delivery of valuable software …
  • Working software is the primary measure of progress …
  • Deliver working software frequently …

The fundamental delivery responsibility of an “Agile” development team is to deliver running tested software every iteration. (Scrum translation: Product Increment every Sprint.)

One of the main reasons why this is a must is that working software is the best form of evidence that we’re doing what we’ve set out to do, and it’s the best thing to evaluate to see how we’re doing.

We build trust between developers and their stakeholders by showing them the software we have built, software that they have asked for. When they see what we’ve done, they can learn to do a better job of asking, and they can better plan what to do. They can even decide to give the software to people who can evaluate it, or even pay for it!

They can only do this if we provide early and continuous delivery of working software. Visible software is the foundation for effective collaboration with our stakeholders.

Must have the technical chops!

We have to be good enough to deliver working software, week in and week out. This isn’t incredibly hard, but it does seem to require certain practices, such as testing within the team, refactoring, continuous integration, and the like. However a team chooses to do this, they have to be able to build integrated tested software every couple of weeks.

The Manifesto says:

  • Continuous attention to technical excellence and good design enhances agility.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

You can quibble with me about whether unit testing is a good idea, whether TDD works, and so on. I don’t care. I’ll show you how I do it, explain how I do it, tell you what happens when I do it, and give you a chance to practice it. If you can deliver working tested software every two weeks in some other way, great, do it that way. I’d like to know how you do it but if you can do it, that’s great.

However you do it, you’ll have to be technically quite capable. This should not be a problem: presumably you got into this line of work to get good at it.

Must work together!

Here’s the rub for most Oppressive Agile situations. The whole team, developers and product owners and managers and whoever all are not working effectively together. Are your planning meetings running four hours with bad plans coming out? That would not be effective working together. Is your 15 minute stand-up taking an hour and a half while your manager sits and judges? Not effective working together.

The Manifesto says:

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

If these things aren’t happening, you’re not there yet. You need to keep working. And you may need help. Read on.

It’s in the book

Call it No True Scotsman if you wish, but if your project isn’t succeeding yet at doing the things above, you’re not there yet. And your job is to get there. Your job is to reflect on how to get there, and adjust your behavior.

However, we could be helping more.

A realization …

As I think about all the tsuris I’ve been reading and writing about lately, I’m coming to a realization.

“We are uncovering better ways of developing software by doing it and helping others do it.”

Those of us who started this ball rolling based our advice on real projects we had all seen. We’ve done this. We’ve had teams working by these value and principles, and we’ve seen it work, time and time again.

From the viewpoint of a programmer – and after all, when it comes down to it, I’m just a programmer – it seemed as if creating the product Increment just worked, if only you could build it.

You built the Increment. The customer saw what you had done. She appreciated the work and saw how fast you were going. She sat in or near the room, so she knew you weren’t slacking. She heard your questions as you went along, so she learned how to answer those questions sooner.

The team came together more and more, organizing around the work. Trust built, effectiveness grew. It was great.

It seemed that the biggest problem was learning how to build the Increment. The practices of TDD, ATDD, refactoring, continuous integration were the best we knew to enable us to build software, every two weeks, at a sustainable pace, essentially forever. So we focused on those technical practices.

We “knew” that if we just built the Increment, “they” would see it, and appreciate it. We were not always right about that, and we’ll come back to that in a moment. We also knew that without the Increment, we couldn’t build the trust, improve the effectiveness. And there, I think we were right.

Sometimes, however, it just wouldn’t work. I’ve visited hundreds of programmers, tens of companies, who were having trouble. In almost every case, the team couldn’t build the Increment and the stakeholders didn’t trust them. In almost every case, when the team learned how to build the Increment, the stakeholders started to trust them.

Therefore, it seemed: learn to build the Increment and everything will be OK.

I left something out. I think all the coaches who work at this level may have left something out: we were there. We were explaining to management what the problem was. “See, the team can’t build the Increment. So you can’t see what’s going on. When they can build the Increment, you’ll be able to see what’s going on, and you’ll be better able to guide the project.”

If they let us stay, and let us get the team’s technical chops up, they did so because they had bought into the notion that the Increment would help them. Because we told them it would, we explained how it would, we showed them how the issues they were having guiding the project would be addressed by having the Increment.

We trained the non-technical people, by helping them see how the Increment could address their concerns. So when the Increments started showing up, they were ready to use them to address their concerns. They were ready.

We coaches knew how to use the Increment to create more happiness in all parts of the team. And by being there, and talking to management as well as to the developers, we left everyone knowing how to use the Increment to become more happy. When the developers began producing things that looked more like an Increment, voila! everyone was ready for it and things began to improve.

Maybe I’m dense.
   – (me)
Yeah, you’re dense.
   – (everyone else, probably)

Probably I’m the only technical coach who didn’t realize he was actually doing non-technical coaching at the same time. OK, maybe so. And maybe it doesn’t matter, because the teams who are suffering mostly don’t have coaches at all. They don’t know they need one, and maybe they’re right. If they can build the Increment, maybe they don’t need a technical coach.

But they may not know what to do now that they can build the Increment. They don’t know how to exploit it to make their lives better, and their stakeholders, never having been prepped, don’t know either.

Bridging the gap

So here’s where I think we let down the side. Or at least I did. Building the Increment seemed to be the key to solving all the problems. I came to suppose that all the team had to do was build the Increment. Heck, every time I was there, it did solve most of the issues. And in cases where they wouldn’t or couldn’t build the Increment, their problems continued.

I didn’t take into account the communication that showed the stakeholders how the Increment could help. I didn’t take into account that I showed them how to use the Increment to solve their problems. While I did explain to the developers how the Increment works from the stakeholder viewpoint, I didn’t help them learn to explain it, and they didn’t need to learn, because enough of the explaining had already been done.

I had bridged a gap without really recognizing it. (Vide supra re: “dense”.)

I believe that this gap has generally not been addressed. It has been surrounded: plenty of people will help you with communication; plenty will help you with planning; plenty will help you become nicer people; and plenty will even show you how to build the Increment if you don’t already know.

But nowhere does it say “Given that you’re learning how to build an Increment of software, even if you’re not super good at it yet, here’s how to use the Increment as a center for communication, trust building, and improved team happiness”. We never told you that. Offhand, I can’t think of a single article, anywhere, that sets out to do that. (But see below!) Some of my Kate Oneal articles may come close, but I wasn’t trying to do that when I wrote them: I was more just describing what seemed to magically happen when you got stuff done.

I resolve to start filling that gap and to trying to induce my colleagues to do so as well.

TL;DR

There’s not enough help out there for development teams, showing them how to manage and guide their relationship with their stakeholders, in particular how the product Increment can be used as a center for building understanding and rapport between developers and those they work with.

I resolve to do better and invite you to help.

James Shore reminded me of this Trust page in his excellent Art of Agile Development site, which is fairly on point. Not just what I was thinking but darn good stuff. More people should read this, and his book.