Agile Forest

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.