Agile governance – does it help or hinder?

Introduction

Agile ways of working have matured over the past 20 years and are firmly embedded in many organisations.

agileKRC provides agile consulting to organisations to help them transition to agile. 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.

Video

In this video, Keith Richards, the Founder of agileKRC and Lead Author and Chief Examiner for Agile Project Management (AgilePM) 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!

Download PDF

To download a PDF version of the presentation used in this webinar, click the button below.

Further questions

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 use 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 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 functionalities one after the other and therefore get early return on investment (ROI) and feedback. Secondly, the term ‘stage’ needs to be treated carefully because if they are PRINCE2 stages then these are firebreaks. 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 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 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’.