How did we get into this mess?

I’m in the midst of an email conversation with a pretty well-known turnaround CEO adviser, the kind of person who can Make Your Company Not Suck. He’s way beyond me in terms of influence and reach, and he consults enterprise-wide for way bigger outfits, but for some reason he ended up asking me why so many projects still get in trouble even though all kinds of training and certification are available these days.

This is about what I wrote back.

Continue reading How did we get into this mess?

Things learned while pairing

I spent a Sunday in January at Corey Haines’s Code Retreat, out on the LeanDog boat. Aside from being too darned early in the morning, and aside from the fact that I had to bail at the 3pm break because my kid thinks she needs a ride to college, it was a fantastic use of time.

The event is like this: You show up, hang out, grab a pair partner, and start doing test-driven development (TDD) on a specific programming problem. After forty-five minutes, you stop programming, join the big group again for a debriefing, and do it again from the beginning with a new pair partner.

And you do this like six times during the day. (I only stuck around for four iterations.)

The problem space

The actual programming problem was to mplement Conway’s Game of Life. It’s a devilishly clever assignment, partly because anyone who’s taken more than one Computer Science class thinks they’ve already solved it. But oh no.

If you don’t know about the Conway game, it’s not really a game you win or lose. You have an unlimited “board” of square cells arranged in rows and columns. Each cell is considered either “alive” or “dead.” On each “turn” every cell counts its eight immediate neighbors (including diagonals); if it has fewer than two live neighbors it “dies” of loneliness; if it has more than two live neighbors it “comes to life”; and if it has exactly two live neighbors it just stays the way it is. That is all. You just watch it go, turn after turn. It’s just cool. There is no object other than watching the patterns that “grow” from various starting configurations.

(If the above sounds like a really stupid waste of time, you are not a geek. Please find another career.)

Harder than it looks

This is actually kind of hard to implement in a real object-oriented way. How do you design your classes? Is there a Board that contains (“has-many”) an infinte number of Cell objects? That won’t work quite the way I made it sound, will it? How about keeping a collection (like a C# generic) of just the live Cells? (It’s a lot easier if you get to assume a limited playing field. But alas.)

What I learned

Somewhat importantly, Corey didn’t expect us to use any particular programming language. He encouraged us to pair with colleagues who were using languages we might not even know yet.

I learned a bit about object-oriented design, if by “learn” you mean “find things to argue with.” Briefly, master crafters like Corey seem to prefer a lot more abstraction in class design than I feel like wrapping my head around. I usually like a one-to-one relationship between code space and problem space; so to me an object is “a thing that does things,” and a class is the idea of what that object looks like and does. If I can’t think of it as a thing, it’s not an object– it’s a method. Maybe.

I didn’t get very far with my pair partners on any of the iterations. We kept getting hung up on the TDD cycle, confused with the problem space, or stuck on mundane tactical issues. In that way it was frustrating.

On the good side, I got to hang out and pair with Angela Harms on an iteration. There was a mutual aha moment when I said out loud, “A cell knows if it’s going to live or die.” Angela thought it was some Zen kind of cool. I thought I was having fun anthropomorphizing the code. We’re both right.

My man Chris Sanyk was there too. He wrote about it, and wrote about it again, and wrote about it yet one more time. Our favorite insight occurred when Corey said something about running unit tests only on public methods, which annoys me because sometimes all the interesting logic is in private methods. I was launching into a “rant” on this topic, according to Chris, when Chris simply said, “So write the test method inside your class.”

I was stunned for a moment, then opened my mouth to argue, realized what I was about to say would be wrong, then started to say something else that was wrong, and finally looked at Chris and went “aaaaaaah.”

Is that the right answer? Beats me. It’s not mainstream as far as I know. But it turned my idea of unit testing on its side.

When they won’t let you do Agile

If you’re a fan here, or if you’ve had more concrete experiences of working on Agile software teams, you probably have a good sense of how well the Agile values and practices can really work.

Problem: Not everybody sees that. Especially (perhaps) your boss or project sponsor.

Continue reading When they won’t let you do Agile

When KanBan crumples

So this week I’m seeing on the KanBan:

  • #101: “I want to be able to comment on a comment.”
  • #102: “I want to be able to post a question in response to a comment.”
  • #103: “I want to be able to post a comment or a question.”
  • #104: “I want to be able to post an answer to a question.”
  • #105: “I want to be able to comment on the conversation as a whole.”

This is oversimplified and (only very slightly) dramatized, but you see the overlap and the potential for confusion. These story cards are blocking a ton of other work that needs to be done in the next couple of weeks. And they’ve been claimed by different developers!

Continue reading When KanBan crumples

From today’s memo pile

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.

Fantasy: the self-organizing team

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

Pair programming sucks. That’s okay.

Pair programming is fundamentaly as simple as it sounds, but in practice it has many layers.

You know, one way to look at Agile is to observe that it’s simply an attitude that recognizes that software is done by real people who have complicated personalities. Tasks don’t get done just because they’re next up on the Gantt chart, they get done because a human person has his or her head together enough to think clearly and figure them out.

That’s the nature of creative work. Thus, you’ll often find that production doesn’t equal resources multiplied by time on task. If you care about your project, cultivate the conditions that help yourself and others do their best work. And pairing, done well, helps bring about such conditions.

Continue reading Pair programming sucks. That’s okay.