What How Why

What are you doing, Ron, how do you do it, and most of all, WHY?

I’m feeling a bit “meta” this morning, for reasons a few may suspect, and I want to see whether I can say anything reasonable about some things that are on my mind.

Democracy in Peril

Starting top down, I feel that our democracy here in the US, and elsewhere in the world, is in serious peril. Between the appeal of demagogues to a significant fraction of people, through the applied power of zillionaires whose agenda seems to be mostly to acquire more zillions, through the actions of politicians who enjoy power more than they do service, we seem to be on the path of being ruled, not served, by the few, to the disadvantage of the many.

I frankly don’t know what to do about this, beyond vote, given my leanings, abilities, and inclinations.

Scrum as Harmful

Scrum, I believe, provides at least some advantages to any organization that tries to use it, even if they use it pretty poorly. However, when Scrum is used poorly–and it very often is–it does not provide advantages to the software developers on the Scrum team.

It should. Scrum should provide them with more autonomy, in deciding how much work to take on in every Sprint, and deciding how their work is to be done. Scrum, done as it can be done, replaces pressure with a sense of what’s important, and leads to a smooth flow of software a team can be proud of.

Done as it too often is, Scrum just provides a convenient set of meetings every week or so to demand more work from the developers, to tell them in no uncertain terms what they are to do and when they are to do it.

That’s no way to live.

Defense against Scrum

I’ve written extensively about “Dark Scrum” and how developers can defend themselves against it. There’s a whole category about it

The central notion for me in defending against Scrum comes from what I would do today, in any of the high-pressure, seemingly doomed projects I’ve seen, been involved in, or, unfortunately, personally run into the ground. I would focus on one single thing:

Every product team will be responsible for having a ready-to-ship, integrated, working, tested product all the time, containing all the solutions that the team has chosen to be in the product.

It would take some serious support to make that possible, and I go into more detail in How to Impose Agile. Check that out. But that article says how I’d do it if i were in charge, so that I could constitute teams, give them what they need, empower them, protect them, and so on.

A more immediate question for many current victims of Scrum and other forms of faux-Agile, is what can they, as individuals or team members, do when the proper support and proper use of Scrum/Agile isn’t in place.

The Increment

Scrum has this structure where every week or two, you plan what you’re going to do, and at the end of the period, you review what you did and how you did it. And if there’s anything at all right about Scrum, to me it is that cycle. And my advice to developers under the thumb of Scrum¹ is to take control of that cycle and begin to deliver real working software every time around.

It won’t be easy, but if instead of focusing on doing the 300 stories they impose on you, you focused as a team on getting one of them done enough to show the program actually running and doing it, you can begin to change the conversation. To quote from Space Invaders 12:

I believe that if we have a product version always ready to go, it change the conversation with our colleagues (read: masters) on the business side of the organization, from “when are you #$%$%@! going to be done” to “you know, if we just added this one thing …”. That change in the conversation makes all the difference.

And that brings us to:

What do you do, Ron, how do you do it, and why?

I develop software right in front of you. I tell you what I’m thinking about, I show you what I do, I show you what happens, and I tell you what I think events are telling me. I try to show you how I program and why I program as I do, and to let you see what happens when I do one thing, and what happens when I do the other.

I think the pattern is clear: when I have working software and keep it working, the product grows in a pretty orderly fashion. And when I turn away from that focus, there are longer dark periods where maybe we as programmers know something good is happening–or something bad–but no one else could have a clue from the outside how things are going. They’d see no progress and that seems bad to them.

And I think it’s clear that when I am able to write small tests and move the code forward in small steps, I can make visible progress in the product every day, indeed every couple of hours. And that changes the conversation, even between me and me.

Almost every day, when I run whatever program we’re working on, I notice something about it that I think we should improve. So I focus on that and improve it. It’s all just me, but it could just as well be my “Product Owner” or whoever the powers that be are. When they see the program working, they see more clearly what should be done next.

And, when they see the program working, and responding to what they thought should be done next, they begin to work with us instead of against us. Sure, they’ll still want more, but they’ll be more able to see that we’re doing what they ask, and that we’re working as hard, and as smart, as we can. They’ll become more likely to see us as collaborators, not some kind of donkeys that have to be whipped to make them work.

It’s not perfect …

You’re right. It’s not perfect. It’s just the best I know.

But we can’t …

Maybe you’re right. Maybe you can’t deliver working software this week. I’d wager that if I were there with you, we’d find a pretty decent way to deliver working software real soon, and I’d wager that if you feel the urgency that I would in your situation, you can figure out how to do it.

But then we’d have to …

Yes. Then you’d have to learn how to do it repeatedly. You could look to my work for ideas to use and ideas to avoid. You could search out experts in TDD, in refactoring, in all the technical aspects of “Agile”, and all the human non-technical aspects as well. (We still have to be able to tell the story to our bosses. It helps to speak our truth in their language.)

So that’s what I do.

I think about programming, in the light of my main desire, to have, always, a working increment of the software, better than the week before, better than the day before, to show and tell. I do

I do the programming, using the best idea and the best will I have at the time, and I show you what I do, and I show you what happens.

I’m not here to tell you what to do. I’m here to show you what I do, tell you why I think I do it, and to let you decide that you’re going to do.

Thanks for keeping an eye on me. Let me know your thoughts. You can find a way to do that if you want to.