Why Your Software Project Sucks
Fresh ideas about development
When they try to “do Agile,” many people work too hard at it. The right idea is to cut down on things that don’t get the project done and build up things that do get the project done.
Here’s another real-life example of applying Agile values and principles in weird or hostile environments. You can adapt well-known Agile practices or even make up your own. The values and principles are what matter.
If management won’t let you do Agile, don’t fight it. Find the best ways to apply the Principles regardless.
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.
The KanBan is made for the project. The project is not made for the KanBan. Adventures in refactoring!
So this week I’m seeing on the KanBan:
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!
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 |
…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.
For those newly tuning in or just standing by, the Scrum meeting is really really simple. Everyone in turn answers Three Questions:
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.
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.
