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.
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.
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.
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.
Last night I had the pleasure of hearing Jon Stahl‘s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.
It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.
Jason Cohen guest-posted in December 2009 on the great blog On Startups, disputing the startup cliche that it’s always good to release your product early. He makes a good case to the contrary, although like some commenters I don’t think the iPod is a fantastic counterexample. (I mean come on. It’s Apple. They can get away with wild new design ideas, it’s what they do.)
Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at).
Which, it should not surprise you to know, reminds me of a story.
I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.
Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)
On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.
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.
In my experience, most software-dependent startups fail because they never actually finish the software. It’s really that simple.
I’m trying to figure out how I feel about Jeff Atwood’s recent proclamation: “Version 1 Sucks, But Ship It Anyway.” As a connoisseur of Software Projects That Suck, I get Atwood’s point: you don’t really know what’s wrong with Version 1.0 until some real customers get to play with it and let you know what they think. I’ve often spent days or weeks perfecting a feature that nobody cared about! Why not save that time by getting feedback first?
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.