You’d think I couldn’t win. Senior corporate managers are nervous that I am doing unconventional agile stuff, without those reassuring Gantt charts or status reports and hardly any formal minutes. Agilists are horrified that I advocate Agile Governance.
This conflict isn’t impossible it is just one of many places where I can demonstrate that Agile practices aid traditional processes/goals. In this case programme/project governance. I start from the position that governance is not contrary to Agile, it is built in. Rather than less governance my Agile programme actually has more governance than is the norm and is is safer as a consequence. Given this position is fairly controversial I thought I’d explain how I go about governance at the moment. I’ll give you a clue – there is a lot of talking.
To the surprise of some folk, those used to traditional forms of governance, I don’t depend on written reports or a PMO, and I try to keep formal meetings to a minimum. I’m sure the traditionalists are getting nervous already. So I think it is important to take a step back to look at why these activities are included in projects/programmes. In my opinion the goal is good – governance – but the technique is flawed – status reports, formal meetings, etc.
I previously defined Agile Governance as:
Governance is the alignment of an initiative (project, programme or product development) with organisational goals to create value. Governance defines how the initiative is set up, managed and controlled.
Agile governance is the application of Lean-Agile values, principles and practices to the task of governance.
So what I do is walk around, observing and listening, attending lots of stand ups and show n tells, then, on a regular cadence, I tell my stakeholders what is going on. It isn’t traditional but it is governance. Agile governance.
What that means in practice is a lot of meetings. The foundations of Agile Monitoring and Control are the daily stand up and show ‘n’ tells, supplemented by a Scrum of Scrums (or similar) for cross-project coordination. I add in more conventional meetings as appropriate or because the context demands – “Steering Groups” if you will. When forced I’ll even do status reports.
When I put all of that together for my current programme I ended up with the following governance routine:
Agile Governance Example
Okay, I didn’t include “Coffee” or “Burger Friday” in the formal powerpoint slide I prepared recently for senior management on my governance structure. I thought that would be a step too far for for them. But those informal interactions are important and are indeed part of governance.
Coffee
I bring a coffee culture with me. There is a lot of “grabbing a coffee”. This is my chance to catch up with folk across my programme to collect and share information, and to make tactical decisions.
Programme Technical stand up
Once a week I get my technical architect and the senior folk from the work streams together to do a sort of Scrum of Scrums. The focus is cross project risks and issues e.g. resource constraints. This is an informal 15 min stand up meeting in front of the programme level board.
1-2-1 meetings
Every week I have a 1-2-1 meeting with two senior managers. As I’ve said before I only see four reasons to book a regular one-to-one meeting, and in this case it is to ensure I get time with those managers. It is partly to keep them abreast of what is going on but also an opportunity to enlist them in addressing risks and issues.
I do not book regular 1-2-1 meetings with the people on my programme team. I don’t need to as I talk to them all the time.
Burger Friday
Somehow we’ve ended up with a tradition to have burgers for lunch on Friday. So every week my London based project managers and I head around the corner to fill up on beef and discuss the issues of the day.
Programme Steering Group
The Programme level Steering Group is a one hour formal meeting with the stakeholders from the four departments affected by my programme and a couple of executives from the Corporate Board. The focus is programme level progress (technical delivery, change, and benefits realisation), risks and issues. It is also the forum for discussing key decisions – although the actual decision making occurs outside the meeting. This meeting happens monthly. I even write minutes.
Work stream stand ups and boards
Each of the work streams has their own daily stand up meeting. In front the team’s board or boards of course. The focus is planning the day but covers progress, risks and issues within the work stream. Informal 15min stand up.
Work stream build monitor
Personally I believe build monitors are part of the governance structure. They are early warning about whether the work stream in question, and possibly the programme as a whole, is in trouble. Code, build systems, automated tests, and the pipeline to live are all incredibly important to me.
PM (of WorkStream 2) at stand up for Work Stream 1
On my programme there is a specific dependency between two of the work streams (1 needs 2). And to make it trickier these teams are in different cities. To address that dependency the PM from work stream 2 (Rachel) attends the stand up of work stream 1 each week. This would be a little excessive if it was only a single 15min meeting that she had to attend. So On that day Rachel:
- Attends the Stand up for Work Stream 1
- Attends the Programme Technical Stand up
- Catches up with me
- Touches base with the Business, who are based in London
Work stream conference call with vendor(s)
Two of my work streams are reliant on 3rd parties which demands an additional level of formal communication. For this we use a weekly conference call. As usual the focus is progress, risks and issues within the work stream. Duration: 30 minutes. We vary this occasionally with a face-to-face with the vendors – when they are in town.
Old fashioned status report
I try never to ask one of my project managers for a status report. However, one of my current work streams is within a department that prepares a weekly status report. My work stream is included. It isn’t the kind of thing I look for but I’m not going to object to it.
Show n Tell
Most of the work streams have a fortnightly show n tell where the team reviews with the product owner and other stakeholders what they produced.
Workstream 1 and 3 are both a bit unusual and do not have a weekly show n tell. This is because they don’t have a internal development team and are more focussed on coordination and business change.
Work Stream Steering Group
One of my work streams has a Steering Group that meets fortnightly. This is similar to the programme level group but the focus is tighter – one work stream – and the attendees include those interested in the nitty gritty detail. I inherited this group and I’m not a super big fan, but until the attendees decide for themselves that we don’t need it I’ll keep the meeting in the mix; for the moment they are still keen.
Other options
What I’ve described is what I’m doing on my current programme. I used different techniques and/or combinations for earlier initiatives. It is all about context. Mix and match what you need for the programme and projects you are working on, and organisation you are working within.
For example, on my previous programme in the same organisation I used a weekly Agile Status Report for Executives: Best, Worst, Throughput. That was mainly because the development team was in a different city to the business so I needed a light weight mechanism for continual communication. The “Best, Worst, Throughput” format gave me that, supplemented with other face-to-face options when we could manage it.