When I worked at Nokia, high level management decided to work according to Agile, a cross functional group was created to ensure that the changes needed for the organization was implemented. An external Agile coach was hired to help the change management process - Dean Leffingwell, this was probably one of the most important reasons why we managed to change the organization successfully (at least according to my understanding); Dean brought experience from other organizations and was a valuable coach to discuss the changes we did – however it was also important that we did it our way, and not only according to how it was done in other companies.
When you talk about working with Agile and Scrum, people think about the teams working in Sprint, but often forget that the entire organization need to change to get everything to work. There are many things involved in changing a big organization into Agile way of working, I will focus on Portfolio planning in this description.
When Nokia did portfolio planning, the steering committee looked at the visions and high level stories (epic’s) and prioritize it according to each other on the portfolio planning backlog. I will here try to describe the lifetime of an Epic and give my comments on what was good and where we could improve – now that I can be wise afterwards, please notice that I do not know details at portfolio planning level, but I have a fairly good understanding of what happens after portfolio planning, so I believe that my picture is fairly correct, at least good enough for an illustration…
When a new Epic was created, s short high-level description would be created together with a profile where cost, time and competence was estimated (very high level), this was very rough, but gave an idea of what it would require to implement the Epic.
The steering committee would receive a presentation of the Epic and decide if they believe that the company should invest in this or not – if the Epic is important enough, it will enter the backlog of the portfolio planning.
Now the really tricky part comes – priority – it is so simple when you say it, but I have never seen anyone who did not struggle with this, it is so easy to say yes and extremely difficult to say no – but we always have a limited number of resources and need to priority what we want to accomplish. The backlog with Epic’s have to be prioritized, normally a new Epic only have to be compared to the others to be prioritized, but at the end, it could mean that some of the old Epic’s on the backlog would not be implemented. The steering committee will not know details about resources available and cost of Epic’s, but they would have a rough overview, this overview was updated by the portfolio planner contact person, we can call him mister X, mister X was the interface to the different organizations that was implementing the Epic’s on the portfolio backlog. Figure 1 illustrate the flow:
Mr X and a planner from each organization was having regular meetings (I think that each organization was 100-250 people), the planner in each organization knew exactly how many resources they had, who was working on what (maintenance, Epic x etc.); when a new Epic arrived, the resources (based on the profile) was allocated (PO and teams), they would then make a better estimate and feedback to the steering committee – if there was not enough resources available, they would go through the Epic’s from the top and secure that the Epic’s with highest priority was the once that they were working on and inform the steering committee about the results, update Epic-profiles etc.
The important thing in this flow is that the resources follow the Epic!
The PO and the team execute the Epic, the PO is responsible for writing a DoD for the Epic and together with the team to create a release plan for the Epic, this will be communicated to the stakeholders – including the steering committee.