Definition-of-Done – Are We There Yet Part 2

This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.

I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.

Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.

But he said something about Definition-of-Done that I challenged and it inspired me to write this “addendum” to my original article. I’m assuming you’ve read that one before this one.

So what bugged me? I’m glad you asked…

Where Does DoD Come From?

In his talk he implied that the team defines their own Definition-of-Done. That they (half jokingly) sequester themselves in a room for a half-day to a day and figure out what done looks like to them.

While I don’t have a problem with the team contributing to the DoD, I do have a problem or concern with the team being the sole arbiter of done-ness. When I asked him about this concern, I used the example of an organization that was creating regulated software. In my example, I said – “what if the team didn’t care to make “traceability” a part of their DoD? Since the business would be literally required to do that to remain solvent, the team would really have to add it whether they agreed to or not – right”?

His response was that agile is about self-directed teams and that we can’t “make” the team define a DoD; instead it has to come from within the team. He implied that there might be another level of approval beyond the team, but he didn’t give any specifics.

I didn’t challenge his answer in the class and the presentation moved on, but I struggled with this view.

Context Does Matter

So to be fair, I guess there are some agile team contexts where having the team solely defined their Definition-of-Done makes sense. I think of many start-ups and very small environments as examples, or teams who are using agile approaches for non-software development.

But there are so many more contexts where organizational constraints need to be “built into” your DoD. I mentioned one of them in my above question.

If you’re working in regulated environments, then tracking test cases to requirements (traceability) is often a very hard requirement. As is running a full regression test as a part of pre-release testing activity.

Another example where I think it makes sense is in larger enterprises or anywhere where you have agile at-scale. For example, I’m aware of one large company that doesn’t provide any constraints at a team level towards Definition-of-Done, tooling, or development practices. None. Every team does virtually whatever they wish and the result is pure chaos. There are no consistent practices, constraints, or even approaches to what agile methods they’ll use.

I apologize in advance if this offends anyone, but this isn’t “Agile”. Everything isn’t optional and the goal is NOT chaos or encouraging the inmates to run the asylum. I think its normal and good practice to provide realistic constraints for mature agile teams.

What IS the “Right” Way?

So Bob, are you saying that the team has no say or input in their Definition-of-Done? Of course not!

But I’m strongly recommending that they don’t have the entire say as well. What I’m looking for is something in between. Where the organization contributes key constraints and goals to the Definition-of-Done. Items relevant in support of the business and economic goals. Then I’m looking for the team to bring their ideas for completeness to the table and meld them into a more unified and balanced DoD.

If you consider my 4-tiered model for done-ness criteria, then some of the tiers have more organizational influence than others. I would expect the release-level to nearly entirely influenced by organizational goals. Conversely, I would expect the work product-level to be mostly owned by the team. The middle two levels should have influence by both sides.

Usually I expect the organization to give the team their input for organizational constraints within the Definition-of-Done. Then, to Jeff’s point, the team should meet and make it their own by adding their own conditions and views. I think this approach creates a balanced DoD, where the team had a chance to weigh-in and create shared ownership.

DoD has a “Cost”

There’s also one other point I’d like to make that I didn’t emphasize in the original article and it supports this argument. I firmly believe that Definition-of-Done has a cost and minimally has to be negotiated with and agreed with the business. In other words, a team can’t simply decide on what’s in vs. out in their done-ness.

The primary negotiating voice for the business and customer is the Product Owner. But in larger scale organizations, the individual Product Owners need to balance things from an organizational perspective. For example, a team might want to build automation as part of each and every user story; so they put it in the DoD. I personally like that goal being a part of things and think it indicates a more mature view to full feature delivery.

That being said, the Product Owner needs to “buy” it, as this constraint has a cost. So there needs to be some healthy discussion and negotiation around many of the constraints within typical Definition-of-Done’s. Some things are non-negotiable, while many others are—depending on their cost.

Wrapping Up

Going back to Jeff’s presentation, clearly his organization is one where the teams defined DoD. The question I’d ask them – is the DoD balanced and does it contain organizational constraints towards quality, the customer, and release? If the answer is yes, then I think their approach is fine. If however, the team has ignored some important organizational constraints and “punted them” downstream for accountability, then I have a problem with that.

And remember, this is as much of an organizational problem as it is a team problem. I think it’s easier for many organizations to not communicate key DoD constraints to their teams in order to avoid conflict or the appearance of being “non-Agile”.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.