Archive for the ‘PMOs’ Category

Following up from my attendance at Agile Australia 2012 I wanted to provide a link to the slides and also a bit more depth of information. Unfortunately a few parts of the panel discussion overran and consequently a few things that I desperately wanted to say were unable to get out.

So firstly, for those that were unable to attend here are the slides:

A write-up of the panel can also be found in the mobile edition of the IT News.

I just want to take the opportunity to get across a few points that I didn’t get a chance to (or were slightly misunderstood):

  • Stop thinking of work as Project vs BAU. When you get to the root of who does the work often it involves the same people due to the shared service nature of organisational structures. You cannot possibly plan by looking at only part of your workload.
  • Everyone will game the system because everyone (rightly or wrongly) perceive governance to be a bad thing. You have to make sure that you consider paths of where people will game the system and either actively encourage it, gather data from it or find a way to shut gaming down in that area. For example, if your governance process categorizes projects that are < $100k as not requiring a certain level of delegation people will split the work down so that it is below $100k. Some organisations would consider this a bad form of gaming the system. I believe that if people can split the work down AND demonstrate benefits also split down then that is an excellent win for the organisation – because splitting it down has just reduced the risk of failure and enabled earlier delivery.
  • Understand prior to transforming your governance model what is broken vs what is working in the model. Understand the wait times, the sink holes, who the deliverables are for and why. For every answer you get apply some critical and root cause thinking to it.
  • Often processes and models get bloated because they are handling odd exceptions – especially exceptions of failed projects. Build a process that works for 80% of circumstances. Let the other 20% be handled by smart people.
  • RUN YOUR AGILE GOVERNANCE TRANSFORMATION AS AN AGILE PROJECT. You don’t have to do everything at once – incrementally deliver it. Once it is “in production” regularly retrospect it.
  • Who owns your governance process/model? Who is allowed to make changes to it? If your answer involves people that never do the activities involved inside of the process then you have just enacted an ivory tower PMO.

Additionally I wanted to talk about where I saw governance going in the future and what were its threats. Thankfully Martin Kearns must have read my mind and tackled part of that topic. But for my record here is my two cents – the biggest problem I see for governance groups going forward are Lean Startups.

People incorrectly think (like I did for a while) that Lean Startups are all about R & D or entreprenural internet corporations. Certainly it is what it was designed for but I have been having visibility that the concept goes wider. For me Lean Startups go back to what Agile really was meant to be about in the early days – delivering very rapidly, ideally each day, having the real customer involved and adapting to change when we find out that we got it wrong. All too often though we are delivering only once every two weeks or worst, several iterations because of perceived lack of “value” until it is 80% there. All too often we still have a Business Analyst as a proxy or a Product Owner that has never talked to a real customer in their life. When people realise that Lean Startups gives us an alternative model to give these back, people will be flocking to it.

Which brings us to the problem of how do you govern a Lean Startup? Think of it in terms of a normal project – usually you have a release date pegged, set budget, a backlog of scope and a clear definition of quality. In a Lean Startup you have a budget set only based upon a date. This date is the date under which your learning stops. If you don’t prove that you are learning then you are unlikely to get another drop of money. Incremental funding is core to Lean Startups – how does that usually work with our fixed capital financial year funds? It means you consider your capital spend a pot of money. Each time you approve another incremental drop of money to a Lean Startup you get your ladel and scoop out a bit of soup. You need to make sure you spend that pot wisely.

So what do Governance groups govern in Lean Startups? They govern learning:

  • Has the team learnt anything about Customer Value since we last saw them?
  • Has the team learnt anything about their planned growth model since we last saw them?
  • Has the team learnt anything about the way in which we can expect a return of investment (revenue)?
  • Are they learning fast enough? How fast are hypotheses being tested?
  • Do the hypotheses make sense given the data?

When I mean learning it doesn’t have to be good news – it just needs to be either validated or invalidated hypotheses.

Most governance models govern scope, time, cost and quality. How many ask the question “Are customers getting value from this product?”. How many organisations are any good at benefits realisation? We spend so much time in governance at getting better at delivering. We need to spend more time getting better at delivering the right thing.

Read Full Post »

I had the lovely pleasure tonight to see Jean Tabaka in action at the Brisbane YOW night. Topic in reflection: 12 Agile Adoption Failure Modes.

My interest was immediately peaked when the opening question was “Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.

What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.

On the first failure mode I felt a little shaky. It was called ‘Checkbook commitment’ and was pitching failure where the Agile Champion is just a Sugar Daddy (my words) –  all money but no heart. I don’t disagree with this as a failure mode but feel it goes much further. To have a Champion in the first place is a good thing. One failure mode would be that one doesn’t exist; another would be that their expectations are unrealistic and they pull the plug too early in the piece to reap the reward, or one that doesn’t stand up for the framework and lets governance bog it down with unnecessary requirements. The failure is in several layers of the Champion not necessarily that they are only a checkbook.

