The dev team needs to see the client, preferably face-to-face but directly in any case. Communicating directly is hard enough. Going through the fake client to figure out what the real client wants is impossible.
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.
There are no seven-page proofs in a 200-level class. Even when it’s Adelberg.
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.
It is amazing how much you can accomplish when it doesn’t matter who gets the credit. GiveCamp rocked!
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
You know this saying?
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;
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
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.
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.
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!