"Are you done yet?" The answer to this question may sink your career, your team and your project. If you respond with a "yes," you may be forced to take on additional work. If you say "no," you may be branded as someone who can't get things done. In this article, I will share an exercise that will help you build your own done list and manage it over time.
Why have a done list?
What does a done list accomplish? First, gives team members the feeling that they are “all in this together” and that it is more important to deliver on their commitments than to focus on specific individual tasks.
Second, it provides clear communication to stakeholders, and by implication, drives down the risk of technical (or other) debt being deferred to later in the cycle. If a stakeholder asks the team if the software works, and the response by the team is “sure it works but we don’t have an installer,” the team has racked up technical debt because the component is not truly done.
Through the done list, and through the communication of that list, stakeholders gain a clear understanding that if the team says they will be releasing to production, they will have met a series of requirements that are needed for such a release. No more will done simply mean that something is coded. On the contrary, done will mean exactly what is published in the done list. Stakeholders will come to expect this level of quality and commitment.
Third, it keeps the team on track and focused. When planning an iteration, the team has a reference point as to what it means to be done. The guesswork is removed, enabling the team to focus on delivery instead of speculation on what could be “if only this or that happened.” The commitment is made, published, and adhered to. When used correctly, it provides the team with a common vision on how to achieve the iteration, release, and project goals.
The following exercise will help you coach your team to an initial done list that works not just for them but for your stakeholders as well. Notice I said “initial.” Done lists are not created once, buried in a drawer, and never seen again. Teams should periodically review the done list and determine whether there are opportunities for improvement or modification. Feel free to revise the list as needed, but be careful. Too many revisions too frequently may create doubt about the validity of the done list in the eyes of the stakeholders. Invest the time to create a solid baseline and modify the list based on the experience and findings of the team. The done list should become a way of life – not a checklist to follow, but a commitment to excellence.
Getting started
You will need the following items to perform this exercise:
- Your team (Everyone. No matter what their role.)
- Post-It notes in multiple colors (stickies)
- Pens
- A meeting room
- An open mind
- No interruptions
Brainstorming
The first part of the exercise is the brainstorming. Before brainstorming, remind your team that there are no right or wrong answers. There is no criticism. There is just the free flow of ideas, sometimes wild ideas.
Start by writing the question the team will answer with its done list on a whiteboard: “What do we need to do, as a team, to ship software to our customers/stakeholders?” Your question may vary, depending on your own team’s unique circumstances; however, the general purpose is the same. The reason the team is together in the room is to identify everything that it needs to do to ship software, the truest measure of project progress I have encountered to date.
Hand everyone a pen and the colored sticky pad of his choice. Repeat the question you are answering. Have each team member write an answer on a sticky, call out the answer, put that sticky in a pile in the middle of the table, and repeat. Team members can write only one answer per sticky and must call out after each answer is written. As team members start to share their answers, inevitably some will say, “I’ve already written that.” Do not worry about creating duplicate items at the moment. This will be addressed later.
The call out puts the storm in brainstorm. I have run this exercise without the team members calling out what they wrote on the stickies, but it resulted in a stale, unproductive meeting. Calling out will feel weird and uncomfortable for most; however, the feeling will subside very quickly once the team becomes engaged and the meeting begins to flow.
Run the brainstorming part of the session until there are “enough” sticky notes to get started with the next phase. It is generally easy to identify when people are done because you will see the flow of sticky notes begin to dwindle. People will begin looking around the room and at each other, searching for something new.
