Overcoming reticence to use RAID logs

Question

When managing a hybrid Agile project with both business and I.T workstreams, let's assume there is a requirement from the internal PMO to use a RAID log. However, you will also need to interface with a Scrum Team to track certain issues and actions. The organisation has a mandate to go Agile but has not implemented any agile governance before.

Staying with Actions for now, I've noted in the past that nobody on a Scrum Team wants to even look at a RAID log. They do, after all, look like something from 20 years ago, whilst Scrum Teams in start ups and digital agencies are using tools that are much more non-threatening and usable, and this is a factor if we're talking about motivating people to help out.

How have people tackled this kind of situation?

One idea I have seen used very well is to replace an action register with a Trello board. It's a slick and usable product, you can use avatars, easily upload attachments etc, and it can be used to model a Kanban board which Scrum Teams will be familiar with from using JIRA. Suddenly talking to the dreaded delivery manager / program / project manager isn't so bad. They aren't stuck in the 1990's, and it feels more like the safe environment you're used to working with alongside your Scrum Team.

Answer 1

My answer is not a canonical answer but rather my observations and opinions from years of practice.

I have found that project teams typically detest and avoid these types of logs no matter if the project methods are agile or not. And I opine the problem is with the governance around the logs themselves vice the concept of having a log to record things.

It Becomes About The Log

The log becomes a deliverable of and in itself. It becomes a product that is nurtured, scrutinized, argued, manipulated, and on and on--versus a tool to track stuff. Teams argue the language used, the message delivered, whether something should be in the log or not, whether the language is clear enough, whether something is a risk or an issue, whether there are grammar errors, whether the title of the record is compelling enough.

On on project as an example, a particular stakeholder thought it necessary to record every item possible and the logs ended up with hundreds of lines of actions, issues, risks, etc. Most of the items were just normal, everyday activities but it required hours and hours and hours to maintain and to keep relevant with no return in value. The team hated this log because they were demeaned if the language was just not right--in the sole opinion of this stakeholder--and caused rewrite after rewrite after rewrite, and meetings to work on the language before it got presented, and more meetings to address the changes. This is an extreme example of silliness but I have witnessed this project after project, but to a lesser extreme.

Your logs should contain only your top five or six items. Maybe seven. These are the highest priority items that you need to track, the most expensive, the most impactful. The rest fall off and are delegated to the teams, who themselves likely maintain their own logs...or should be encouraged to do so. By doing so, the logs remain truly relevant and important and even a SCRUM team will look at them and find them useful, I suspect.

Answer 2

Scrum teams don't dislike RAID logs because they look like something from 20 years ago. They disklike them because:

• Frequent releases reduces the value of tracking risks
• Agile values conversation over documentation - hence the sprint retrospective is the preferred place to resolve problems
• Letting RAID logs be viewed by people outside the Scrum team runs the risk of misinterpretation - these people do not have the same context the Scrum team members have