From Agile Program Management perspective how do you manage
dependencies and risks? Do you identify
what is under your control and manage those alone? Do you assume risks – do you
assume that risks will be taken care of by those who have full control on the
risks? Or do you consider those as part of your action plan? This is what I
plan to discuss in this post.
There are ways to identify and handle dependencies in projects. I had discussed this in one of my previous posts. Also, agile methods have inbuilt mechanisms to manage dependencies and risks such as Release Planning, Sprint Planning, Scrum-of-Scrums, Agile Governance etc.,- provided these mechanisms operate in an orchestrated manner. Does it happen on the ground across all projects and situations? Well, it depends! In the name of ‘Inspect and Adapt’ some Agile teams succumb to the ill effects of poorly managed dependencies and risks. And of course, they retrospect, learn and improve. Or they fall in to the same traps again and again.
When it comes to Agile Program Management that involves multiple interrelated projects, the dimension of dependency and risk management becomes even more critical. In one of the programs I was part of we had a good grip on internal dependencies and risks. Those were the elements on which we had full influence or control to steer them in the right direction or implement mitigation plans to reduce the overall impact. However, we had external dependencies and risks too. Those were the elements on which we had either partial or no control to steer them in the right direction. One of them was about a dependency on a third party products. These products were evolving and the corresponding vendors had announced dates for the next releases. The products got released and as you may guess they were not stable enough because of defects and performance issues. The host of applications that we were building were being built on one or more of these products. Now you can guess the impact!
We had multiple releases to go and more or less all these releases had dependency on the enhancements and upgrades of these third party products – these products had a release road-map with multiple releases too. If we assume that everything will go according to the release road-map, it is a risk. If we become paranoid it is unhealthy and risky again. Collaboration and continuous planning is what helps in such situations.
Classical program managers resort to assuming certain entry and exit criteria. For example, ‘Let us assume that the 3.1.2 release of the product from our third party vendor will be ready on 10/23.’ Is that a good assumption? Or is that assumption itself is a risk? Or should the assumption be collaboratively vetted or validated at regular intervals? Who is responsible for this? Agile Program Management is. This is because, individual project teams are busy moving from one iteration to the other. Scrum of Scrums happen in large projects. Project teams sometimes become too busy to pursue these. Either implicitly or explicitly they call it out or call for support. Coach them to make it explicit so that the program management team is aware. That is what I would recommend. And make it explicit at all appropriate levels and own it as part of Agile Program Management. This is true for all kinds of dependencies and risks – both internal and external. Program Management team needs to be at the eye of the storm in such situations and have a clear focus on how to manage situations. Else, they become an extended arm of project teams and remain equally clueless. They lose focus and become inadequate to arrive at optimal solutions or pragmatic decisions.
It is about seeing the forest but not losing sight on trees!
