Agile has become so popular that companies are looking to implement its principles in innovative ways, and for good reason. The concept of the Agile methodology is appealing: it provides for more predictability on a project, engages stakeholders, and focuses on business value.
But one size truly does not fit all. Everyone needs to “rightsize” their implementation of Agile to match their organization, maturity dealing with Agile, and the programs/projects they are executing.
Without a true understanding of how each “flavor” of Agile works, what often happens is that Agile is incorrectly applied, doesn’t work, and then companies don’t understand what went wrong.
Benefits of Agile
One reason the Agile methodology works so well is that it values individuals and interactions over processes and tools. It considers the human factor of a project, which, if we’re being honest, is where failures usually originate. Remember, when projects fail, it is typically not due to a single major event, but more likely to be death by a thousand papercuts, where small human errors compound until the point of no return.
Agile focuses on working product over comprehensive up-front documentation and a mantra of relentless ‘inspect and adapt’ mindset coupled with the courage to rapidly pivot and course correct. The iterative nature of Agile ensures that the team is constantly tweaking as more requirements or issues are found.
There is customer collaboration over contract negotiation. It’s important that both the business side and the IT side of the equation are getting their needs met.
And finally, Agile is…agile. It’s about responding to change over following a plan. Of being flexible when needed.
Beware the Agile Zealot, or: Overapplying Agile Principles
Agile zealots are those who learn the tenets of one particular flavor of Agile and then want to apply them, without modification, to everything.
Just because you have a hammer doesn’t make everything a nail.
I was on a project with a client who had an offshore development team that it decided to turn into a Scrum team. What they didn’t see is that by doing so, they violated the very premise of Scrum, which is to have everyone in the same room. That doesn’t work with a remote workforce.
If you’re sitting in the same room with the developer, business product owner, and others on the project, you can resolve questions faster and more easily. The velocity of work goes up. Instead, in that remote setting, communication became more difficult because the purist Agile formalism designed for co-location was not adapted to these specific ways of working involving geographically and time-zone dispersed teams. The project struggled.
Trying to follow a purely Scrum framework in this situation didn’t make sense. While, yes, Scrum can provide value, in the wrong application, it can create more problems than solve them.
In this situation, we found better ways to incorporate traditional methodologies, such as using Waterfall artifacts, with an Agile twist.
Agile is a methodology built around flexibility. It’s an assortment of tools that can and should be used and modified to fit a project. Trying to over-structure your Agile implementation can keep you from reaping the benefits of small self-run teams.
On the other hand, implementing it too loosely can end up in “Agile chaos” with teams working independently without any coordination. There’s a balance. Find it.
Agile: It’s Not Just for Software Development Projects Anymore
While the original intent for Agile, particularly Scrum, was for software startups, its applications can now be stretched beyond software to most projects. Organizations are now implementing Agile at scale across departments and functions. They’re using it in a variety of new contexts, ranging across ERP implementations, product development, training material development, and process optimization, to name a few.
But realize: not everything in an organization needs to be Agile. It’s important to consider the nature of a given business transformation initiative to determine whether the characteristics of Agile are relevant and useful, and if so, in what functions and what work domains.
Find Your Flavor of Agile
Just like Goldilocks had to try several chairs and porridge to find the one that was just right, it may take some work to find the right flavor of Agile (what we like to call Practical Agile) for your program, project, industry, company, culture, and workforce. That might involve a combination of Scrum, Kanban, or even AgileFall.
Remember: Agile isn’t about perfection; it’s about constantly adapting to get it right. Rather than aiming for a complete product, aim for a Minimum Viable Product (MVP). Be open and adaptive to change your approach if you see the Agile tools you’re using aren’t working.
Look at your organization and projects and select a methodology toolset that best fits your operating environment. Then review the different components and omit or enhance that basic structure to best suit your needs. That may mean creating a patchwork quilt of components and strategies, and that mix might be different from project to project. The key is: honoring the project with the most effective balance of tools that best enable the people doing the work to attain success.
Share: