Not always. We have a tendency to solve problems we face with a single silver bullet. In the recent past, I observed an organisation trumpet it’s move to agile in multiple communications. This organisation had undoubted issues with delivering to commitments it had signed up for, and agile was seen as the way to fix all its ills. Yet, when I talk to those working in the organisation, they see little change. And surprisingly, the outcomes are no different now than before.
So is agile to blame for this? Or was waterfall methods (if indeed it was what they used) really to blame for their past failures. The reality is agile is not something that simply works. A cultural shift is required within the organisation to derive benefits from using any agile methodology. Without that, (so called) agile is just as bad as any other way of running projects. So what are the things that defeat agile in organisations?
Multi-disciplinary teams: Agile project teams must include subject matter experts from areas that they are delivering too. If a software is being written for automating taxes for accountants, then you must have accountants and tax specialists in your project team, along with your developers, testers etc. Technical staff cannot be experts, and this is why you will need subject matter experts. If experts get tasked with duties on top of their day job rather than dedicated time on the project, agile is bad for this organisation.
Decision autonomy: You get over the first hurdle and have the skills in the team that you need. Time comes to make the first choice between implementation options and your subject matter expert needs to get it approved by their manager, who is not available for rest of the week. If your subject matter expert cannot make decisions on the project with authority, agile is bad for for this organisation.
Urgency: A key tenet of agile is the delivery of working product at the end of each iteration. Iterations are intentionally kept short so prioritisation always focuses on highest value items, builds value incrementally, and avoids the bells and whistle distractions. If the organisation cannot get you decisions in a timely fashion, then you can be guaranteed to either twiddle your thumbs for parts of iterations, or pull too many moving parts into it. Either way, agile is bad for this organisation.
Change control: It is all well and good for the project team to work in an agile environment. What happens to the working product delivered by the team? Is the organisation geered towards receiving these products at such intervals? Can they cope technically? Is there enough staff to make it happen? Can the required training be produced in time? If the answer to these questions is no, then agile is bad for this organisation.
Procurement and audit: Agile planning is done in stages. Closer you are to working on an item, more detailed planning you undertake. In the course of the project, it may become clearer that delivering more in one area is of higher value than delivering on another that had initially been identified as a requirement. If the subject matter experts make this call and the organisation’s procurement or audit team later lambasts them for non compliance, agile is bad for this organisation.
The intent here is not to highlight deficiencies of agile methods. In fact to the contrary. Agile done well can be immensely valuable for organisations and an innovative and satisfying environment to work in. The key is to recognise agile requires a cultural shift in the way an organisation operates to make it truly worthwhile. You do not make agile project teams, you make agile organisations.