When Agile trips you up

When Agile trips you up

We live in a world where people love to put flashy labels on things. If it’s popular online, it’s viral. Fast-growing startup? It must be a unicorn. But labels don’t change the very nature of something. You can’t label a chicken a cow and get milk from it. Similarly, just because you call yourself agile, that doesn’t mean you are.

Agility has become a desirable tag for businesses and processes, but it is in fact largely misunderstood. Let’s investigate it a little further.

 

What Agile Is… and What It’s Not

 It’s easy to get bogged down by complicated definitions of agile, and even easier to agonize about how you approach and apply agile project management in your business and your processes. The irony is that in doing so, you might very well be driving yourself further and further away from true agility.

Long before agile was a style of project management, it was a word that described movements that were quick and nimble. Being able to move quickly and change course on a dime. As much as we’ve tried to bottle that lightning and force it into a system, agile is still exactly that. There are teams out there who are agile without even knowing that they are, and those that make a lot of noise about their agility and are not.

This is because true agility is something that is inherent in your business model and processes. It’s a mindset. It’s about snap decisions and grabbing opportunities.

 

The Problem with Commoditising Agile

 In the process of refining the philosophy and best practices of being an agile organization, the whole concept has become somewhat of a commodity.

Software companies develop new platforms that promise to transform your bulky, sluggish organization into a lithe creature of constant, effortless change. You keep piling on Kanbans and sprints, hoping that the right flow chart is going to make all the difference.

But, while all of those things can be fantastic tools in the hands of an agile team, they don’t make the team agile just by being in the same space.

 

Fix the Foundations

 By the time most organizations even start to think about “going agile” they’ve already built processes that are time-consuming, hierarchies that stifle speed, and mindsets that like to stay in the same old groove, day after day.

When you try to put a veneer of agility over that, it doesn’t take long to identify some pretty big splinters. Time-consuming approval processes slow down the works, lack of autonomy paralyses whole departments and tried and true systems override anything new.

The simple fact is that to truly become agile, you need to throw away the old and safe, embrace innovation, MVPs, and pivots, and really recognise that sometimes speed is more important than perfection. Because if you try something fast, and it doesn’t work, you’ll always have time to try something else.

Unfortunately, if you’re already stuck in a groove, it can be very hard to break free piece by piece. So, you might have to change everything to change the things that really don’t work. That kind of total change can be scary and hard to embrace. But if it doesn’t go according to plan, in an agile space, you can always change things as you go.

 

The Sticks in the Mud

 One of the most interesting things about companies that struggle with agility is that very often, it’s the project managers themselves who derail efforts to implement. Project managers, by nature, are very often creatures of habit. They find something that works, and they stick to it. It’s safe and it will get the job done. Not necessarily fast, but adequately. While there’s a lot to be said about performing adequately, if you never try anything outside of your comfort zone, you might never learn about new, exciting and game-changing processes.

 

A Sprint by Any Other Name

 Sprints are a very useful part of the agile process. Unfortunately, sometimes, they’re used as tools to micromanage instead of encouraging the magic that happens when you really put speed and innovation at the top of the list. The only way to know if this is happening in your organisation is to take a long, hard look at how you use sprints. Are you using them solely to assign hard deadlines to your team? Or are you using them to encourage free thought, collaboration, and new ideas?

 

Tight Ships or Tighter Budgets?

 Another common misinterpretation of agile mindset and methodology is that if you cut the budget and make do with less, you’re getting it right. While it is true that agile teams can do a lot more with a lot less, cutting budgets for the sake of it is never the answer. The true key to agility is to recognize where you need to spend to grease the wheels, and where you can cut unnecessary items to lighten up the project balance sheet.

If you see every tightened notch on the organizational belt as a victory on its own, take some time to look closer. Are you seeing corresponding cuts in productivity or quality? Are your cuts necessary, or are they damaging your ability to deliver, or worse, the morale of your team. Cutting your spending doesn’t automatically increase profits, so make sure you’re making smart choices with the right kind of results.

 

Focus On the People

 There’s been a lot to digest here so far. You might be wondering if you’re doing agility right or understanding it at all. Or you might be wondering what you should be measuring first, to figure out where the problems and pitfalls are.

In this case, my advice is to start with the results. Are you getting what you want out of your processes? Are your customers happy, does your team meet their targets, and are you continuously improving and streamlining your methods?

Sometimes, the best way to find what is broken in any system is to start at the end and reverse engineer it until you find the sticking points. 

Need help?

If your organisation is 'stuck' bridging the gaps between agile and traditional ways of working, get in touch for an obligation-free discussion on how I may be able to advise you to a better path forward based on practical current real-world experiences. Email: contact@agilemanagementoffice.com

www.fatimahabbouchi.com

www.agilemanagementoffice.com


Shweta Upadya, PMP

Experienced Program Manager in Information Technology

3y

Thanks for sharing, very insightful.

Rudi De Koker (PMP®)

Interdisciplinary Professional: PhD Candidate | Public Health Specialist | Board Member | Director

3y

Thank you for sharing this insightful article. To some Agile means a free for all, with no rules. The project(s) thus ends up not materialising because of a lack of structure. Agile is not the challenge, but the implementation thereof in a too relaxed fashion is. What I have found when working on Agile projects, is that stakeholder engagement is lacking where the project tend to fail or not produce the desired effect. There might be an input into your end product which requires changes or more effort, and if you do not engage on these points, you will be setting up to fail.

Sebastian Oh, A-CSM, CSPO

Agilist focused on delivering projects with positive customer experience A-CSM® | PMI-ACP® | Agile Coach | CSPO® | SAFe®5

3y

Insightful. Some organization are fast to "adopt" agile thinking it is a faster way to develop/deliver for ROI. Though have not thought it through if agile is the right way for projects with milestones, if teams understand what agile is and if management have truly embraced agile. Thus, end up tripping over one another.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics