Fake agile: how to fix it with design sprints

Article
Written By Luke Taylor

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

Your organisation claims to be agile, but everyone on the team knows that what you’re doing day-to-day is far from being nimble. Design Sprints take a massive leap towards correcting that.

What do you mean by 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

You’ve heard these phrases before, which will have made you shudder. Tasks come in at the last minute, ideas come out of nowhere, or features get rushed to release. This is fake agile.

There's the illusion that moving quickly and accommodating last-minute requests means, by some stretch, that you're operating in an agile fashion.

It's bad planning, the opposite of being user-focused, eventually frustrating everyone. However, once you are aware of it and know how to become more agile, the team and your users will benefit.

It’s time to come across management with little experience and exposure to agile yet spout about being nimble. Surveys by Deloitte and McKinsey found that 90% of senior executives prioritise becoming agile, but only 10% see their firm as highly agile. This disparity has led to many managers claiming they’re agile, ultimately damaging the teams they manage and the customers' experiences they serve.

One of the challenges of agile is integrating into huge monolithic organisations with many moving parts and splitting tasks so that small autonomous teams can work on them. All while remaining obsessively customer-focused. Deloitte produced a quiveringly worrying framework. Take a moment to spot the customer on this map.

Spot the customer

It’s an impressive lesson in how to make a methodology that can be simple to explain but hard to implement 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 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 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

Luke Taylor
Previous

Crazy 8s Timer Online
Next

The Symphony of Productivity: Unveiling the Power of Music in Design Sprint Workshops