I’ve been sitting on this idea for a post for some time now. From time to time throughout my career, this topic materializes out of nowhere and is worthy of discussion. And when it comes to ‘ownership’, I have experienced differences of opinion that could easily rival the argument about which is better … Apple or Android.
So with that grenade firmly tossed, the question(s) leading into this post are as follows:
- As a product manager (or perhaps product owner), what is your definition of done?
- Who ultimately owns the definition?
Interestingly, if you search on ‘definition of done’ many of the sites returned are developer or IT-centric … and many of them focus on the ideologies of Agile. I’ve posted many times in the past I am a firm believer in the underlying principles of the Agile manifesto, so to a large extent I understand why this is so. And there certainly good many examples of good checklists out there … this one in particular I found fairly complete …. Definition of DONE! 10 Point Checklist.
Then again, I’ve seen some impassioned responses in forums & blogs about how “the development team is solely responsible for the DoD“, and this is what makes me take pause. It’s not that I fundamentally disagree with the statement, or believe development is not capable. It’s more of a question of does it make sense to belong there.
So while I am a believer in being responsive to the changing needs of the market and/or organization, it can’t be at the expense of good business or product management practices. I shared about the differences between being “needs driven” and being “strategically driven” in my post Taking the Lead In A Well Orchestrated Dance.
As I was prepping for this post, I found this image. And I really like how it cuts to the chase of what I have experienced over my career. Essentially it has less to do with ownership of the definition per se, and more to do with when the definition is weak and/or doesn’t fully have a good set of checks & balances to ensure it is executed upon correctly. In either case, the result is technical debt.
Listen, having played in both roles (developer and product manager) I get it … technical debt on occasion happens. I wrote about this in my post I Understand, but I Still Don’t Like It!, and the point I made is it is hard to make up for … so if you can avoid it if at all possible you should.
I like the new Farmers Insurance jingle … we know a thing or two because we’ve seen a thing or two. These are just some examples of when the definition was weak and/or checks & balances didn’t exist:
- “we didn’t have time to do all of what you asked for, so we split it into multiple phases/releases” – if planned for up front, and agreed upon across all stakeholders, no problem. If unilaterally decided upon by development, problem.
- “you didn’t explicitly ask for ‘X'” – X has manifested itself in many different forms … but does it make sense I would need to explicitly ask for things like published documentation? Or if we are expanding to support payments in another country, wouldn’t not hard-coding a currency code seem intuitive?
- “we didn’t test for ‘Y’, part 1” – this refers to an environment where developers are responsible for testing their own code. This is never a good idea as they are too close to it . Getting too close to something happens to everyone, not just developers. Even with the best of intentions, we may or may not be aware of blind spots.
- “we didn’t test for ‘Y’, part 2” – this is broader challenge, and refers to when the QA team doesn’t align their test cases all the way back to the requirements documents. Having this kind of trace-ability is critical as a business owner, and one good argument about why the definition of done shouldn’t fall under development.
And lest you think this is entirely about beating up on development, it isn’t! Here are a few more supporting arguments for the definition being broader than development because these fall squarely on the product manager.
- “where are the requirements?” – there are always times where we need to run fast. But bypassing necessary steps in the process is never a good idea. If you are dealing with a specific customer, not having documented requirements leads to scope creep and mis-managed expectations. From a broader market perspective, not having requirements means no ownership/accountability of whether or not the final solution actually meets the market needs. It is hard to get to a definition of done when you can’t explain what done is supposed to look like.
- “we were supposed to tell other people about the release?” – another If you deliver a perfect solution on time, on budget, and on scope … but don’t inform your sales team(s), support staff, and implementation specialists, are you really done?
I’m interested in hearing your stories on the topic as I’m sure I missed some obvious ones. Regardless of who actually “owns” the definition of done, I hope the message you took away is it needs to be a coordinated process … a well orchestrated dance.