Abandoning Agile? Hold on a sec…
About a 4-minute read
Cover Image: Shutterstock - Jonas Listl
“Agile” is not inherently a bad word. Mention “Agile” in a business environment, however, and those five letters can be incredibly divisive. One side sees Agile evangelists and advocates championing Agile ideals and picturesque outcomes. Across the divide, there is a side believing if something is not broken it should not be fixed, or they see intrinsic flaws with Agile, or perhaps they are haunted by past failures. There is validity on both sides, with emotions and experiences determining if someone lands on one side or the other. Even when Agile falls under negative sentiments, there are undeniable benefits that can exist outside a pure Agile environment.
Where is the Agile negativity justified? Working in an Agile space for the past decade, I have noticed Agile is quite the buzzword and something organizations race to implement. Thousands of dollars, mountains of resources, and hours of personnel time are invested in a process intended, and sometimes advertised, to solve the problems plaguing organizations’ workflow and output quality. Agile implementations are accomplished via frameworks that require adherence to prescribed steps and roles, and should any of the ingredients be omitted or adjusted, the Agile structure risks toppling. In these instances, why is Agile so fragile? Blindly implementing an Agile framework like Scrum or SAFe can shoehorn people and legacy processes into something that was never going to fit. The poorly tailored result ends up stressing an organization’s change management capabilities and its people. Without steady leadership guiding the change, as well as constant reinforcement of foundational values for why Agile is being pursued, the organization can quickly lose sight of purpose and motivation. The resulting effect is a natural reversion to the familiar, and eventually, as with things that do not work as they are supposed to or as intended, a smart organization pivots; Agile is abandoned.
Moving on from Agile is okay. A greater concern, however, is what exactly did not work. The questions to ask the decision makers are what Agile means to them, and then within that context, what did not work, as opposed to casting a blanket denunciation of Agile. My goal in asking these questions is uncovering whether the Agile mindset failed or whatever framework was intended to exemplify Agile. Why does this differentiation matter? It all comes back to the intention that Agile is not a framework or a process; it is purely a mindset, and it does not need to be anything more.
Focusing on Agile as a mindset does not make it any easier to implement, but it can be more sustainable. Organizations still require strong leadership buy-in, consistent reinforcement of purpose and destination, and capable change management practices. There will be a constant pull toward what is familiar and comfortable, and an Agile mindset is typically neither of those. The mindset, however, can simply be a different way of thinking rooted in the Agile principles and applying a foundational level of that thinking to common everyday work and challenges.
Agile Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity - the art of maximizing the amount of work not done - is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Source: agilemanifesto.org
Another way of framing what an Agile mindset is and is not, is by looking at what organizations are giving up when moving away from Agile. When an organization says Agile does not work, they are saying continuous improvement is not for them, that accurately identifying and addressing customer needs is not a priority, and minimizing wasted effort is not a concern. Those are all components that can be improved with Agile. Furthermore, introducing an Agile mindset does not need to be fully encompassing. Wherever and however an Agile approach finds its way into an organization, noticeable benefits should follow. Perhaps stakeholders and users see a product-in-progress and provide feedback that alters a potentially disastrous development outcome, or maybe a team meets regularly to review whether their current approach to work, and one another, is still producing the best output.
The moral of the story is Agile implementation through prescriptive frameworks and processes may not be for every organization or person. What I believe works best is focusing on the implementation of the Agile mindset so organizations can ensure work is pointed in the appropriate direction, that said work is rightsized for the organization and available skill sets, and that teams are striving for continuous improvement. For that to be successful, leadership also needs to embrace an Agile mindset and regularly remind themselves and the organization’s people that their identity is not their processes, and even if they continue using legacy approaches, the back-end thinking guiding the work is done with an Agile mindset focus.