4 steps to solving issues in projects
In many different projects and organisations, I’ve seen people struggle with techniques on how to solve issues without creating huge issue registers that weigh down the project and takes an inordinate amount of time to manage, resulting in the actual problems often not getting the attention they deserve.
There are lots of agile techniques for tracking stories and work, like card walls, but what’s an agile oriented approach for issue management?
The following are four steps that I’ve seen consistently work well.
1. Make the problem visible
Making the problem visible for everyone to see allows people to see the problems, which may prompt people to provide more context, examples of the problem or suggestions on resolution.
For a co-located team, create an issues wall. On a sheet of paper, draw a big target. Have some index cards that you use for issues that are of a colour only used for issues, such as pink or red.
Issues that have a bigger impact on the project put towards the centre of the target. Those that are lower impact, put towards the edge of the target.
For distributed teams, use a Trello board.
Create three columns. To Do, In Progress, Done.
As issues arise, create a Trello card in the “To Do” column.
Cards that have a bigger impact on the delivery of the project put towards the top of the column Those that are lower impact, put towards the bottom of the column.
2. Get a shared understanding of the problem
When dealing with issues or risks, many people will have an opinion, which is great, but how do you get that without getting bogged down in in the detail?
Run an Issues or Leadership stand-up two or three times a week (no need to do one everyday) with key people from the team. Ideally it is best to get representation from each of Product, Technology and Delivery within the team, such as Product Owner, Tech Lead and Project Manager. Extend to other people as required.
For distributed teams, do this via a teleconference or video conference tool like Google Hangouts.
Keep the stand-up to 15 minutes.
During the stand-up, discuss each card briefly that are “in progress” or “new”.
3. Give the issue an owner
Each card must have an owner.
The owner is the person who is reporting on how the resolution of the issue is going during stand-ups. The owner may be solving the issue, or working with the people who are solving the issue. The main thing is that the owner of the card is the person who is following up on getting the issue resolved.
It is best to have just one owner, rather than many owners on one card, that way, people know who to talk to about status of the issue.
4. Shut it down quickly
Each card must have a date to resolve the issue by. Write the date on the card, or add a date to the Trello card. This gives urgency to the problem.
Focus of the standup should be on “shutting-down”, “closing” or “resolving” cards. If at each stand-up the issue is not getting resolved by the date required, then this is a problem and a hint that it needs more attention or a different approach to solving the problem. If the card was resolved since the last stand-up, then this is the opportunity to update everyone that the problem is solved and how it was solved.
For the co-located team, you can draw a line through the card, or put a green sticky dot on it to mark it as complete. For the distributed team, move the Trello card to Done.
The benefits of these four steps is that focus is on a lightweight governance model to address the problems quickly and with a shared understanding without getting bogged down in heavy process and tracking usually experienced in issue management.
These are my experiences, but what have you seen that works for issue management?