Why Fake Agile isn't Fake News

Interviewed recently on the subject of “why does agile fail?”, I found myself rolling out similar answers to those that I have been talking about for over a decade now. Are we getting better, or worse? 

Certainly, it feels like “agile” (and its associated methodologies) is becoming a scapegoat for failed projects and digital transformations - much in the way that people blamed PRINCE2 for similar digital failings a few years before. 

It’s got so bad that there is even a phrase for it “fake agile” - defined brilliantly here on Forbes by leadership coach and agile expert Steve Denning. 

Like “fake news” the term is used by detractors to describe a strain of agile that we don’t like. But, unlike the fake news debate, we have in fact lost sight of the core principles that make agile what it is. 

There is nothing wrong with agile, per se. There is no “fake agile”, just agile done badly. And in the hundreds of projects that I have been involved in, none failed because the agile methodology let them down. Rather, the project was executed badly, misunderstood or (in the case of agile) any host of specific reasons that I’ll outline below.

Agile Transformation Starts with People and Culture

First, that phrase ‘digital transformation’. If we accept that the goal is to make better use of technology to deliver value to customers faster, then a connection to agility is inevitable. 

The other side is using technology to create operational efficiencies. And wherever the focus - business culture and people challenges sit at the heart of any change. 

Companies going through a “digital transformation” almost certainly need an “agile transformation” as well - which is more about people and culture than platforms and code.

Don’t Scale Something that Doesn’t Work

Enterprise-level digital programmes require agility at scale. But you can only scale something if it’s working perfectly. Otherwise, it goes wrong exponentially. 

Digital transformations come with whole company challenges around organisational structure and culture (and many other things) - which is what makes it so hard. 

It’s not a binary case of “top-down” or “bottom-up”. As with most things, it’s a balance of both, with (initially at least) a bit more bottom-up drive with top-down support. 

Try to scale up before you’ve got things working at a small scale and it’s all too easy to fail for any number of reasons. I have always visualised this using a diagram similar to the one below.

To summarise, first you need high performing teams. On this platform, you make the right technology choices. Upon that, you can implement enterprise-wide transformation. And throughout, you support the people through agile coaching.

I’ll now unpack these, one by one.

Step One: High Performing Teams 

This is illustrated in box 3. Scrum (or Kanban or whatever methodology you like) is actually really easy to set up. Set up the meetings, write some user stories and off you go. The barriers to entry are terrifyingly low. But creating a high performing agile team is an art form that is rarely done well. 

Instil Agile Coaching and Collective Culture from the Get-Go

First, you need the right skills (3a). This means having Scrum Masters and Certified Product Owners, of course, but these people also need to operate as Agile Coaches - so, initially, you need real experience in these roles (or separate people in Agile Coaches to support). These people may be technically adept, but if they can’t lead or teach you’ll fall at the first hurdle.

As well as ensuring that the processes and tools are running perfectly (well-written user stories, efficient Scrum meetings, etc) they need to work on creating a strong team culture (3b). This can be a little different for each team but it’s so important to get people engaged and firing on all cylinders. 

My original Agile Coach described himself as our Agile Coach and “Pastor of Fun”. He took responsibility for making sure the team socialised. It didn’t take long for friendships to form and this then continued organically (nobody likes enforced corporate fun!). 

This culture played a huge part in the effectiveness of our team. We worked as a unit, had each other’s backs and strived to find ways to improve our performance because we cared about the product we were building and each other.

We solved a lot of major challenges independently from the wider organisation and challenged hard when we weren’t getting the support from outside. We were a self-motivated, cross-functional agile team. But that culture didn't happen magically, it took a spark to get it going. 

Prioritise Efficacy Above Efficiency

The team must also be focussed on efficacy, and not just on efficiency. By this, I mean iterating towards a goal, rather than focussing on getting to the goal with the fewest possible resources. This may not be the most efficient process but is more effective as the goal may change as you go.

That's hard and needs an article all of its own. 

But it requires a strong User Experience team, good use of data & analytics (see next building block) and support from the business to help define the vision. The team needs to focus on being as lean as possible and iterating towards that vision, not focussing on simply building that vision as efficiently as possible. Because the vision might be wrong and the team needs to prove or disprove it as quickly as possible. 

