Agile governance – does it help or hinder?
Agile ways of working have matured over the past 20 years and are firmly embedded in many organisations.
agileKRC helps organizations transition to agile with agile consulting, coaching, and training. One way we suggest to our clients that they can succeed with Agile is to have good agile governance in place.
There is a big difference between using agile on small projects or as part of business as usual and other situations usually in larger organizations. In more complicated situations and possibly with distributed teams, lies the controls that are placed around the agile behaviours and working practices.
Agile governance – a contradiction?
There is an assumption that agile and governance are contradictory terms, however, in most respects it makes sense to mix the two together. The combination of agile and governance can lead to huge potential. To succeed in agile and enjoy the benefits, it is essential to have good governance in place.
In the many occasions when I have delivered this presentation, I find that many people are interested in the subject of governance on agile projects. Attendees often come with the assumption that the idea of the words ‘governance’ and ‘agile’ being in the same sentence is a bit like mixing oil with water.
However, at the conclusion of each presentation there is often a tremendous sense of interest, and I have to say excitement, as everyone (well nearly everyone!) realises that not only is agile governance possible, but in most respects it makes perfect sense.
Why are people against agile governance?
I believe it is for two reasons: fanaticism and stereotyping.
By fanaticism I think a lot of the misunderstandings come from the extreme end of the agile community. They see words like ‘control’ and ‘governance’ as an anathema to ‘the agile way’. Even the role of ‘project manager’ brings hoots of laughter as they believe it to be a relic of the past.
By stereotyping I mean that if anyone mentions PRINCE2 or terms like ‘project assurance’ and ‘business case’ then this must surely mean we are talking waterfall, big design upfront and lorry loads of documentation.
But the reality is somewhere else. Agility needs to be controlled, and control needs to be flexible.
The difficult bit though is knowing what flexible control looks like and sounds like. What does an agile business case look like? What do you assure on an agile project? How do you control funding on an agile project? How much does the sponsor need to know, and what does he or she need to do?
So, the assumption that agile and governance are contradictory terms is not true in my opinion. The truth is that this combination creates huge potential when combining the best of both worlds.
It is not an easy thing to do as some areas need to change and some don’t. The key is to identify what does and what doesn’t need changing!
As an example, it is important that if a project is using timeboxing and fixed resources you need to track features delivered instead of tracking time and cost.
In this video, Keith Richards, the Founder of agileKRC and Lead Author and Chief Examiner for Agile Project Management (AgilePM) and DSDM Atern looks at how to ensure that governance is ‘agile friendly’.
Keith looks at what can be reused and what needs to change. He examines what works well to ensure deadlines are hit and quality is protected.
You may be surprised by some of the points made in this video – sometimes ‘less is more’ when it comes to control, whereas at other times it can lead to disaster!
In this video, Keith covers several aspects to agile governance including:
- What agile governance is, and what it looks like, and how it’s done
- How to combine agile and governance
- What is agile
- What it means to be agile
- Why everyone needs to change to be more agile
- How to make agile governance a reality
To see a PDF version of the presentation used in this video, click the download button below.
At the end of this webinar there were several unanswered questions which Keith didn’t have the time to answer. These questions and their answers are presented below.
It is easy to box agile for tasks, but more difficult to integrate agile across the whole of the PRINCE2 processes. Does PRINCE2 need to change?
I agree with the sentiment of the question and yes PRINCE2 needs to change but this change is more of an adjustment in a few key areas (such as how to manage scope), as opposed to PRINCE2 under- going major surgery.
Clarity still seems to be missing from agile itself vs the methodologies of agile. Will agile governance change in line with a particular agile methodology?
I agree that there is a lot of clarity missing from agile, and I think this is because it is such a large subject area. I do think that agile governance will be slightly different depending on the flavour of agile, but I think this is more a case of nuances rather than anything major or significant.
If your scrum master and product owner can handle the agile governance duties, why do you still need a project manager?
The short answer is that you don’t. However, I only see this applying where the task in hand is relatively straightforward. This would not work on a complex project in my opinion.
How do you ensure that agile governance doesn’t become command and control – especially when directors are so used to command and control?
With great care and hard work! In some senses this is the $64,000 question because it addresses the big cultural issues of agile. The simplest piece of advice I can give is to get the directors in a room and explain what agile is and what role the directors need to play.
Did you say that a single product owner is a liability?
Yes I did. I have not checked the recording to confirm this, but I think I would have probably said ‘can be a liability’ or ‘may be a liability’. The point about a single product owner is that it can be a single point of failure. If the product is relatively simple and the product owner can encapsulate all the views of everyone involved, then this is fine.
But I find from my experiences that this condition rarely exists. The secret to success of building the right thing is to manage several stakeholders and canvas several reviews.
I’m still curious about the three doors slide. Why do you have double the probabilities if you change? What did you want to get at with it?
The point of the three doors slide was to get a message across that sometimes, common sense isn’t the answer, and the answer is sometimes counterintuitive. Most people think that sticking with the same door is sticking with the same odds when in fact the opposite is the case and can be proven mathematically.
This is why educating people to drop things out and deliver less may sound like heresy but actually may result in you delivering five projects instead of four. So, delivering less ends up delivering more’ sounds counterintuitive.
I am happy to share some feedback that I may have confused rather than helped with the three doors analogy so rest assured this will not be used again on any future webinars :-)
What does it mean to put ‘flexing of scope’ centre stage? Shall we not commit to anything in a timebox but only giving a ‘flexible deliverable list’?
What I mean by this is that the best thing to manage and play around with on a project is the scope. However, I do not want that to sound like everything is flexible. On a normal project there will be a lot of things that must be delivered, several things that should be delivered, and other things that could be delivered.
The skill is to make sure that if anything isn’t delivered it is low priority and therefore low impact. If you end up flexing or dropping out half of your project or timebox this is technically known as a ‘bad day at the office’.
So how is agile governance implemented? Is it one person overlooking the project?
It depends on the size of the project and how much governance is needed. On a very small project it may well be that the project sponsor could cover all the governance requirements. However, on a more complex project you may need a more complicated steering committee in position so that the views of the supplier, customer and the business case are all appropriately represented.
How do you define stages when your scope needs to be flexible? Isn’t having stages just ‘big’ waterfall?
This question covers two things. Firstly, it is a very agile concept to break a project down into chunks and deliver areas or groups of functionality one after the other and therefore get early ROI and feedback. Secondly, the term ‘stage’ needs to be treated carefully because if they are PRINCE2 stages then these are fire-breaks. You put them into a project to ensure that the business case is still sound. These should not be confused with technical stages which can look, sound and feel like waterfall terminology.
Are you aware of any tools that support agile governance?
Anything that helps you with agile governance and is a tool is, by definition, a tool that support governance. I am sorry I cannot be more specific here. Any project management software or benefits tracking software is in effect a tool that ‘supports governance’.
Should agile be about adopting things that work from a tool set not turning Agile into a formal methodology? I am seeing ‘Agile’ turned into a new ‘religion’ which is anything but agile and uses hugely complex process and supporting tools
This is a very tricky question to answer succinctly because primarily if you come at any method or way of working from a tool perspective it is not the best direction to come from.
My suggestion is to see agile is a framework and a collection of behaviours, approaches and techniques that need to be used appropriately. Any feelings that this may be a religion or cult normally comes from extremists and the evangelists that in my opinion don’t really help the cause of agile. Always remember, agile is a means to an end and not an end in itself.
When projects get closer to the go-live, the remaining scope can all become ‘required’ so there is no scope for flexibility in the product backlog which you had in the timebox backlog – how do you deal with having fixed date and quality but no flexibility in scope – all remaining features need to be delivered?
I really like this question because I get this one a lot and I’m really sorry to say that the only answer I have is that you are in a lot of trouble! There is no magic wand when you are in this situation.
If you have been timeboxing correctly and using the correct feedback loops with your business representatives/customer, then you should not be getting bad news as late as this. It should have come a lot earlier.
Agile and methods like DSDM are very much about ‘if you’re going to fail you need to fail fast’. When I am training and consulting, I always say to people that projects never go wrong at the end. They go wrong many, many weeks and months before that, it’s just that people wanted to look the other way. Golden rule in the agile workplace is never say ‘we’ll catch up’.