Lukasz's Blog

The Verdict on Agile

This week Te Papa in Wellington played host to the annual Agile NZ Conference. The team from Assurity have done a great job of hosting this conference over the past few years and its gone from strength to strength - attracting some headline international Agile experts and speakers.

At the same time I have noticed an increase in the number of articles questioning the value of Agile and whether the methodology actually delivers the benefits it promises. Many people I’ve talked to recently have been asking the same questions. After a few years of adoption many organisations are now getting to a stage where they are taking stock of how things are going.

The interest of executives and senior managers in Agile probably peaked about 5 years ago. Everyone was disillusioned with the lack of delivery and cost blow outs associated with the traditional IT project delivery approach. They thought surely there must be a better way - so they (or their consultants) went looking.

What they found was that teams who have a clear purpose, complimentary competencies and communicate well were using Agile practices. Enter a classic case of ‘correlation versus causation’. The assumption people made was that Agile was the key to improving delivery. And why not - iterative value based on more frequent releases, makes logical sense right?

And so happiness reigned in the land again - executives and managers had found a new approach which they had seen delivered value and a whole industry of Agile coaches & experts emerged to help organisation adopt Agile practices. Silver bullet found.

Unfortunately the reality is that most organisations are bad at change, and so what followed was years of largely only the IT function adopting Agile practices - usually with the support of a handful of forward thinking business product owners or stakeholders - whilst the wider organisation around them didn’t shift. Most organisations ended up with what I call the Water-Agile-Fall methodology.

Upstream activities such as governance, portfolio management, resourcing/funding and prioritisation continued to operate in the usual waterfall manner which meant that product ownership/the product backlog were constrained by the same funding/resourcing/changing priorities issues that sank the SS Waterfall.

The adoption of product ownership as a business discipline has also been patchy - so often you end up with product owners who act as proxies for a range of business stakeholders, and who end up being torn between the competing needs of thoss stakeholders without having the mandate to actually make decisions. I think too many business owners see product ownership as an ‘IT thing’ when really it’s about being the responsible owner of the product or service on behalf of the whole organisation.

One of the other major oversights of the ‘Agile scouts’ was that the companies they studied were predominately technology-centric (usually software development) companies or ones that delivered digital products or services. They weren’t based on a classic asset-centric, project cycle based business model - they were based on the construct of product teams and lifecycles. That shift - from project to product - was a crucial part of the Agile recipe which most organisations left out.

Some business models or activity types simply don’t lend themselves to iteration and incremental development - there’s too much rework and wastage introduced. There’s nothing wrong with that - your organisation should be able to pick the right tool (approach/framework) for the job at hand.

So is all lost - do we need the next generation of scouts to go out to the valleys and find us another methodology or framework? My sense is that rather than repeating the cycle organisations should perhaps genuinely commit to change (including difficult conversations around leadership, structures and roles) and utilise frameworks such as Agile to re-engineer their operating models to be fit for purpose.

For me there are a few key things to get you started down that path:

• The adoption of any framework like Agile needs to be business focused - led by the CEO and executive - with the intention of changing the way everybody works and the way the organisation delivers products & services to its customers. In fact I would start by re-engineering the customer engagement side first and then work backwards.
• Frameworks and methodologies are no replacement for culture and people. The idea that changing frameworks will improve delivery is so appealing. The reality is that there are no silver bullets; you can’t simply ‘import’ something into your organisation - you have to do the hard yards, figure out what works in your context and then work tirelessly to make it happen.
  
• Your primary focus should be on people, not frameworks. Hire and train the best possible people you can find, create a clear purpose for them and then empower them to do awesome things. Creating a culture where people want to stay will ensure that even as you upskills them (and they get offers from other places) they will want to stay. Culture is king.
  
