I’ve spoken about this before , and surely will do so again. This entry brought to you by:

  • The Increment: A while back, I was ranting pointing out to the Scrum trainers and coaches that a common element in failed or flaccid Scrum was that the team was not producing an increment of tested integrated software as Scrum requires. Some trainers and coaches replied that no, the biggest problem was that the culture was not supportive of Scrum.

  • Toxic Scrum Projects: Prior to that, I received a great deal of flak from Mr Bowkett , who took legitimate exception to how I expressed my belief that they weren’t “doing it right” on their quite toxic project.

  • More Toxic Projects: Just a day or so ago, a valued Twitter associate was describing a truly vicious situation which caused her to leave a situation, and said that no woman could have done anything to change the horrible culture.

  • Coding: This morning, another group of wonderful Twitter associates had an exchange that led to one coach saying that they found it odd that an Agile coach would be afraid to code, and another referring to coding as fetishizing one skill above others.

This may seem controversial …

… but I think that there is only one skill that is truly essential to developing software, namely the ability to code (and to do it reasonably well).

Now, the truth is that walking isn’t just one skill, and neither is developing working software. Nonetheless, if you can’t code, you can’t develop software.

Can you develop software without analysis? Yes, but not much of it, and it may make little sense, and probably no one will like it. But you can.

Can you develop software without testing? Yes. It almost certainly won’t do what you intended, but you can. (And IBM Cleanroom showed decades ago that you can produce code that works without testing.)

Can you develop software without good communication skills? Yes, although you’ll find your ability to work in team limited, unless you find a bunch of very tolerant good listeners to work with.

Can you, personally, develop software without coding? Well, you can quibble with me about AppleScript and various tools that turn drawings into software, and the like. But really, the answer is no. If you can’t code, you can’t really develop software.

Why is this important? Why is it even interesting?

Well, Bunky, it’s important because when we said “Working software over comprehensive documentation”, we really meant it. When we said “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, we really meant it.

It’s important because Scrum really meant it when it said that the Dev Team delivers a tested increment of potentially shippable software at the end of every Sprint.

And it’s important because working code can change the culture.

Mind you, I’m not guaranteeing that if the team would just produce a working increment of software every two weeks, everything would be hunky-dory and that jerk manager would become less of a jerk, but it gives you a chance. Here are some ways an Increment might help:

What if they ask for everything?

The People With Requirements always want everything. I’ve written elsewhere that this is a good thing, in that when you are figuring out your product, you really should think of everything. Unfortunately you can’t actually have everything, and often managers accept the list of everything and then demand everything. This delays the release (until they finally give up without everything) and demanding stuff is really irritating to those of us who build stuff.

The Increment helps this way. It’s done. You could ship it. There’s only one reason you wouldn’t ship it: it needs at least one feature that it doesn’t have. But you could ship it.

This fact can be used to change the focus of the Powers from “give me everything” to “what’s next”. We can have conversations that weren’t possible before:

So, yes, it needs more. What’s the most important thing to add next?

I need everything.

Yes. What shall we do next?

I don’t have time for this. Do anything. I need it all.

OK, we’ll do this stupid thing here.

No, not that!

OK, what then?

(Real conversation begins.)

This may not work the first time. If they won’t answer, do the stupid thing and show it to them next week. With any luck they’ll get the drift that the need to steer by selecting what’s next.

What if they demand that you go faster?

When you’re not showing working software, everyone is impatient. Frankly, they’re afraid you’ll never get done. When you’re showing working software – software that is done but incomplete – things change. They’ll still wish you could go faster but you can have this kind of conversation:

Here’s the next increment. We added A, B, and C, just like we agreed.

I need more stuff. You have to go faster.

We’re going as fast as we know how. You’d be wise to assume this is the pace we’re going at and plan for it.

Go faster!

We’ll try. Meanwhile, these are the facts. It might be good to use them for planning.

If you don’t go faster, I’ll fire you!

Well, you can do that but if you do things will go even slower, with no one working and all. It might be best to plan for this rate of speed. We continue to try to go faster but these are the facts.

Work more hours!

Here’s a graph of how many hours we worked and how many features we got done and how many bugs were found in them. We seem to perform best about here on the graph. We could work way out here but it looks like you’d get more bugs and less done. Which would you prefer?

(and so on)

Here again, a sufficiently bad manager will continue to be bad. But the fact is, most people aren’t just bad, they’re doing the best they can in a situation where they have insufficient information and a lot of fear. Giving them better information can reduce their fear and thereby give them room to make better decisions.

Think about it yourself …

What weird management or colleague behaviors might be improved with the ability to show them working software, and frame a discussion around it? I think you’ll find a lot of them could. If you can’t think of ways to use the Increment to help change things, ask me. Maybe I can.

Changing process enables changing culture

If we change what we do, we change what happens. With some effort, some conversation, we can change what others think what others feel, and what others do.

The Increment can help us change culture. Agile can help us change culture. It’s not magic: it’s still hard work. But we do have more options.

And without code, you’re not going to get any software, no matter what you do. So build the code as we suggest, and use it as the center for conversations.

If you’re not doing that, you’re not doing Scrum, and you’re not doing Agile.