Hmm. There are two alternatives here:
1) Decide the definition of âdone doneâ at the development organization level
2) Let each team decide what âdone doneâ means
I donât like the first approach much; âdevelopment organizationâ means âmanagementâ in a lot of places, and the biggest power of âdone doneâ is that a teams defines it as a group, holds themselves to it, and updates it as they learn. Having something imposed means that you lose the team empowerment, you lose it as an exercise for team-building, and â most important â you lose the opportunity for teams to experiment their way into better processes.
When I read something like, âone team is doing unit testing and another isnâtâ, my initial reaction is âthat is going to be problematicâ. My second reaction is, âitâs going to be interesting to see how big an issues it will be in practice and how *the teams* figure out to address itâ. My guess is that they will probably come up with a good solution on their own â or perhaps with a little facilitation. And they will learn about working with each other, the value of looking at what other teams are doing, and my guess is that theyâll do it without a lot of process. I would not be surprised to see the team that chose to add âunit testsâ to âdone doneâ actively working to train other teams how to do it, and if they can do that themselves, it will be great for the org.
A homogenous world â where teams have very similar process â is a simple world, and that makes is alluring. But the innovations that drive teams and organizations forward come from a heterogenous approach, and a lot of the big wins are elimination of process that the team doesnât need any more. If that process is defined at a larger scope, itâs much less likely the team can get rid of it.
Or, to put it another way, Iâm willing to tolerate a fair bit of chaos and differences between teams to give them the ability to experiment their way out of the old and slow ways of the past and into better ways. I trust that teams are going to generally make good choices, and Iâm pretty sure theyâll discover things like, âIf we write better unit tests, we can stop running the huge integration suite that everybody hates before every checkinâ or âPairing is great because we do continuous code review and therefore donât have to wait for code reviewers before we check inâ.
Eric
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Wednesday, August 19, 2015 9:08 AM
To: ***@yahoogroups.com
Subject: Re: [SCRUMDEVELOPMENT] Open (free) Product Owner Assessment
On Aug 19, 2015, at 8:28 AM, Wouter Lagerweij ***@lagerweij.com<mailto:***@lagerweij.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:
Frankly, 'the development organisation' doesn't mean that much to me in a Scrum context.
I guess this means it wouldnât work for Team A to skip unit testing while Team B insists on it in the same code base. There must be a clearer way to say that though.
âmj
(Michael)