Defining what “Done” means for an IT group can be as hard as herding cats together. Frankly, in my experience, it’s always been a struggle to get a team to discuss openly and honestly about what “Done” means. I’ve been finding that it is necessary to have a designated time to really sit down with the team and discuss what “Done” means, and not have one-off conversations, for example, at the end of a retrospective meeting to figure out what “Done” means for the team.
Well, enter Rachel Davies with a fantastic (and well documented) way to have your team discuss what “Done” means and how you can follow her way of facilitating these types of meetings and conversations.
I specifically like the Surfacing the Current practice section that talks about what your team does now: Currently, Sometimes, Not Doing. – Sometimes understanding where you are now helps you know where you need to go. Sometimes the opposite is true: Knowing what you shouldn’t do.
Coming out of these types of meetings to define what “Done” is essential for your team to know not only what it is, but who is responsible for helping that happen (dependencies, anyone)? Having a Proposal for your team’s Definition of Done as well as a Working Agreement (who/what/when) helps everyone get on the same page. Hopefully if these things work out for you and your team it will help with not only your technical debt, but also your ability to better track the value of what your team is doing.
Isn’t it better when a team works together?
Read more of Rachel Davies article on “Done” here. And her steps below:
- Surface the current practice (Always, Sometimes, Not Yet)
- Discuss what Definition of Done what feels practical for the team
- Resolve any puzzles and concerns before putting into action
- After a couple of weeks, repeat from step 1.