While listening to the Usurping Agile podcast, I heard a couple of mentions that creating a RAID log as an outcome from a Retrospective was an anti-pattern. I didn’t understand why capturing or documenting risks, actions, issues and decisions was anti-agile.
Looking for some clarity. I thought that documenting and tracking this information (in a light-weight way) was good.
Thanks,
In my opinion it’s not the act of collecting the data that is the problem. It is how it is used.
RAID comes out of a PMI/PMO mindset, and is often an extensive log of “issues”
And that log is used to assign accountability (aka “Escalate”) and quite possible blame.
It is less of a “hey, here are the top five things we want to take on as candidates for change over the next month” and more of a “hey, this is on the list that the executive leadership is paying attention to…”
The same can be said for RAG project status. We did a podcast on it recently. Fundamentally, there’s nothing wrong with stating that your project is yellow, or any other color. But if you use the project status to beat teams over the head when they are “bad” then they will never be honest and orgs can’t solve problems together.
I hope to God that risks are communicated across the board. But will I be punished for saying I made an assumption about this topic? It’s up to the group to use data points better.
Intent and actions here are so important. Metrics can help a team improve and managing risk similarly at a team level. The moment any metric is used to chastise and target individuals we have big issues.
I am partially in agreement with what is being said here.
We need to be clearer that Agile / Scrum is not a project management methodology. It is a software development methodology. It does not offer a model for planning, period.
Also it brings some new concepts that do affect how work should be approached, now in terms of “products” rather than “projects”. But it actually creates an issue that it does not resolve around planning.
Agile (and Lean) only focus on the flow of the work. Not on planning the end dates.
Enterprises need planning. Not everything can be just left to a flow. At least not until major-mega-big transformations have occurred. By creating a problem without a solution, a lot of the frustrations are emerging as a result in the Agile journeys of most Enterprises.
Agilists argue that until the Enterprise has reached this major-mega-big transformation, it is not going to work well, making the case for more transformation, but also leaving a trail of chaos along the way. This is generally winding Exec Management up and detrimental rather than helpful to Agile transformation.
Another approach consists in doing this small enough at first to not need big solution and move quickly from this. This again struggles to gain traction in big enterprises.
There is a need to establish planning substitute outside of the Agile flow and in a way that is compatible with an Agile operating model / experimentation cycles. Even if the end-game is to have short cycles as the norm and the organisation aligned around this, there needs to be an intermediary approach to planning.
I am actually thinking of this and quite a bit has already been written on the subject. Something like speculative planning rather than predictive planning. Estimation of the work is banned, it should be based on true progress, and mapping the future volume of work (with the various levels of granularity of its definition to past work). eg. #of Features per flow / #of stories per feature / avg story size, etc. The key thing is that never people estimate the backlog, this should be based on observation and true pace of work. You may even model resolving waste, improving velocity, etc. and eventually establish ETA of the desired key features. The understanding of such models is that it is only speculative and non-committed by the team as the scope is actually unknown. In such model some traditional artefacts of planning could still happen under the understanding that all is only speculative.
Driving change is very much about understanding the reasons for resistance to change, derisking the situation, educating, creating a zone of comfort that enables progress to a better state. I believe that establishing an approach to planning compatible with Agile is necessary to help enterprises transforming.