Busting The Myths of Agile
Agility is a hot topic, but you have to separate fact from fiction. In this post, we are busting five common myths about enterprise agility and agile philosophy.
Organizations are increasingly looking at a way to not just survive but thrive in this fast-paced, ever-changing environment.
ImportantWith the advent of unprecedented digitization, the world today is spiraling into a volatile, uncertain, complex and ambiguous environment.
In this hour of need, several organizations are turning towards Agile.
WarningWhile Agile is the buzzword in the market today, it is a concept that is often misunderstood. Is Agile a methodology? Does it work in a non-software context? And so on.
When fundamental questions about Agile are not answered adequately, several myths have cropped up around it.
These myths can either prevent organizations from adopting an Agile way of working or make them choose it for the wrong reasons. Both scenarios are undesirable because they result in organizations not leveraging the full power of the agile way of working.
Organizations adopt an agile approach for many (sometimes bad) reasons.
Some hope for greater productivity and a reduced time-to-market. Others for more successful products. Still others adopt agile to increase collaboration between developers and business people, to improve quality.
But, for as many benefits as there can be to agile, there seem to just as many fallacies.
Agility Is a Methodology
This is possibly the most common misconception about Agile. Organizations and people tend to be confused that agile is a methodology that needs to be adopted and executed.
Agile is a MINDSET — a way of thinking or philosophy.
Some people think of agile as just doing iterations, retrospect meeting, daily standups, etc. Mindset is one of the most important elements and something that is actually missing in the agile manifesto.
The Agile Manifesto is all about 4 values and 12 principles. It does not mention anything about methodology.
ImportantAgile is more about a set of principles to guide you in the decisions you take. Agile is principle-driven (mindset) and not rules-driven (methodology).
In other words, successful agile transformation starts with changing how we think — specifically, in my opinion, how we think about priorities and failure.
Priorities become linear and organized instead of reacting based on what is broken. Failure is no longer looked upon as something to be feared; instead, we embrace failure as a learning experience.
Being agile is a way of thinking primarily focused on the customer. Therefore, to deliver what the customer demands, in real-time, teams must focus on collaboration, continuous improvement and commitment to quality, focus on people and delivering value, empowerment and self-organization.
Agile is not just changing what you do, it’s changing how you think.
WarningSuccessful agile transformation requires an organization to be prepared to undergo a meaningful shift in both methodology and mindset. Once you make this shift in perspective and fully embrace it, you derive a higher chance of reaping the rewards of agile.
If you want to be agile you have to strive to be antifragile.
ImportantIn other words, antifragility is the ability to derive benefit from change. Antifragility means building systems and developing skills that allow you to benefit from rare, unpredictable events.
Agility Is Chaotic
One of the most common myth about agile is that it would be chaotic — it would sacrifice reliability and predictability for a more dynamic organization.
In reality, Agile combines stability and dynamism.
Nevertheless, scaling the dynamic practices of agility can be done only when supported by a stable backbone that prevents mayhem in a constantly changing organization.
Agility doesn’t come from being loose and unstructured.
WarningFearing the rigidity of being over structured, many managers flip-flop to being under structured. They mistakenly believe this to be agility. It isn’t and rapidly decays into a chaotic, seat-of- the-pants mode. That’s fragility not agility!
Agile means no planning is another myth and misconception.
ImportantThe fact is that planning is often less visible because agile teams pursue planning as a series of smaller, recurring activities to ensure that their plans reflect the realities of the present.
Agile isn’t anti-planning; it’s anti-static planning.
Agile teams develop plans the same way they develop products — by revising and adapting. The goal is to invest time in planning at the best possible moment and adjust to changes easily if they occur during the execution phase.
Agile doesn’t let employees get to do whatever they like. Actually, it’s the vice versa — Agile needs well-disciplined teams. Each team member should be ready to help its peers whenever they need help, should collaborate with them, and be open to acquiring new knowledge so that the team could deliver a faster and higher quality of work. This is definitely something which cannot be achieved through anarchy, but by having well-disciplined teams.
It’s time to bust another persistent myth: the myth that agile teams don’t architect or design their products.
ImportantAgile teams definitely design their products. But, in the same way they plan incrementally, agile teams architect and design incrementally. This allows them to inspect and adapt their architectures and designs so they become the best possible.
This means there is no upfront phase during which all architectural decisions are made.
In this way, the emergent architecture of an agile product is also intentional. The architecture doesn’t just show up one day. It emerges gradually and guided by the intent of the technical team members.
Agility Is "KISS"
Agile is not “Keep It Simple Stupid“. Organizational agility is complicated and over simplifying it is a big mistake.
Stupid simplicity ignores complexity whereas elegant simplicity is simplicity which embeds that complexity.
ImportantWhile Agile works best when implemented in small teams, this doesn’t mean that it won’t work for larger organizations. It means that you will have to start small and then scale the implementation of Agile within your organization.
When larger organizations are embracing Agile, continuous integration of the process on a daily basis is a critical success factor.
If you are working on large projects, Agile is more likely to help your organization achieve better results. Agile must be implemented on small batches so that you can quickly receive feedback, reflect on it, make the proper changes, and start the next implementation batch.
Simplicity is about right value. You focus on what people need delivered — and as little else extraneous as possible. Remember, Agile is a way to deliver value. Simplicity reduces waste. Because you’re not doing extra work due to a focus on simplicity, the work you actually do meets a need — a need you clarified by a focus on simplicity and not complicating things.
For Agile, simplicity means understanding a requirement and building the simplest solution that might meet that requirement.
WarningIf necessary, incrementally building upon it until the customer is satisfied. Too many teams want a detailed description of the requirement and spend way too long building it, only to find that it misses the mark.
There is nothing so wasteful as doing with great efficiency, that which should not be done at all.
ImportantFocusing on the why gives the team an objective — a need — rather than a specification. It allows the team to negotiate how that problem is solved, for there are often different ways of achieving an outcome. It also allows the team to focus on simplicity and — here’s the critical bit — doing the least amount of work possible in order to achieve the outcome.
Agility Is For Geeks
Agility has not been specifically designed for IT or product development. Agile transformation can start with an enterprise-wide perspective.
Agile has come a long way since its inception back in 2001.
ImportantThough it was initially meant to aid software development, it has evolved with time and a lot of non-tech teams and industries have begun adopting agile significantly.
Agile works for any team — software or business.
It is important though to implement Agile thinking and build Agile mindset at an enterprise level, for the goal to be met. Beyond product development, agile principles are now being applied successfully in a wide range of industries like marketing, legal, human resources, manufacturing, and healthcare.
Imagine having an Agile product development approach, but a waterfall approach from the Sales and Marketing teams. This will inevitably lead to a dysfunction in the organization.
Increasingly, forward-thinking companies are taking advantage of the same agile techniques that have transformed software development.
Now they are successfully deploying these techniques in other core business units, from marketing to human resources to finance. When companies implement agile across their entire organizations, ways of working improve dramatically.
Agile methods are more collaborative and creative and can be more efficient than other business models.
WarningSiloed employees should no longer perform discrete, predefined tasks in isolation. Instead, cross-disciplinary, collocated teams should collaborate in innovative ways to enhance the customer experience.
Agility Is Faster
It’s not uncommon for the Agile fanatic to tell you that your organization problems come from the fact that you are not using Agile as a way to manage projects.
Agility is mostly about productivity but should not be restricted to it.
ImportantSpeed and adaptability are actually the primary benefits of Agile. While faster speed and flexibility usually boost output, agility’s true value is creating a position of strength, not fixing broken productivity.
Agile is not the silver bullet to success, as there isn’t such.
WarningYou can fail with Agile as you can fail by using any other traditional project management approach. At least, by using Agile, you will fail faster because of the visibility and transparency it brings.
The myth that we don’t have time to do traditional project management, so we will use Agile project management, because it is faster is a trap.
This is NOT Agility. Agile is time-boxed in iterations. If a project has a clear, unchanging set of requirements it may actually take longer to complete it using an Agile approach, as opposed to a traditional approach.
Agile can actually be a bit slow and that’s ok. Agile prioritizes quality. It emphasises continual refactoring and paying down technical debt. Thus Agile can actually be quite slow in delivering features. Which puts pay to the lie that it means “fast and cheap”. Those words imply something shoddy rushed out the door, riddled with bugs.
Agile does NOT solve every project problem you have.
WarningOn the contrary, implementing Agile generally shows all the ways your project (or your organization) is not agile. Communication is a bigger problem with Agile and poor communication has a larger impact when using Agile project management.
Agile does NOT trade speed for quality.
All those people who claim that in Agile, quality suffers, ignore the fact that testing and quality check, actually happens within the team. The quality check is implemented in each team’s workflow.
Mythbusting is always beneficial, but it’s especially valuable when it applies to enterprise agility — a complex and often disruptive transformation that requires thoughtful consideration, not complications triggered by misconceptions.
Being in the driving seat of your agility as an organization is quite a challenge so you must make sure that you don’t fall prey to these myths.
ImportantAn organization’s ability to transform itself comes down to its ability to respond rapidly and proactively to the ever-increasing competitive cycles that characterise modern markets.
With all these Agile myths debunked, we hope that you may reconsider your perhaps, distrustful attitude towards Agile.
Or, if you are already doing Agile, but we just showed you some of the cracks in your organization — you will take action and embrace the change.
Agility is transformation. It is the only truly sustainable competitive advantage.
WarningIt is difficult, and it can’t be avoided or bought. Yet the best leaders actively design their organizations to do it constantly.
I’ve busted five myths surrounding agile product development. What other myths have you encountered in your organization? Let me know of your favorite Agile myths in the comments section below, I would love to add them to this list.