In the last Mektup, I talked about why you need to develop a Definition of Done (DoD) and what it is. Today, I will talk about creating one in the team. Definition of Done is unique to the team, and it's an agreement with stakeholders.
First, you need to define who your stakeholders are. In product companies, these people are often the Product Managers, Team Leads, Engineering Managers, or any other manager leading the team. If engineers don't have this level of management in the team, then stakeholders are the people who are responsible for the team's deliverables and accountable for the overall work. Don't confuse these people with project stakeholders who usually don't care about developing a feature or a project. Project stakeholders only care about if you deliver it on time or not.
The first step to developing a DoD is getting together with all engineers, designers, quality assurance folks, project/product managers, engineering managers, team leads, or any other manager who is accountable and responsible for the team's work. During this time together, everybody will write down their expectations from a finished work from their perspective. You can use post-its—virtual or physical—and write down one item in each post-it. Give everybody fifteen minutes to write their expectations down without too much thinking or pondering on them.
The next step is identifying the shared expectations. Group post-its that mention similar expectations. Then, as a group, start from the largest group and discuss why people think that expectation should be in DoD. The goal is to identify common ground, find people who disagree with the expectations, and have a healthy debate. One by one, from the biggest group to the smallest group of post-its, discuss with your team. To keep the discussions on time, set a maximum of five minutes for each group and have a decision in the end whether the expectation should be in DoD or not. If you need more time in discussions, extend it by one minute each time.
Once you have listed all your· expectations, go over them and identify if all expectations are applicable to your projects. If any expectation is not suitable for all of your work, mark them either "optional" or "if applicable."
While going over the list again, think about if you can meet all the expectations all the time. Don't try to come up with an exhaustive list. The DoD should have only the bare minimum. It shouldn't contain wishful thinking; it should include essential items in your work.
Once you're done with the DoD, set a timeframe to try it. I found six to eight weeks a reasonable time frame that people can adapt to a new process and realize the invalid or missing points in DoD. During this testing period, try to enforce the DoD as much as possible. For example, add it in your pull request templates if you use GitHub or integrate it in your flow as a checklist in Jira.
Once your testing period is over, iterate and refine the DoD. Prune unnecessary or inapplicable items and add missing ones. When you're done, announce it to everyone around your team, especially to all your stakeholders and other teams you often collaborate with.
After you have it defined, I recommend keeping it as a living document and reviewing it every six months. Our projects evolve, and we change our workflows in time. It's crucial to keep DoD up-to-date with our evolving processes.
Before we end this letter, I have one last tip. Look out for the items in DoD that you can automate. If you can somehow automate any item in any way, it definitely worth's the effort.
Updates from The Last Two Weeks
I’ve been part of quite a few reorganizations and restructuring. I’ve experienced both from either side: as a restructuring initiator and as a person affected by restructurings.
I realized the importance of storytelling skills in all complicated situations. When leaders use their storytelling skills in these situations, the result often didn’t look like chaos, and there were many “yeah, make sense” responses.
I wrote about why I think storytelling skills are essential and the elements leaders can focus on.
The wars and their results create various feelings in us. It creates conflicts. It creates sadness, hatred, happiness, proudness. All of them at the same time.
However, we cry. At least I cried a lot over the last week. But this time, I know why I cried.
I don't know how you feel lately, but I have a different perspective on all this as a Middle Easterner and a person who had faced bombings in my city before.
I started working on the new season of the Software World podcast. Soon, you will hear the topics I will cover within this season.
🤔 A Quote I'm Pondering
This quote is from The Wise Man's Fear by Patrick Rothfuss. During the conversation, two people talk about a game they are playing. I found Bredon's point as a valuable lesson to the many things in life.
He gestured at the brief and brutal lay of stones between us. "Look at that. Why would I ever want to win a game such as this?" I looked down at the board. "The point isn't to win?" I asked."The point," Bredon said grandly, "is to play a beautiful game." He lifted his hands and shrugged, his face breaking into a beatific smile. "Why would l want to win anything other than a beautiful game?"
💡 Today I Learned
Yesterday was the Equal Pay Day in Germany, marking the date that women are working up to yesterday for free due to the gender pay gap. It's coincidental that today is International Women's Day.
If you find these letters valuable, consider sharing them with friends, colleagues, or work friends!