Lessons from a year in SAFe: If you talk about risks and dependencies long enough, eventually every team will have them
This is the third article where I write about some of the things I learned while working in SAFe as a Team Coach and Product Owner. I’ve previously written about how you should focus on teams’ maturity, rather than focusing on specific roles and how you can use the ART Planning board to highlight the problems you’re trying to solve. Now, let’s dive in to my third lesson.
Lesson #3: If you talk about risks and dependencies long enough, eventually every team will have them
During PI Planning, risk management is an important aspect for each team and train to consider. SAFe talks about the importance of managing risks and ROAM:ing them properly. Furthermore, risks and dependencies are visualized in tools such as Jira and Azure DevOps.
In my role as the Team Coach I was in coach syncs where they were always discussed and also when the entire train was gathered. I often got the feeling that we were “doing it wrong” if we didn’t identify enough risks and dependencies. Looking back at this, I don’t think the issue is that you encourage teams to identify and visualize this, but what you might want to consider is how this could create value for your teams and the train as a whole.
It’s hard to get the full picture before we start working on it
When a product team initiates work on a feature or dive into a problem worth solving, it’s hard to have the full picture of potential dependencies and risks at the start. That’s fine and probably the way you want it to be. If we spend too much time on identifying dependencies and risks early on we’re probably never going to put anything into production. If you want to be as agile as possible, there is always a trade-off between the cost of knowing everything before we start development and finding it out as we go. I get it, some companies are huge with a complex architecture, but if we would encourage our product teams to be as obsessed with our customers as many teams within SAFe are when it comes to dependencies and risks, we would be better off for it. Which takes me to my next point.
Think about the type of risks your teams are raising
Being proactive as a product team and having the ability to figure out risks that might impact your deliveries is a great quality to have. But if you think about the type of risks that are raised during a PI Planning, how many of them are related to not satisfying the end-user or reaching a specific outcome? Team X not completing their development in time and thus impacting Team Y is something we want to avoid but what if the things both of the teams are working on have zero impact on customer satisfaction or our bottom line? The counter argument to that might be that it’s hard to gauge if the things we’re working on are impacting that but if you don’t have a hypothesis regarding this, then why did you initiate the development to begin with?
If you take the time to identify dependencies you should also take the time to eliminate them long-term
What ends up happening during a PI Planning is that a team will do a great job of identifying dependencies to other teams, both in the train and in other trains. The Team Coach or Product Owner will then initiate contact with that team to perform a handshake that the dependency can be handled in the upcoming PI. But rather than just doing that, I feel it’s important to identify the root cause of a dependency. Especially if the nature of the dependencies are systemic. Then leaders within the train (RTE, Business Owners, PM:s, Architects) should do their best to communicate this to their respective stakeholders and ensure they can get the prioritization to solve them long-term. The solution might be big in size (change in architecture, team ownership etc) but could be so important for the long-term success of your train.
Like I said in the beginning, the issue is not that you have a practice of identifying risks and dependencies but rather how you approach it and what you do with it long-term. Risks related to not realizing your product vision or impacting the bottom-line are often neglected in favour of more concrete dependencies and risks. That’s a problem if you want to be a customer-centric company and maximize the value from your product teams.
