Last weekend, at the Hacker B&B, I mentioned to Jason Rudolph that my current team has no cardwall. He was a bit surprised and asked what we do have.
We track what needs to be done in 3 stacks: Eventually, This Release, and Tech.
Our stakeholder gives us requirements all the time. We also think of things that need to be done on a fairly regular basis. All requirements are captured on an index card with about 5 to 6 words. These cards are not the entire story (pardon the pun), instead they are a placeholder for a conversation. That's fairly standard for the projects that I'm a part of.
New cards are put in Eventually, unless they need to be done for This Release. When a card is done, it's put in a Done stack. Our stakeholder goes through the Done cards every few days and discards them after a quick once-over.
That's it for requirements. It's a very slim process. We estimate at the release level, not the card level.
Some cards are purely technical. We put those in the Tech stack and the team prioritizes as they wish. In general we work on Tech cards when no-one is available to pair. However, sometimes a Tech card is the highest priority and it can get picked up instead of a This Release card.
I mentioned to Jason that I believe we can be successful with this process because of the trust that our stakeholder has in us. As a consultant, I always felt like a vendor instead of a partner. Now that I'm full-time, we're all on the same team. When you're on the same team you don't seem to need as much ceremony and information radiation. This definitely isn't universal, but it's been my experience since I joined DRW.
I definitely prefer the slimmed down process, but I only see it working in an environment with a very high level of trust.
Update: Credit due to Chris Zuehlke for leading the fight for the slimmed down approach. We are more productive thanks to his efforts.
I've found that most of what we call process in software development is created to allow non-trusting parties to collaborate successfully. Once you're in an environment with a high level of trust, I've found that a ton of the process can simply fall away. How is trust established? Through repeated successful deliveries.
ReplyDeleteDave, I agree. Thanks for the comment.
ReplyDeleteI do the same thing, more or less (down to the "now", "future" and "tech" categorizations), but keep it all as lines in a TODO file at the root of the version control repository. If something needs more writing that reasonably fits into a line (say, we had some IM conversation that needs to be preserved), this goes on to a wiki page and a hyperlink goes on the line (after a meaningful title).
ReplyDeleteHi Alex,
ReplyDeleteI like it! I think cards works better for us because it allows our stakeholder the be hands on if he wishes. But, I expect that will vary by stakeholder. There's clearly no "right" way in that case.
I hope you're doing well.
Cheers, Jay
You might find Liz Keogh's somewhat opposing thoughts on how to handle technical stories in her blog post from last autumn rather interesting:
ReplyDeleteFeature Injection & Handling Technical Stories