Not having a Definition of Done at the company makes it hard to get the entire company pulling in the same direction.
Empowered teams understand that other people in the community need to deliver results and add value by collaborating on shared definitions such as Definition of Ready or Definition of Done. When teams fail to understand this value, they often expend a lot of effort doing things on their own.
This all-too-often results in wasted effort, delay of delivery, and lead time for multiple dependencies across the community, which are sometimes cross-domain. What gets delivered does not have unified deliverables, making it impossible to define what is done after work is completed on an iteration.
It would be one thing if all of this resulted in some visible benefit to the company or community. However, it often fails to deliver visible benefits to either party, which exacerbates the friction between the team and the rest of the organization. Defining “Done” builds trust, increases transparency, creates a safe space for creative thinking, and reduces waste of all kinds.
When teams spend time building products together, it has to deliver some business value by creating shared knowledge, collaboration, relationships, software code, architecture, design, documentation, working products, market acceptance of services or products, or any other possible physical artifacts that cross-talented individuals of the team can universally support.
There are several reasons why this doesn’t happen when efforts are siloed. The first reason is that people spend so much time hearing “we did X” without being able to see exactly what it is that they did. Another reason is that there are so many examples of failure within multi-year projects, feature creep, multi-generational defect tracking systems, schedules full of low-value activities, high turnover rates, high costs, and disruptive change.
For teams to self-organize around high-value activities, they need to believe that they can spend time doing them. They achieve this, at least initially, through the ability to get other teams to support them by engaging in responding to small requests for information about their plans.
That’s the tricky part. If all you do is collect free information, then you aren’t engaged in managing the team.
Instead, you need to use the information you learn to extrapolate about how the team is likely to use resources and what decisions they will make. When you can communicate this effectively, you’ll build trust and provide value by helping the team learn why it’s essential for them to support you.
Start with the simple stuff. Find out what’s important to others in the organization that you are most likely to have visibility into, then leverage that information to move into more complex areas. Don’t waste time getting other teams to do things for your team if they can’t pay off quickly with value delivered to their customers. This is especially true when you provide external support to an organization or community that you are trying to bring along your development life cycle. Don’t go off on tangents when you are providing this support. Stay focused on what they need to achieve to solve their problems. Most of the time, simply having a level of agreement about what’s essential will solve their problems in many cases, without any further help needed.
Not having a Definition of Done makes it hard for teams to self-organize around high-value activities. It limits the opportunity for high-quality interactions between the team and the rest of the organization. Establishing a Definition of Done is the basis for agile thinking.
Failing to develop one makes it difficult to its databases, chat logs, defect tracking systems, timesheets, etc. Another thing that happens is that teams end up having retrospective meetings. They yell at each other for not delivering acceptable results on time (after making many change requests during development). Meeting notes often record feelings of failure or negative attitudes by people on the team after failing to meet unspoken expectations of the organization around how the team should act on behalf of the business. It’s pretty thoroughly documented how these things create more obstacles than they clear away. A minimum of maturity is required for teams to establish reliable Definitions of Done unless using ticketing systems, which don’t require maturity. Consequently, Excellence starts to slip whenever the Definition of Done falls.
To help you establish a DoD, I’ve published a whitepaper that will show you how to set one up and start using it right away:
Most importantly, when you are part of a team that establishes a DoD, you can be much more confident about what other people in the organization are doing. You can have faster, more predictable deliveries with minor unwanted changes. All of this happens in the context of an organization that has already said, “these are things we want to deliver to our customers.” More people will approve of your work if they understand what you are delivering so they can better explain the value to their customers. If your company can be measured in providing products or services applicable to your customers, then making sure that you are perceived favorably by your customers is part of your job.
Creating zero defects in your effort is just one way to show your customers that you are working hard to give them something that will make their life simpler. The fact that you worked hard shouldn’t matter to them; what should matter is whether you delivered something that makes their life easier. Defining Done is the most effective way for teams to deliver work reliably to their customers without wasting time on defect triage, manual quality control, active project management, etc. The team’s Definition of Done doesn’t replace these activities; it replaces non-value added activities.
When members of the community establish good Definitions of what is Done together, everyone realizes that the pooled results are the work of the individuals on the team.
Just like multiple streams flowing into one river valley will eventually lead to the ocean, all of our activity streams eventually lead to organization-wide success.