Wednesday, July 02, 2008

Scrum Sprint 1 - Week 3 - Reevaluating “Done”

HanselMinutes - What is Done? - A Conversation with Scrum Co-Creator Ken Schwaber

“Scott chats with Ken Schwaber, the co-creator of Scrum, agile advocate and a founder of the Agile Alliance. Scott asks 'What is the definition of Done?' and gets a more complicated (and more interesting!) answer than he bargained for


After listening to Scott Hanselman’s Scrum related “What is Done” podcast yesterday, I believe I need to redefine what I call “done.”

I have been very clear in stating our done means “done done.” That we need to have shippable, deployable code the day our sprint finishes. That when we demo the app, we can only show stuff that we can ship that day. That if at the Sprint Review the Product Owner says, “I want that now”, we can reply “is after lunch okay?”

So in that respect I think our “done done” is on the right track.

But where I think I need to work on (and why, as ScrumMaster, I have asked the team to listen to Scott’s podcast asap) is to better define what we mean as “done”.

I’ve been calling “Done” as being coded, tested, documented and ready for the user. Do you see the issue? Define “tested” or “documented” or “coded”. Does "coded" include well factored, well performing, unit tested code? Does “Tested” mean integration, manual, destruction, user acceptance testing? “Documented” at what level?

I look back on my work in this Sprint and have to say I’m not satisfied with my performance and “done” acceptance level. I’ve was lazy and was willing to accept “just barely good enough,” “it’s coded and seems to work,” “we should be doing ‘that’ but…” and "Oh we only need simple doc's..." from myself. That’s just not good enough.

I want my team to succeed. I want Scrum to succeed. I want to make the PO happy and deliver the needed solution as soon as we could.

So I accepted shortcuts from myself. And I can only expect the team to follow where I lead (as ScrumMaster, their Performance Manager, and “the guy who’s been here for forever” and group Manager). Like Ken Schwaber said, I could probably get away with this for 3-4 Sprints. But I can already see, now that I’m really looking and thinking about it, that these shortcuts would come back to haunt us.


Live and learn. Luckily Scrum is so adaptive that we’ll be able to tweak our “done” and improve it before we get to far into “quality debt.” We control our destiny, at least during the Sprint, so we can fix this. I need to make it clear that slapping down some code isn't everything. That as the "Man" I accept and understand that doing it "right" may mean they are not banging on the keyboard the entire day. That fewer "good" and "really done done" features are better than more "kind of done" ones. It's the quality that's important as much as the quantity, if not more so. And more important than anything, I need to walk the walk...


Can you tell what one of my topics will be at the Sprint Retrospective?  LOL


Related Past Post XRef:
Scrum Sprint 1, Week 2 – A rolling stone gathers no moss (aka the Scare Factor of having a timeboxed integration)
Are you “really” using Scrum?
Sprint Day 1 – Here we GO!
Scrum Day [Decision + 1 Week] – Passion versus Religion
Scrum Day [Subscript out of range] – Time for a minor reset, I’m pushing back the Sprint Planning Meeting by a week…
Scrum Day 0 – The Search for ScrumMaster
Scrum Day -1 - Infrastructure Day
Scrum Day -2 - The Decision is Made

No comments: