From today's memo pile

We’re not a Scrum shop. We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do. Here’s how to make the Scrum meetings Not Suck.

To: Everyone
From: Mark

A note on process…

…as well as a reminder of today’s Weekly Scrum meeting. I’m notifying everyone (including executives and non-technical managers) because you’re all invited to join today’s meeting as chickens, and because you might be interested in the process summary. If this stuff bores you, sorry about that. [And something about how to turn off the notifications.]

First off, the Scrum will start at 5pm. If other “pigs” will be in the office I will join you, so let me know. But we will also be on Skype (where I’m MarkWSchumann). Other pigs are: [names elided]

If you care to join the Scrum as a chicken (i.e., involved but not committed), that’s fine–let me know and we’ll include you.

End of announcement. Beginning of process talk.

For those newly tuning in or just standing by, the Scrum meeting is really really simple. Everyone in turn answers Three Questions:

  1. What did you get done since the last Scrum meeting?
  2. What do you plan to do before the next Scrum meeting?
  3. What obstacles do you have?

I’m gonna say something here.

The answers to these questions are often a variation on “I screwed up, and this is how I screwed up, and this is how it’s affecting my team.” Let me be clear about one thing: The process doesn’t work if you can’t be totally honest. Okay, two things: People aren’t gonna be totally honest next week if you make them regret this week’s honesty.

So if Alice admits she caused a blockage because she bit off more than she could chew, no fair scolding her about the same exact thing on Monday. She already spilled her guts. Don’t make her do it again. (She’ll wonder why she bothered to suffer that experience the first time if it didn’t count.) And if Bob tells you he botched some code and has to do it all over again, appreciate the fact that he said so. Don’t make it all dramatic. Just help him fix it and move on.

Got it?

And the Scrum should go really quickly–maybe about three minutes per pig I guess. And zero minutes per chicken, because chickens don’t get to talk in Scrum meetings. If an obstacle can’t be resolved instantly, we take it out of the meeting to talk about later.

This is not really a Scrum shop.

That’s been implicit all along, but now I’m actually saying it.

Scrum has burndown charts and a different kind of backlog system and an explicit kind of connection to management, among other things. We don’t need those. I think.

We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do.

I’m gonna draw everyone’s attention to the online Kanban system we have at AgileZen: [url elided] If you don’t have access to this, you should. I don’t care if you’re technically on the dev team or not–there is really one team here, and in a face-to-face workplace the Kanban would be an actual physical board placed where everyone can see it.

If you want to know why the heck stuff isn’t getting done, this would be the first place to look. That’s the transparency thing.

Very briefly, each “card” is supposed to move from the (sometimes hidden) Backlog column at way left, through the various columns, and into the (sometimes hidden) Archive column at way right. Cards edged in green are Ready to be pulled to the right. Cards edged in red are Blocked and need help.

I encourage everyone on the dev team to watch for Blocked cards throughout the board. You can often help with one that’s not currently in your own primary area of work.

Friday Night War Story

Nondisclosure agreements don’t usually come with an expiration date, but this story is so old nobody will care. Still, names have been changed to protect… oh… me.

I was doing this Clipper-on-Unix project (yes!) in 1996. It was a really big deal. The idea was to migrate a rather large vertical application from FoxPro on SCO Xenix (doesn’t that make you smile already?) to FlagShip on Linux. We would add a few major features, mainly interfaces to credit cards and some application-specific hardware. We had a few months to do it, and I was the only Clipper guy. (And by the way, can I just say that FlagShip itself was all kinds of awesome?)

Continue reading “Friday Night War Story”

Fantasy: the self-organizing team

Does it help to hand cards directly to developers and asking for status every day?

It sure does! It helps me feel super-duper important! It reassures the client that I’m in control! It reinforces my position!

It doesn’t get any more work done, but hey.

I wrote about this phenomenon in a different context about a week ago, but it’s come up again. Twice is a coincidence, three times is a pattern, right?

I was talking to a client the other day about a thousand things, in the space of half an hour. There were a few things that stung badly, but one of them was to the effect that I wasn’t managing the developers very well.

Continue reading “Fantasy: the self-organizing team”

Process, schmocess

I worry about software development shops where things are over-controlled. It indicates a lack of trust, and I can’t imagine hiring smart technical people who you don’t trust!

Today I’m talking about two different kinds of Process. On the surface they’re very different, but both kinds exist to support you and protect you. They’re also similar because some people regard them as threats or compromises.

Continue reading “Process, schmocess”

The way I do the things I do

“We’re going to tone down the panic atmosphere, whatever it takes. The next steps will be like firewalking: deliberate, calm, and quick.”

Over the past few years, I’ve studied what it means to market and sell professional services like mine. Honestly, I’m in a weird place with that, because I’m a huge geek (and still speak FORTRAN fluently) but a lot of what I do is what is sometimes, probably condescendingly, called the “soft skills” realm.

That makes it hard to answer that inevitable question, “So, what do you do?”

I used to reply with variations that started, “I’m a software developer” or “I’m a Unix guy.” But that doesn’t quite tickle the people who really need me.

Continue reading “The way I do the things I do”

The silver's all around you

Software developers always seem to be struggling with problems. That’s because everything that’s not problem-solving has been automated or solved. The only silver bullets to be made are the ones you make yourself.

This is a response to Peter Kretzman’s coherent and insightful blog post, “No silver bullets. Really!” You should go read that first. I’ll wait.

Peter’s post, in turn, is a response to the classic paper, “No Silver Bullet: Essence and Accidents of Software Engineering” by Fred Brooks, in which Brooks says that complexity in software development is essential, not accidental. You should read that too.

Now here’s what I think.

Continue reading “The silver's all around you”

The Saga of Lou

Don’t dismiss the weirdest person in the department. The weird guy may know something you don’t.

Sometimes projects are made to suck because people are cussed and they just won’t listen.

There was this time in late 1988. It was my first job out of college, with my freshly minted B.A. in Mathematics (!) and a lot of enthusiasm. It was a little financial services company just off East 9th and Euclid.

One of the first things they asked me to do was… kind of a drudge job. See, there was this database on our IBM System/38 mini. It had a file that included (among a lot of other fields) customer identifying information, balance due, and last activity date.

Continue reading “The Saga of Lou”

On dev software upgrades–when, why, how?

When do you buy and install development software upgrades? I put them off until there is some concrete benefit. Is that so wrong?

A few months ago, a client had made a few changes in some nifty little WinForms application I’d written for them and then wanted me to pick it up again from there.

I know that sounds like a nightmare, but the person who did the changes is really sharp, and he definitely improved on my work. So it wasn’t like I had to go and fix all the problems he introduced. There weren’t any.

No, I’m writing this because of a different complication.

Continue reading “On dev software upgrades–when, why, how?”