Project management in the enterprise
An organization had invested in a project for years to replace an old system by a new system that should be future proof. More than 50 people worked hard. In time, many project members changed, including several project managers.
The current project manager decided to avoid that this predicament, so he chose a radically different approach. He fundamentally organized the project so that it became a new project. A new start architecture was designed and a Scrum way of working was chosen. Assisted by experts in that field, he made a proposal on the new way of working. Teams of a maximum of 9 people were then formed, each of which had the responsibility of a part of the system. Each team was given its own Team Product Owner and Scrum Master. There was also a Chief Product Owner who covered the formal interface with the business. The project manager supervised the coordination with the (traditional) steering committee and involved integrators and operations at the time.
Sprints of two weeks were agreed, in which an increment was completed which was good enough for deployment. Each sprint results were presented to all stakeholders. These turned out to be better every time and everyone was proud.
The product owners met weekly, together with a technical representative from each team. They refined the features for the coming sprints for each team. All features were documented in a joint product backlog. Overarching technical barriers were discussed in this forum and possibly resulted in backlog items. Planning poker cards were used to prioritize and order the backlog and to estimate, so that it clarified which next features had to be worked out.
The quality was getting better every sprint as everyone was able to oversee the scope of its own part and could estimate what the impact of his activities would be. The big project was a large success.
What can we learn from this?
Scrum is designed to work in teams of up to 9 people. As long as the scope of work can be handled within a team, Scrum can work very well. By using multiple teams that stay tuned, large projects can also successfully be managed.
In many organizations, it is utopian to think that teams can go their own way (autonomy). Even more, there is always a bigger scope and so alignment is needed. It is therefore important to optimize collaboration between Business and IT as well as the collaboration between development and operations. In the above case, the organization learned to get the right balance between autonomy and fast alignment which can be supported by one of several standardized approaches.
Since the alignment problem is not unique, there are several initiatives to support a standard solution. See for example agilescaling.com for an overview.
The above picture shows an agile framework at enterprise level (see also scaledagileframework.com). This can be used as a tool to project in your organization. In the framework, the role of project manager is not present. Fortunately, there are roles for which project management skills are sorely needed, like the Release Train Engineer, Product Owner, Scrum / Agile Master and Epic Owner. Please note: The framework is a tool, not a goal.
To come this far needs some time and some resistance needs to be overcome. See the overview of Shore and Larsen. One single person cannot get the blame for the failure, it’s just a mutual success. The football coach (from Part 1) is not the one who determines everything autonomously; he’s part of the system. For management this feels uncomfortable. From command and control to servant leadership. From work to result oriented.
Most people who are accustomed to the new situation would not go back to old ones. This applies to both the employees from the IT and the business, but also to management. Even the most skeptical people quickly adopt this way of working after they have tried it out.