• Home
  • Fake agile: How to fix it with Design Sprints

Fake agile: How to fix it with Design Sprints

Your organisation claims to be agile. Designs Sprints can help.

Your organisation is claiming to be agile, but every single person on the team knows that what you’re doing day-to-day is far from it. Design Sprints take a huge leap towards correcting that.

What do you mean fake-agile?

Let’s get this out quickly and be agile

Release it and see what happens, so we can be agile

This is a last minute request, we should build it anyway since we are working agile

There will have been times where you’ll have heard these phrases and they’ll have made you shudder. Tasks come in last minute, ideas come out of nowhere, or features get rushed to release. This is fake-agile.

There’s this illusion that by moving quickly and being able to accommodate last-minute requests means by some stretch that you’re operating in an agile fashion.

In reality, it’s bad planning, the opposite of user-focused and eventually frustrates everyone. But once you are aware of it and know how to become more agile, all of the team, and crucially your users, will benefit.

It’s not uncommon to come across management that have little to no experience and exposure to agile, yet spout about being agile. Surveys by Deloitte and McKinsey found that 90% of senior executives give high priority to becoming agile, but only 10% see their firm as currently highly agile. This disparity has led to huge amounts of managers claiming they’re agile, ultimately damaging the teams they manage, and the experiences of the customers they serve.

One of the challenges of agile is to integrate into huge monolithic organisations, with many moving parts, and split tasks into such a way that small autonomous teams can work on them. All whilst remaining obsessively customer-focused. A quiveringly worrying framework was produced by Deloitte. Take a moment to spot the customer on this map.


Map of an agile framework by Deloitte

Spot the customer


It’s an impressive lesson in how to take a methodology which in essence can be simple to explain but hard to implement and make it monstrously complex. Anyone with a genuine agile understanding should spot this a mile away, but do they always? It’s one of the many reasons fake-agile happens.

What are the symptoms of fake-agile?

  1. Last-minute requests, because someone forgot to do something, not because you’ve learned something new from your customers

  2. Wanting to release new features or improvements without having a user-driven reason why-often because it benefits the business or the stakeholders in some way

  3. Trying to A/B test yourself out of a hole because you’ve no idea what your customers want

  4. Looking busy by tweaking features, just to keep the team occupied - movement is not progress

  5. Not having time to do the research or design because you have to release something - remember that no user ever said “I love this feature because it was released on time”

If that’s fake-agile, what’s “real” agile?

The single best way to summarise agile is to say that a small team is set up in the best way to react to new information. And is obsessed with delivering value for a customer over anything else.

It’s impossible to talk about agile without mentioning the Manifesto for Agile Software Development. Seen as the Magna Carta of the agile movement. The manifesto sets out 4 values and 12 principles for agile software development. It’s a fantastic starting point for those wanting to adopt agile methodologies, but can be difficult to interpret without having experienced the values first-hand.

With over a decade of experience, Steve Denning summarised agile perfectly by outlining 3 “laws”:

  • The Law of the Customer  — an obsession with delivering value to customers as the be-all and end-all of the organisation
  • The Law of the Small Team — a presumption that all work be carried out by small self-organising teams, working in short cycles and focused on delivering value to customers
  • The Law of the Network — a continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers

If you need examples of truly agile organisations, look no further than the likes of Amazon, Apple, Facebook, Google, Netflix and Microsoft, to name a few. These aren’t the most valuable companies in the world by accident. But they didn’t get there overnight.

Agile is a journey. You become agile through hard-work and top-down trust. You can’t apply the label to what you’re currently doing and expect fantastic results to materialise. It’s easy to look at fake-agile and think that this is early-stage agile, but the two are worlds apart. Early-stage agile is part of the agile journey; you’re just starting to become agile and are learning. Fake-agile is the antithesis to agile. The agile journey never ends either, organisations just find new ways to become more agile.

Design Sprints can fix it how?

So, where do Design Sprints fit in and how do they help? Design sprints solve big problems and test new ideas in just 4 days. They’re a fantastic way of showing how it’s possible in a short amount of time to learn from your users, produce something tangible and set yourself up for success. You can’t lose. You either learn or you push forward and launch. Bringing a process with this much energy, success, and structure to a fake-agile organisation can be eye-opening for them. When done well, Design Sprints can make it feel like they can’t be any other way to push forward creating or improving on features.

There have been some fantastic articles on how to integrate design sprints into your current development sprints, so I won’t cover these here. First, focus on your design sprints and build your team’s empathy towards your users. Then, and only then, do you need to worry about integrating the sprints into your workflow.

Casting back to some of the original symptoms of fake-agile, it’s easy to see how sprinting in this way helps move a team towards real-agile. 

It’s no longer important to get things out quickly, but rather learn what to get out and be set up in a way to do that quickly. Thus reducing time to release and releasing customer value early. It’s a very different conversation. You’re testing the ideas with real users, and ideally, the problems you are generating are from your users. Putting users at the heart of everything you do. 

Last-minute requests aren’t without justification. You run a Design Sprint, you learn, you push those new learnings into the team, and they react, build, and launch in confidence.

Design Sprint X specialise in Design Sprint facilitation and training. We’ve worked with monolithic corporations and start-ups alike. Fake-agile is rife. All is not bleak though, early-stage agile and agile is also common but not as much as you may think. And definitely not to the extent you may think. We’ve seen many companies adopt design sprints and turn their agile culture around. It brings a new appreciation and understanding for putting the customer first. It’s rewarding for all the team, and more importantly the customer.

What we have seen from running these designs sprints is how they bring an overall new perspective and appreciation of design and agile. All of those that attend usually leave with a new energy, a new way of looking at problems, and an overall positive attitude towards design. Your team will surely be set up to think in a more agile way.

Give Design Sprints a try and see how it helps move your company from fake-agile to the all-important early-agile stage. You’ll not look back, and neither will your team.


Appendix

Newsletter

Design sprint inspiration and stories.

No spam, ever. Unsubscribe any time.