• Now is the time for some difficult conversations - using yesterday’s thinking, governance or processes to manage today’s delivery simply isn’t going to work. It’s time for change; for some people that might mean upskilling or career change.
• Rebuild using the product mindset - nothing stands still anymore and as soon as your product or service hits the market there will be a backlog of enhancement and fix requests. Writing a business case to run a project every few years won’t allow you to keep up with those customer demands. Products require a life-cycle approach and constant stream of investment.

The principles, spirit and practices behind Agile are still solid. It’s the application of those that has let most organisations down over the last few years. The adoption of Agile has been too focused on the framework & tools rather than on the people & practices.

I think the experience of Agile adoption has taught us some valuable lessons. The good news is that all is not lost and with the right leadership and focus organisations can still achieve what they set out to achieve.

Visual Management Tools

Our adoption of Agile practice now spans about 3 years. Over those 3 years we have learned a lot about what works (and what doesn’t) and have seen elements such as visual management (e.g. Kanban) tools crop up around our organisation.

Whilst I would have to concede that the rate of Agile adoption has been fastest within the information services group (which is so often the case) I would say that we’ve seen increasingly agile-esque behaviour from the majority of our business units & stakeholders. For example, the concept of a Mimimum Viable Product is reasonably well understood and supported.

Over the past few weeks we have been thinking about what else we could be doing to improve the way we work and continue to drive business buy-in into Agile. We already use a range of operational dashboards using the Splunk tool so moving this into the product/project space felt like a natural extension.

Wall space for visual management has started to become premium real estate, and our reporting needs have grown as our practices have matured, so we thought moving to digital visual management tools as a next step made sense.

Using the tools we already have we were able to replicate the Kanban and activity boards on a large display in the team stand-up area. Whilst there’s definitely something tactile and rewarding about moving post-it notes around the digital equivalnet allows us to see work in real-time from anywhere as well as offering us a richness of reporting we never had before. We can see up to the minute views on the progress of work requests, what is in the pipeline at any point in time and make the best possible resourcing choices we can.

The current trial is focussed on one team but it it proves successful we will be rolling out digital visual management tools to most of our other teams over the coming few weeks.

Unsurprisingly the trial has also caught the eye of a number of business stakeholders who are starting to think about the potential visual management tools may have in their respective business units which has to be a plus if it helps us to further drive Agile adoption.

Project Management Maturity Levels

The last decade has seen a huge growth in project management, to the point where some organisations I have worked with seem to be unable to do anything unless a project is kicked off. The demand for project management skills has also created a whole new ’snake oil’ marketplace filled with methodologies, practitioners and consultants.

To their credit the major project management bodies (OCG, PMI etc.) have done a good job of getting standards and certifications in place however there are still a LOT of rogue practitioners out there.

A lot of organisations I’ve worked with have also not done themselves too many favours by being very loose around their definition of project management and what purpose it actually serves - many figured they just needed project management because everyone around them was doing it. Many went in expecting to deliver projects sooner, with less risk and cheaper than before and are often left wanting when process went wild and few benefits were realised.

I’ve often used a maturity model (see graphic below) to position the project management function within the organisation based on what outcomes the business is after. For example, Maturity Level 1 focuses on managing cost and risk associated with bespoke projects whilst Level 3 concentrates on developing and delivering cross-functional portfolios of projects.

Many organisations experience a disconnect with what they want to achieve and how they position their project management capability. Many are after a portfolio approach to projects but position their project management capability at Level 1. Expecting enterprise-wide efficiencies & reporting when operating at Level 1 is another classic misalignment example. Heavily utilising contract resources in an environment where portfolio-wide continuity and alignment is a primary issue is the other issue I see all too often.

I think its quite timely for organisations to look at the project management investments and 1.) make sure they are positioned & aligned with the wider organisational objectives, 2.) have the right-sized process frameworks & tools in place and 3.) most importantly have the right people on board to help them realise the outcomes they are after.

I would also consider some of the more flexible approaches to solution development such as the Agile/Scrum methodologies as part of a balanced delivery platform.