5 Excuses Why You Can’t Use Agile…and Why They’re Just Excuses

During my 10+ years of doing agile and Scrum training and consulting, I’ve heard lots of excuses from people about why they can’t use the agile approach in their organization. Here they are…in no particular order:

1. Our projects are too large and complex.

Actually, this is a good reason to use an agile approach! When projects are too large and complex, they run several risks, especially the risk of waiting too long to deliver something useful, only to find out that the customer’s needs have changed. The agile approach breaks up a large and complex project into a series of short iterations and deliveries, which allow the team to avoid this risk by getting constant feedback to make sure they are on the right track. Certainly, large, complex projects are difficult no matter what approach you use, but now there are very sophisticated frameworks (such as the Scaled Agile Framework™) for managing large projects using an agile approach.

2. Our stakeholders: they don’t know what they want / they don’t agree on what they want / they like to micro manage projects/ <insert your stakeholder issue here>

The agile approach is actually designed to deal with difficult stakeholder issues. By providing the stakeholders with an opportunity to review and provide feedback on working software at regular, short intervals, you can uncover issues like uncertainty and disagreement earlier and, in Scrum, make use of the Product Owner role to address them. And, because approaches such as Scrum rely on constant ordering of the Product Backlog, teams are always focused on developing the most valuable functionality. (See my earlier blog on Putting Your Product Backlog in Order for some prioritization techniques that might be helpful.) Getting stakeholder agreement on what is most valuable is a tricky business, but since you do it constantly, they tend to get better at it!

3. Our organization is heavily regulated and needs lots of documentation.

By doing things iteratively, and having more frequent releases, you can meet changing regulatory needs in a shorter time frame and shorten compliance cycles. As far as documentation goes, the agile approach tries to eliminate unnecessary documentation that does not add value. If you have to produce a document for compliance reasons, the guidance I give is to make it as “bare bones” as possible, so it meets the compliance requirements but you don’t spend any more time than absolutely necessary writing it. Half the time, nobody reads those documents anyway, and they don’t really add value to the software you are producing.

4. Our governance process is based on the waterfall process.

It’s often the case that an organization has built its governance process based on the phases of the waterfall process – requirements sign-off, design review, test readiness, etc.  Your management might say, “You can do agile, but we need the requirements signed off after the first month of the project.” Governance processes are meant to make sure that projects are on track and meeting their objectives, but having a governance process that is too tightly bound to the operational process of development does not provide much flexibility when you want to try a different development approach. Can you look at each of the “gates” in the governance process and the purpose of each gate and adapt them to an agile approach? For example, the purpose of requirements sign-off is to ensure that the stakeholders agree to the requirements as they are documented. Can creating and ordering the initial Product Backlog serve the same purpose in Scrum?

5. Our team members work on multiple projects at the same time.

Ah yes, the old myth that multitasking makes us more productive! (Even though the evidence does not support it.) I’ve run into this excuse quite often in IT organizations. Short iterations actually make resource planning simpler, especially in environments where people work on multiple projects. It’s much easier to get a good sense of a team member’s availability over the next 1 to 2 weeks and get a commitment during that time frame than it is to figure out team availability over the next month or 6 weeks. (For more information on this topic, see my previous blog post The Benefits of Short Iterations, or Why Time is Like Closet Space.)