I have to admit, I’m biased. As a manager and a business person, I have a vested interest in my teams success. That success is built upon them achieving a sustainable pace of delivering value to paying clients while supporting their personal growth.
The definition of “done” is a powerful tool. In my journey as an Agile Coach and Scrum Master, I have found that focusing on the team’s definition of ‘Done’ provides tremendous return on effort. If your team jokes about ‘Done’, ‘Done done’, and ‘Done, done, done’ - there is usually a gold mine of opportunity for continuous improvement.
I believe in the strong relationship between defining done and improving a team’s overall well being – I've seen it first hand. Conversely, I see high dissatisfaction within the team, from the Product Owner and people outside the team when there isn’t a clear definition. In the knowledge business, people like to create and provide things that others use; they generally hate building the wrong thing or things that aren’t wanted or used.
First example from a real demoralized team:
Scrum Team: “We define ‘done’ as the feature being ready for QA to test.”
Scrum Master: This is clearly an anti-pattern to delivering a potentially releasable unit of value. We’re doing Wagile, not Scrum!
Expunge that way of thinking permanently and never say it – ever! Seek first to understand…
A Scrum Master should always assume that people are rational and therefore behave rationally. Dig into the reason for the definition. Perhaps this was the team establishing a working agreement based upon having a lone QA person and this was seen as a solution not a problem. I bet that they’d love some help that can result from simply asking “what can we do as a team to help you with your workload?” See the world from their perspective. They may be transitioning from classical waterfall workflows and the team hasn’t adjusted to the concept of a cross-functional team.
Use the principle of “take it to the team”.
How can we (the Scrum team) help you? Help ourselves?
Scrum Masters also use individual 1-on-1 coaching – How can the team and/or I help you?
Second example from a real team:
Scrum Team: “We define ‘done’ as the feature being implemented, passing tests, and meeting the acceptance criteria – but we never release anything.”
Finding possible root causes is again key. Problem solving requires an agreed upon statement of the problem and the desired outcome from a change. In this case – it appears that it is potentially releasable, so the team may have a variety of options such as exploring:
Please note that the 3rd bulleted item shifted to exploring possible solutions.
If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.