Micro-managing Definition of Done?

Why are managers adding anything to the Definition of Done?

In Scrum, if the Definition of Done is not provided by the organization, then the members of the Scrum Team are responsible for defining the Definition of Done. Unless the managers are also Developers, the Product Owner, or the Scrum Master, they wouldn't have much involvement. The team should be empowered to craft their own appropriate Definition of Done, and if there are any constraints, seek out anyone from outside the team to ensure their Definition of Done aligns with those constraints.

In SAFe, the Definition of Done is part of Build Quality In. SAFe considers a scalable definition of done that includes considerations at the team unit of work or increment level, the PI increment level, the solution increment level (if you are working in the Large Solution configuration), and the release level. Defining each level of the responsibility of the Agile Team, the Agile Release Train, and the Solution Train and should be done collaboratively by the people working at each level.

No one should have to police the Definition of Done. The teams should be acting as professionals and treating adhering to the Definition of Done as a commitment to their colleagues and to the stakeholders in the work they are doing. In some contexts, there may be independent audit of the way of working that confirms and provides assurance that the teams are adhering to their Definition of Done, but this is not what I'd consider policing since this should be a simple confirmation that what is expected is happening.

If you need evidence of things, I've found that the best evidence is that which falls out of doing the work. By using the agreed upon and configured tools, evidence that work is happening can be seen by anyone or demonstrated to anyone. Automation and integration points to reduce manual activities can go a long way. Sampling is a common auditing approach, so the number of times a thing happened can be counted and a percentage examined to ensure that what was expected happened in all of them. People don't police other people.

Thanks for the reply Thomas.

I'll simplify my question.

In an org where dev teams are NOT meeting their DoD, but they are attempting to deploy to prod anyway. How can we fix this?

Let's assume we have already said, "dear dev teams, please determine your own DoD and meet it."

How is DoD normally policed? I'm starting to think myself and other managers are adding too much rigor to DoD.

No you're not, what's actually happened is you've sucked out respect and trust. Now you're chasing rigor down the plughole.

If there's any policing of a DoD in Scrum, the Developers must police themselves. They are the ones doing the work. Only they can really meet and assure that standard. In Scrum it is the Developers who are accountable for quality. Realistically, no-one else can be. The belief that a CAB can dot every i and cross every t on quality is illusion, and no amount of management oversight or interference will make that conceit real.

It sounds like a conversation is needed between all parties about respect, trust, and the accountability which is presently missing in the organization.

In an org where dev teams are NOT meeting their DoD, but they are attempting to deploy to prod anyway. How can we fix this?

Depends on who the "we" is in that statement. If the "we" are managers, I'd say you really have no way of fixing anything. In fact, your attempts to try may be what has caused the current situation.  What has been the organization's priority? Is it delivering based upon a schedule or delivering quality increments of value when they are ready to be delivered?  The fact that you have a Change Advisory Board when there is no mention of one in the SAFe framework could be contributing to the problem. 

The Scalable Definition of Done in the SAFe framework is not something that is managed. It is something that is evolved and then adhered to by the professionals involved in the Release Train.  It is something that everyone agrees to abide by and everyone holds each other accountable to doing so.  If you are truly using SAFe, it might be worth people's time to reread the documentation on Built-in Quality to reorient themselves on the purpose of the Scalable Definition of Done.

SAFe does not use Scrum as described in the Scrum Guide. It uses a variation called ScrumXP that was created for the Scaled Agile Framework. You might want to consider finding a forum that is focused on SAFe or ScrumXP to see if you get any different answers to your question. I don't think you will but it would be worth a try. 

You're preaching to the choir, Ian. 

"It sounds like a conversation is needed between all parties about respect, trust, and the accountability which is presently missing in the organization."

We had said conversation. The result was, the CAB wants proof the DoD is being met. After several sprints of seeing said proof, they think trust will come back. Example: if "accessibility tests pass" is part of DoD, the CAB wants to see an artifact that shows accessibility test evidence. This seems reasonable to me. Myself and other managers are merely helping to bridge this gap. Since we have the CAB observing eight dev teams, it seems to me, uniformity between said dev teams will increase the likelihood of success. If all dev teams can provide a similar artifact reflecting accessibility testing, it's easier for the CAB to find this so-called proof.

AND, in this case, as much as I hate the CAB, the CAB is actually correct. DoD is not being met. The CAB did not ask for accessibility testing. Instead, the dev teams put it in their DoD. The CAB merely noticed accessiblity testing does not appear to be getting done. For example, when the CAB says, "tell me about your accessibility testing", the dev teams shrug and a kind of bystander effect takes place..."I think Joe did it".

"Developers must police themselves". I agree. I like that sensible default. I'm looking for ideas on how to help them police themselves better.

When the Scrum Master looks at the Sprint Backlog, does he or she have confidence that the Developers have done enough technical planning for the DoD to be met?

A Scrum Master manages people's understanding of Scrum, including their accountabilities and commitments, so they can then manage themselves.

When the Scrum Master looks at the Sprint Backlog, does he or she have confidence that the Developers have done enough technical planning for the DoD to be met?

I like that question, Ian. The relationship between the Scrum Masters and the DoD is the recent discussion my org had, that inspired me to reach out for ideas via this forum. We started with the notion that Scrum Masters should have some oversight/management/coaching/influence that might hold dev team members more accountable for meeting DoD. But the conversation stalled out when we got into the weeds on what that means in practice. Some Scrum Masters felt a DoD checklist on each story would help. We spit-balled how to do this in Jira. Other Scrum Masters thought maybe it wasn't their job. One suggested it approaches something like micro-management. At one point we thought, maybe the PO can help make sure the team met DoD...but wait the PO is responsible for some DoD tasks too.

Back to your question, Ian. That didn't come up but I like it. Maybe extra questions/conversations/planning about DoD during story refinement is a good place to focus.

The fact that you have a Change Advisory Board when there is no mention of one in the SAFe framework could be contributing to the problem.

Daniel, of course I agree. My primary goal is to disband the CAB. To quote the Accelerate book, "...[a CAB] doesn't work to increase stability of production systems...it is in fact worse than having no change approval process at all". Ironically, the Scalable Definition of Done doc you referenced suggests "Approved by Release Management" be a core DoD item. Ha! That seems like an antipattern to me. It seems eerily like a CAB. Boooo SAFe.

I'd start with making sure that the developers understand the purpose of a Definition of Done, what it means to include some kind of task or work or activity inside the Definition of Done, and the importance of the Definition of Done as a commitment to downstream consumers of their work.

Since SAFe is also involved, I'd pay attention to the different levels of the Definition of Done, from a specific team's work to the ART's increment to a release.