Programme Management in an Agile Organisation
Developing and launching products is a team activity, it involves the efforts of development, marketing, sales and support functions. The tasks performed by these functions can’t happen at random times, they all need to be co-ordinated.
Traditionally it has been the responsibility of a project / programme manager to perform this co-ordination and report progress (or lack of it) back to upper management and ensure their suggestions get implemented. The conundrum is how do you do this in an agile organisation without it feeling like some form of top down management.
This article shares how Redgate has been iterating on finding the approach that best fits with our ambition of having empowered teams, yet also provides the co-ordination for and transparency into what is happening and allows managers to offer valuable input when they have new information or can offer a wider perspective based on their experience.
Background
Agile organisations work in a different way; they’re made up of empowered teams; they push the decision making as close to the data as possible; they work in rapid cycles of learning and adapting; they’re supported by a servant leadership model (rather than a command and control one); most communication tends to happen horizontally rather than vertically.
But for all that these organisations do have some form of structure and every organisational structure will be optimised for one factor at the expense of another, they are all compromises.
Back in 2016 Redgate reorganised itself using a functional structure, with a division for product development, one for marketing and one for sales etc. This meant people felt accountable to their function but not necessarily to the overall successful delivery of a product. At this time, they also got rid of the project manager role for product development but introduced a Development Lead role to be a servant leader for the product development teams (I’m one of those Development Leads).
This left two problems, how to ensure activities are co-ordinated across the divisions and how do divisional management gain insight to what is happening.
Iteration 1
Redgate was approaching launching their first product since the reorganisation, everybody wanted it to be a success, the divisional leads were being held accountable for making it one, so they called a regular meeting with the Development Lead, Product Manager and Product Marketing Manager.
These meetings were horrible, they felt like you were having to justify decisions already taken, the right information or evidence was never to hand (as you didn’t know what was going to be asked), nobody wanted to be there and not only did they feel like a waste of time, they felt counterproductive and it started generating a bit of an “us & them” mentality, they certainly weren’t changing any of the team’s activities.
They improved significantly when, following conversations, it became clear that they (“the management”) were just trying to help and were trying to work out where to spend their efforts. They instantly became less adversarial and more productive.
We learnt from this to be clear with everybody about the purpose and motivations behind any meetings, and be wary about taking actions that, however well intentioned, damages trust.
Iteration 2
Redgate had several companywide initiatives which involved teams from different functions and wanted to ensure they were achieving the expected outcomes, so “programme management” was thought of. This involved identifying a sponsor, work stream leads and a programme manager. There was to be a monthly A3 report and a monthly meeting with the sponsor, work stream leads and other key stakeholders to discuss progress, risks, issues etc.
Most people involved had worked at other organisations that had programme managers and they all expected slightly different things from the role, such comments as “I’m glad you’re the programme manager, means I don’t have to worry about this anymore” and “You need to ensure I do the things I said I’d do” were heard, which didn’t seem to sit well in the type of organisation Redgate aspired to be.
The one thing that became rapidly apparent was that to do the role well was probably a full-time role and was being performed by people who already had another job, and in many cases didn’t aspire to be a programme manager. This resulted in nobody’s expectations being met and the programme manager feeling constantly under pressure.
The other lesson was the fact that the monthly meetings never occurred just when a stakeholders input was required, things were just moving so rapidly that all the discussions, decision making etc. was performed outside of the monthly meeting and frequently the information on the report was already out of date, rendering the meetings redundant.
Iteration 3 (current approach)
We’ve kept the concept of work stream leads and have clarified the expectations for this role, they are responsible for knowing what is happening in each of their areas.
The Development Lead is responsible for ensuring the work stream leads meet and co-ordinate their activities.
We use OKRs in the product teams, which provide insight into the teams intended direction and stakeholders trust that these are being worked towards. It in incumbent on the work stream leads to raise any blocking issues for the stakeholders to help resolve.
We have a great big visible progress board, which displays the current activities, risks etc. for the programme. The work stream leads meet regularly in front of this board. The key stakeholders meet weekly with the programme representatives to understand the activities and provide guidance etc.
It’s still early days with this approach but it’s feeling better. We seem to have created the right mechanisms to allow the communication to flow horizontally whilst also being able to provide a window in for stakeholders and a mechanism for them to provide input / direction.
I’m sure over the coming months we’ll learn something new which will make us inspect and adapt again.