That’s why we put really strong governance processes in place at the team level. This means looking at risk management, quality and commercial health of the project, burndown towards an MVP, as well as a measure of team health and culture. 

Step Two: Strong Technical and Architectural Vision

While a lot of agile transformation conversations come back to people and culture (and rightly so) there are of course ‘practical technical’ and ‘strategic architectural’ elements to all of this which has to be understood well, which brings me on to Box 2. Broadly I split this into three core components:

1. Data & Analytics (2a)

Having the right data and analytics in place to ensure you understand what you should be building, as well as validating what you have built is adding value.

2. Enabling Continuous Delivery (2b) 

Through Continuous Integration and Deployment. A strong infrastructure team who can help drive and support a DevOps culture is vital to the success of any agile project. You can’t do agile if you have long test and release cycles.

3. Architectural vision (2c)

For large organisations, an understanding of your legacy technical debt and a future vision for your architecture is vital.

This isn’t (and mustn’t!) be a siloed IT programme to migrate to a new architecture and infrastructure in a ‘big bang’ approach. 

It’s about having a vision of your dream future state and then finding smart ways to iterate towards it. Try and make things a little bit better each week and by the end of the year, you’ll have made huge strides. 

Focus on what you need to do in order to deliver value to customers quickly. I use the word value and not features deliberately: data and analytics will tell you if the features add value or not.

Step 3: Organisational Agile Transformation

Don’t even begin to think about scaling any of this, or accelerating change, unless you have nailed the two points above. This brings me onto Box 1.

It’s theoretically possible to roll out a SAFe implementation with value stream mapping at the top and immediately have high performing Scrum teams at the bottom. But I’ve never heard of a success story of that in the real world. 

It has to be iterative. And therefore it makes sense that it has to start small and then grow out incrementally. This is really hard, especially when a business thinks it has a clear vision of its future and wants to get there quickly and cost-effectively.

But it’s important to recognise that it’s not going to work without these foundations in place. 

By starting with high performing teams (that can then spread out and support other teams to support the same processes and cultures) at the bottom then a lot of the challenges will be solved for you.

Again, I broadly split this element into three components:

1. Delivery Process at Scale (1a)

Whether you pick SAFe. Scrum @ Scale, The Spotify model (which actually really isn’t a model but just a naming convention!) or LeSS (Large Scale Scrum) you need a framework to roll out across your teams. 

This becomes more manageable if you have a few high-performing Scrum teams and invest in some good Agile Coaches; the first step towards an effective, scaled engineering team. 

With maturity, you can adapt these frameworks and take elements from each to find a scaled model that works for your organisation. 

2. Understanding your value streams and products (1b)

I hear a lot of talk about “project vs product” at conferences these days, and it’s an important distinction. 

Digitally native businesses understand how digital helps to deliver value to customers and then back to the business. 

For everyone else, the culture is often different. There tends to be a culture where divisions have annual budgets, and divisional leaders create business cases for projects that use technology to improve a business KPI (quite possibly underpinned by an un-researched theory about what they think the customer might want!).

It’s almost impossible to efficiently fund a scaled digital team and to drive the backlogs in the right direction if you are jumping from project budget to project budget. 

If you are able to understand and fund your value streams and then empower the teams to use data and analytics to measure the efficacy of what they are delivering, then you really are doing better than most organisations.

3. People and culture (1c)

OK, so I’ve saved the hardest one to last!

This is where most digital transformations fail. And realistically this needs to be rolled into the two streams above. 

Scaled agile frameworks aren’t just ways of grouping technical people together. It’s about breaking down the barriers between IT, digital, marketing and any other parts of the business that are involved in delivering value to a customer. 

So, therefore, it’s also about reorganising around your value streams. 

Some would say it’s about reorganising around your customers, but this can often be the same thing depending on how you define your value streams. Personally I find the “putting the customer at the heart of the business” line a bit over the top although I do understand the sentiment; for instance in the NHS, where the patient is not the customer.

So Why Does Agile Fail?

Agile fails because any one or more of these core building blocks are not in place or poorly executed. 

At a project level, it’s something in those first two layers that will be wrong. 

If it’s an Agile Transformation as part of a Digital Transformation, then the third layer comes in to play. 

But if you don’t have the foundations at the bottom, then all the clever thinking in the world at the top isn’t going to save you.