Then failure mode two hit: Your organisation does not support change. My faith was getting weaker with immediate thoughts as to whether this was a cop out statement. What organisation DOES support change? If an organisation was supportive on change then surely Agile Implementation would be a no brainer. This is why cultural change takes an average of seven years and without a doubt Agile is a significant cultural shift for most organisations.

Now in fairness Jean had incredible jet lag and sleep deprivation so maybe the words didn’t come out right. When the closing slide was done I looked at it curiously – failure mode two was renamed to “Your organisation does not support learning” – was the initial slide a typo or the recap was the typo or did I just fail at paying attention probably and mis read it? If the point was supporting learning then maybe I could see that as a failure mode, but this is probably the only point in the whole presentation I wasn’t sold on.

There were further comments that occasionally peaked my interest. There was a reference to ‘insight’ and I felt that this had synergy with Alistair Cockburn’s recent post of reflective improvement frameworks.

Another point was made about servant leadership and this one really made me think hard. If we are trying to achieve a servant leadership environment – is the Scrum Master/Iteration Manager role counter-intuitive to this? Is the role we seek more really an Agile Coach rather than a Master/Manager role. Perhaps just the titles are bad, but all too often I have seen teams not take on collective ownership of the story wall, not take ownership of helping to facilitate retrospectives. I have heard many SM/IMs call the role an almost ‘administration’ role rather than a coaching or mentoring role. Maybe we are doing ourselves a dis-service in the furtherment of Agile by continuing with the Scrum Master/Iteration Manager terms?

On the recent topic of PMOs Jean talked about how a PMO isn’t there to enforce practices. I think I am still in two minds about this. I have re-organised a PMO so that its key function was to ensure that prior to senior executive approval of major projects the right IT people (and by right IT people I mean the real workers) were engaged with the right business people (end users or those that truly knew the business benefits and drive) met together and both agreed that they got just enough detail that they needed to proceed to the next step and that the value was worth the effort. In essence, they were there to ensure that effective collaboration was done. Prior to implementing that change executives would approve projects with no IT input to estimates or timeframes or estimates were changed (read dramatically cut) from what the IT group provided.

Take the presentation as a whole – 12 failure modes. What if a PMO’s function was to ensure that those 12 failure modes did not occur; I wonder if that would be considered worthwhile.

I loved the idea of walking into a retrospective and asking for a confessional (sorry Jean I took this idea a little further). Imagine asking a team that hadn’t performed a retrospective for a while and asking them to start their brainstorm with ‘Hi I’m Renee. It’s been five weeks since my last retrospective”.

I loved the concept of Servant Leadership as “I raise IQ’s for a living”.

I loved the point that performance bonuses are not beneficial to Agile (I’ll probably tackle this on my next blog as it has been mulling around in my head for a few months now and I will be presenting my vision on this when I present next week at Agile Australia).

I can’t recall anything mentioned about Definition of Done on the testing related failure modes but it was on the recap slide (maybe a typo again?).

All in all I got probably 5 takeaways that really made me ponder so A++ to Jean for the presentation, for making me think, and doing it whilst incredibly jet lagged!

Read Full Post »

Dr Evil meets PMOs

A fellow coach, lets call him Dr Evil, was recently describing the fun that he was having on an Agile coaching assignment.

He was tasked to work with a small PMO (thats project… or in this case Program Management Office) among a number of other teams. He put on a cheeky grin like Dr Evil and I saw that he was up to mischief.

Now most coaches when faced with a PMO to work with would begin to educate those involved in the PMO how the PMO evolves to be a supportive function under Agile. Within Agile, a PMO might do a very small portion of governance and might help find resources for certain roles such as a supportive Project Manager, but the concept of a ‘reporting’ function would no longer exist or is simplified to such an extent that only a small number of resources are required.

Dr Evil is not like most coaches. This is a fact that he prides himself on.

Some coaches are supportive, some are direct. Dr Evil likes to think out of the box .

Problem of context: this PMO wanted to have a large degree of say as to how the Project Managers in the Program should be running their work. This behaviour was very anti-Agile, directly reducing the empowerment that the Project Managers should have.

Dr Evil’s solution: Load em up baby!

Dr Evil not only embraced what they were doing, he was actively giving them more… and more… and more. He has been happily tracking their PMO meetings and plotting on a graph the time that the meetings take. This graph is currently on an exponential rise. He hopes that at some point in time (soon) they will break under this ever booming pressure and plead for the Project Managers to make decisions, thus finally giving them the empowerment they should already have.

The current most inane decision sent up to the PMO: desk by desk seating allocation of 80 personnel.

Stay tuned to see how long they take to break, good luck Dr Evil!

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers