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.

  • And how is the gap to the RAID log bridged? Commented Jun 8, 2017 at 8:11
  • What I am alluding to is reverting to Trello to track Actions on a program or project, instead of the RAID. Risks, issues, and dependencies can be maintained in (e.g) google sheets so we can remain collaborative, but I'd see the engagement with any scrum team members centering around actions. Therefore the PMO would still still get a RAID log, but a hybrid-agile one, essentially. Commented Jun 8, 2017 at 8:59
  • Who's maintaining the RID parts? I'm asking because "centering around actions" is not too clear in this regard, and I'm very curious what you saw being used very well. Commented Jun 8, 2017 at 9:38
  • PM maintains a RAID log but in this case the A is Trello. Commented Jun 8, 2017 at 9:58

2 Answers 2


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.

  • 1
    Thanks for sharing! -- I have Q. Is a reduction to five to seven items, and delegating the rest to the team, your governance advice, or do you have more suggestions? In my experience, people often don't have the mindset to think about the project / product this way, but that's not openly addressed, and usually there exists a widely accepted excuse which everybody can refer to ("useless activity", "no time", "I don't have to attend"). Which raises the question how at least that little bit of risk-based thinking can be established in such a team. Your A seems to imply that it is already there? Commented Jun 8, 2017 at 12:46
  • 1
    Thanks for this. Indeed, I've experienced the same thing where agile teams are horrified by a RAID log - and I've had senior managers obsess over maintaining it. But then the PM can turn into an administrator, which is soul destroying and pulls you away from strategic thinking and debugging your project eco-system. I'm working with a client who is looking to move away from obsessing over an audit trail and they want to be more agile. So your suggestion of keeping it 'impactful' is a good one. Have you seen Trello being used? Curious. Commented Jun 9, 2017 at 3:27
  • @loomwithacrew, you should post your question in this forum. It's a tough question and a not so easy answer! Commented Jun 9, 2017 at 11:25
  • @ProjectWorf, have not used Trello. If you end up using it, post back later how it worked out. I'm generally tool agnostic. I'm more on the people performance, psychological, and behavior side of things. Commented Jun 9, 2017 at 11:27
  • @DavidEspina positif Commented Jun 12, 2017 at 13:02

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
  • 1
    I agree with all of these @Barnaby, thanks for sharing. Points 1 and 2 are my biggest bugbears with RAID logs generally, as time is consumed with administration, which for a project manager can destroy your capacity to think strategically and about the program or project eco-system in general (i.e. applying systems thinking). And yes, good point - the act of writing things down which management are going to see could seriously damage the relationship between a PMO and the scrum teams. "Who is going to read this?" etc. Awesome post. Thanks. Commented Jun 14, 2017 at 1:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.