The W part of DTSTTCPW
A couple of weeks ago, a question turned up on the BaseCamp site we use to coordinate one of my projects. One programmer asked what we thought of a certain calculation he was setting up on the database. It had to do with accumulating “rating” points of an item in a tree-shaped threaded discussion.
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!
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:
- What did you get done since the last Scrum meeting?
- What do you plan to do before the next Scrum meeting?
- 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?)
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.
Another reason that software projects suck
Regular fans are surely aware of my “funny and accurate” (says Steve Belovich) paper on the eight reasons “Why Your Software Project Sucks.” I kept it to eight because you have to stop somewhere, and also because I have this nifty photo of myself with a “Magic 8-Ball” to go with it.
But today I’m re-encountering an issue not on my original list of eight. It’s the one where you can’t possibly fulfill expectations because the client is not your client.
The things you learn
It was something like the spring of 1984, and I was (as usual) struggling in Professor Adelberg‘s class on Series and Differential Equations. And as usual, I took advantage of his office hours, on the second floor of ARH.
I don’t remember where the proof was supposed to end up, but I had about seven handwritten pages that sort of got me there. Not quite.
Win: Cleveland GiveCamp
I’m probably just about decompressed now from the joy and struggle that is Cleveland GiveCamp. If you weren’t there, you missed a fun and exhausting time. (You also missed out on seeing me walking around with yellow CAUTION tape around my head. I’m learning to accessorize.)
How it came together
Mark tells one of THOSE stories
It is amazing how much you can accomplish when it doesn’t matter who gets the credit.
Organizing GiveCamp was like that. I was the nominal Leader of our semi-formal organizing committe, but I always cringe when saying that. Jon Stahl was the de facto leader, at least in part, because a) he’s organized big events before; b) he’s hooked up with the larger GiveCamp movement; c) he took charge of a huge portion of the logistical details; and d) it’s his boat. I’m not remotely comfortable giving orders or even strong suggestions, so it was often hard for people to tell it was “my” event. To me, “leading” stuff looks more like finding out what people need and connecting them. It’s a middle child thing.
Based on the capacity of the LeanDog boat, the organizing committee figured that 75 volunteers would be an ideal number. Working back from that, given an average of five volunteers per team, we thought it would be good to do projects for fifteen local nonprofit organizations.
Those goals turned out to be challenging. We didn’t have a surplus of applications for help from nonprofits, and while it seemed that we’d probably reach our volunteer goal we didn’t expect to go very much beyond it.
Then Margaret Bernstein visited the boat, and this article hit the Plain Dealer. Within a week, the requests came in by the dozens and we eventually received sixty-eight. About 130 volunteers registered in advance. I openly asked my fellow organizers, “How many volunteers is too many?” After all, that was nearly doubling the capacity of the boat.
And it’s a boat. It can sink.
That’s when Jon asked about using the terminal at Burke Lakefront Airport, which is less than fifty yards from where the LeanDog boat is moored. Burke said okay, and we became a two-site gathering.
Who did what
Among many, many other things that got done by other organizers:
- Andy Craze went to a zillion user group meetings to recruit volunteers, and assigned them to teams a day or two before the event;
- Larry Mingle made the Cleveland GiveCamp website;
- Matt Beyer collated all the volunteer registrations;
- Trish Rouru networked with many of our nonprofit partners, solicited food donations, and (together with Deb Stahl and Jane Winik) prepared all the meals;
- Sam Nasr served as our Sponsorship Coordinator; and
- Nick Barendt set up our fiscal sponsorship with IEEE Cleveland, talked to media people, and took care of many, many site details.
In summarizing like this I am leaving people out, and minimizing the accomplishments of those I did include. It really is amazing how much work goes into an event like this, and in the heat of getting things done it’s hard to remember who did what.
While they were not part of the organizing team, I especially want to pick out two other volunteers:
- On Friday night, Amy Wong told me she was available to help write website copy for any and all nonprofits. Amy was busy all weekend with this. I think her words are on at least half the websites we did.
- Also on Friday night, Heidi Cool (who was there as part of our social media team) foolishly reminded me that she can help with WordPress and design issues. We ended up doing about fifteen WordPress sites! Heidi was incredibly in demand. She also taught an hour-long seminar on WordPress content management for our nonprofit partners on Sunday.
What got done
Bottom line:
- We took on twenty-two projects in software and website development.
- Twenty of them were successfully completed during GiveCamp weekend.
- All the nonprofit clients got training on using and maintaining their new software and websites.
That makes Cleveland’s the largest and most successful first-time GiveCamp. Anywhere. Ever.
Retrospective
Jim Gorjup solicited “retrospective” notes from all the volunteers and nonprofits. We wanted to know what worked really well, what could have been better, and what really sucked about this year’s event. Mostly, I took these handwritten scraps and passed them right along to Jim so he could collate them and talk about the themes, but one line got my attention. It went something like this, approximate quote:
I liked the way everyone cooperated and shifted from team to team as needed.
This was particularly evident when a scheduling application for the Richmond Heights Fire Department looked like it wasn’t going to get done. Jon–being pretty much the King of Agile around here–collected what we called the “rockstar team” of Ruby developers who were done with (or could be borrowed from) their other projects and prompted them to self-organize. The upshot, unfortunately, was that the project simply couldn’t be completed in a weekend. It was just too ambitious, and since the project was a last-minute addition to our lineup it was hard to know that ahead of time.
I count that as a win for the Agile concept. At least we were able to conclude that project wasn’t going to go, which gave us permission to drop it (for now) and reallocate our developers to something that had a better chance.
What’s next
In my closing remarks to the assembled GiveCamp community, I referred to “next year” even though there weren’t any specific plans to do this again. I caught myself and asked, “Wait, who wants to do this again next year?” I’d say the response was strongly in the affirmative. So we’re on for next year.
Which reminds me. There is still time to contribute cash for next year’s event!
The key hiring question
Esther Schindler asked recently, and this is a paraphrase because Twitter won’t show it to me today, what question you’d ask a candidate interviewing for a network administration job.
My idea was something like this: “Tell me about a time something broke, how you felt about it, how you tried to fix it, and what the result was.” You may recognize this as “behavioral interviewing,” which I learned a little bit about in my very first job after college.
From the Saturday afternoon memo department
| To: | [name elided] |
| From: | MWS |
| Date: | Saturday, 6:04 p.m. |
Wow, I do weekend things on a weekend, come back to the computer, and there’s all this action.
What’s this about needing something done by end of month? I’m pretty sure [name elided] already handled the demo, which is why those cards are in archive. If there’s something I’m supposed to do by month’s end, there should be a card for it in the backlog. And the progress of cards is how you know things are getting done. If I’m doing things that aren’t on the cards, the funders are going to ask what the hell I’ve been doing. And I won’t have a good answer for that.
A decision is made to do something when a card gets added to the backlog. If it’s not in the backlog, the decision to do it hasn’t really been made. Among many other reasons, this is necessary because it keeps the project owner from making half-assed decisions. You either have to do it, and add points to the project, or admit that it’s not really on the agenda. You can’t pester the team to do stuff that’s not in the backlog and then hold them responsible for the backlog not getting done.
Bottom line: Agile is the exact opposite of doing whatever the hell you feel like. It’s very disciplined even though it looks informal. It will absolutely not work if you keep trying to circumvent it or make it be something else.
