Oh, the Horror! – How Agile Can Go Wrong

We’ve all heard mentions of Agile and likely a few horror stories that tag along. Every so often one instance where it was adopted successfully by a company might crop up – but, oh, the horror stories… There are just so many! In this blog we’ll look at why people are doing agile wrong:

Doing Agile Rather Than Being Agile

The first misconception about agile is, “By implementing the use of a Kanban or by using scrum methodologies, an organization is being agile.” Yes, there are tools that might be used in most agile organizations, however Agile is not a methodology but a philosophy based on a set of principles as specified in the Agile Manifesto.

Granted, agile started as a software development philosophy, so the manifesto reflects this. However, if the philosophy is one that you believe will benefit your organization; it’s very much worth considering its adoption.

 

Focusing on Speed

When an organization has historically used the waterfall approach of project management, they usually look to agile when deliveries are delayed, and they have a huge backlog. Yes, the initial need is speedy delivery which is certainly helpful when you have a backlog of orders or a major project is considerably delayed. However, if the only focus of your adoption of agile is delivery, the cure might be worse than the illness. “Why!?” Because of…

 

Favoring Quantity Over Quality

This goes hand in hand with the previous point. Not addressing problems as they arise because they might be minimum is only setting yourself up for failure. Yes, your deliverable might be completely functional and have passed applicable tests when you deliver it to your customer (whether it’s an internal or external customer) and you might address it in the next iteration of the process after all, based on your standard procedures this might be perfectly within compliance. However, what happens if the user of your deliverable has encountered a similar situation? As you can imagine, the minor issues can compound and easily snowball into a catastrophe. The way to go here is to have a discussion with the applicable parties so the issue can be identified, the risk can be assessed, and a joint decision can be made. Bonus points: you get to enter a preventive action into your log. The quality manager will be proud! This can be seen as an instance of what the manifesto refers to as valuing individuals and interactions over processes and tools.

 

Waiting to Get Feedback

Ever roll your eyes at any mention of the phrase “acceptance test?” Whether it’s a User Acceptance Test in software development, or a Factory Acceptance Test in a manufacturing application; this rolling of the eyes has historically happened when a provider just knows that the customer is going to ask for changes to the product before releasing it for deployment/delivery because “that’s what customers do in acceptance testing.” Yes, the due diligence of selling the appropriate solution to a customer based on their problems might have been done before you came into the picture of developing said solution. However, as you are developing or building the solution, open communication with the customer and asking for their feedback can save you many headaches when it’s time to deliver and close the project. No need to have the “well, this is what we offered and what you signed off on” which usually triggers the initial rolling of the eyes. This refers to the ideas of valuing “customer collaboration over following a plan” and “responding to change over following a plan” stated in the manifesto.

 

Dismissing Waterfall Altogether

So, you decided that agile will benefit your team. You adopted it, reaped great benefits from it, and now your management is excited about it and wants to unleash the company wide “Agilization 2020 Initiative” that should yield similar results based on your experience and your best practices. Time goes on and the results aren’t quite there, so now everyone hates agile. Talk around the water cooler becomes “it’s a fad that can’t be sustained” unlike the “way we used to do things back in the day” and people give you the stink eye when you walk by them in the hallway. The truth is that agile is not universal and even if it were, there are no best practices that will apply to two different teams.

Remember that agile is about valuing the people over processes. Each team or group should experiment and come up with practices that work for them specifically and they should be learning more about their team as they analyze each iteration in retrospective (just don’t let management talk you into “Agilization 2021 Initiative II: Hindsight is 2020”). In the end it might turn out that waterfall is the way to go for specific projects or operations and there is nothing wrong with that – even if the general approach of your organization is agile.

For more information on how we can help you and your project management team, send us an email

If you are looking to kick start your project management journey, sign up for our Microsoft Training Classes. We hope you find this blog post helpful.  For more tips and tricks on Project Management, follow us on LinkedIn and Instagram