It's Nice When It All Clicks

My grandboss1 walks into my office today and says. "Our customer doesn't understand the spec we sent them for the work they want us to do. We've got to find a better way to explain it to them."

I'd just spent an hour explaining to my boss and some others what I learned in the Scrum Product Owner training I did in LA last week. A big chunk of that is this:

The developers care about what they need to do. The customer cares about what the system will do. Someone needs to see both sides and bridge that gap.

The problem, of course, was that we'd written the spec as list of things we would do. Tomorrow I get to sit down and put together something that describes what the customer will do with when we're done. But at least now I see what the problem is.

1 Grandboss: Your boss's boss.

Comments

[Rob Donoghue]

I'm envious. That's a great kind of problem to have, and even better to have someone higher up the chain recognize that it is the problem.

[Paul]

To be honest, I was the one who realized why they didn't understand it.

[Jon Edwards]

Thanks for posting that quote, Paul! As a project manager and agile enthusiast in game development, I'm struggling with this every day. I've been trying to make the distinction between "activities" and "deliverables."

[Kevin Fitzpatrick]

@Paul:
A ) I love "grandboss." That's just plain awesome.
B ) This is why I prefer user stories to big spec documents. While they're not a substitute for technical documentation when it's required, the format more easily captures the _intent_ and _business value_ of the feature/deliverable/task/widget.

[Kevin Fitzpatrick]

BTW, check out my new blog at http://apprentice.kfitz.me for my thoughts on software craftsmanship and my traveling around to learn from dev shops around the world that I think kick ass (currently in Sweden!)