In the tech and startup spheres, agile is still seen as an ideal to strive for. However, recent data suggests that, for IT and software development professionals, the agile method as we know it today may be broken–or, at the very least, lost its sense of self.
Jump to the main takeaways:
According to the 2019 State of Agile Report, 97% of those surveyed reported that their organizations practice agile development methods, yet only 22% of companies are getting universal agile adoption buy-in from all their teams.
It gets worse. The same study revealed that only 12% of respondents said their company practiced their version of the agile method with a “high level of competency,” and 6% felt those agile practices were enabling “greater adaptability to market conditions.”
In other words, lots of people say they’re using agile to develop, build, test, publish and market software, but very few feel like it’s making a real difference.
Some, like Ron Jeffries, think companies should abandon the agile method completely:
“It’s time to try something new, and here it is: Developers should abandon ‘Agile’ [...] I really am coming to think that software developers of all stripes should have no adherence to any ‘Agile’ method of any kind. As those methods manifest on the ground, they are far too commonly the enemy of good software development rather than its friend.”
If agile has been left rudderless amid a strong current of digital transformation, an obvious question floats to the surface of this narrative: Is there an issue with the agile method as a whole or simply how companies and development teams are using or implementing it?
The more we searched for a definitive answer, the more apparent it became that the question is incredibly complex. That said, organizations who practice agile software development can still take major steps to optimize their agile processes and overall productivity.
Go Back to Basics to Understand What Agile Development Really Means
One of the big reasons that agile software development has lost at least some of its core identity has to do with the historical evolution of agile as both a general concept and a set of core practices.
As the Agile Alliance’s website makes clear, being truly agile means going beyond Scrum and Feature-Driven Development (FDD) philosophies, as well as practices like stand-ups, sprints, and test-driven development (emphasis mine):
“One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.”
Teams that organize and prioritize projects autonomously, with the ability to pivot or change their approach based on context–sounds simple enough, right?
If only that were so.
For many businesses, that idyllic state of cohesive collaboration that is supposedly synonymous with agile is often replaced by a dystopian, digital-age Wild West setting, where project overload, unclear scope and a lack of a long-term vision reign supreme.
Again from Agile Alliance (emphasis mine):
“[Being Agile] doesn’t mean that there aren't managers. It means that teams have the ability to figure out how they're going to approach things on their own […] Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.”
Similarly to when we discussed how to create the best ITSM strategy for your company, your agile software development practices should emphasize flexibility and collaboration while also allowing management to provide the support that facilitates purposeful execution.
Democratize the Agile Development Process With Guidance, Not Orders
With its collaborative nature and iterative deliverable structure, success agile development is always a democratic process. Everyone must have a say in each stage of a given project, with team members who are empowered to contribute to the decision-making process.
Historically, this is where the biggest clash between agile software development and more traditional waterfall methods of building, testing and delivering software clash the most.
Statistics show that, if a top-down, order-driven waterfall development practice is used, team productivity will almost certainly take a nosedive. As per a 2015 CHAOS report from the Standish Group, agile projects end up failing less than 10% of the time, while waterfall projects crash and burn nearly 30% of the time.
Why is this the case? Consider this elaboration from Perforce’s Rikard Nilsson:
“Agile succeeds, in part, because it [redistributes] power from management to the team-level. While relinquishing control can be daunting to some, what Agile methods do, in effect, is make teams more accountable to each other and their success.”
Essentially, it’s important to strike a balance between a strong, collaborative team dynamic and a grounded guiding force from a lead developer or manager. Agile doesn’t mean you do whatever you want, whenever you want, with no regard for the consequences. However, it also doesn’t mean an entire team should follow directives given from one sole individual.
To produce smaller, iterative deliverables and provide continuous value to consumers and partners, there needs to be a unified sense of democratization within any agile software development process.
Grow Your Productivity By Focusing on Moving Forward Instead of Backward
In a 2017 Forbes study, 92% of senior executives agreed that organizational agility is a crucial part of business success. Despite this, one of the biggest obstacles many businesses face when trying to adopt more agile practices is either an organizational culture that’s at odds with agile values or just general resistance to change.
Ironically, companies who say they’re agile but live with those internal blockers are totally against what agile is all about, namely “the ability to create and respond to change.”
Let’s be honest with each other: If previous industrial revolutions are any indication, change is inevitable. At the hyperfast pace at which new technology hitting the consumer market, that’s never going to change. How you evolve with, adapt to, and even embrace those changes is a voluntary action that lives at the heart of the agile method.
So, how do you get all your employees, managers, executives and external stakeholders to buy into this change? If you’re new to agile development, it starts with putting your team’s needs first. Use a change management process that not only clearly communicates the benefits of this new way of working, but also shows them you care about their success.
As per Capterra’s blog, “the best way you can address and ease these fears is by communication. Be transparent throughout the organizational change process. Talk about why a change is coming and what purpose it serves.”
If your developers already practice an agile or agile-hybrid method, it’s critical that everyone stays the course. Don’t let one failed project that was deemed too costly, grueling or frustrating revert your organization’s development tactics back to more traditional methods.
For agile to work, you need to engrain those processes into your company’s operational fabric. As time goes by, you’ll be able to tweak and refine those practices to better suit your team’s collective strengths and weaknesses. Quitting before you even get to that point, however, is not an option.
Optimize Your Development Practices With DevOps Integration
I mentioned going back to basics earlier, and, to truly adopt agile development practices, that adaptive logic needs to extend to other areas of your organization, such as IT services, marketing, customer success, and more.
In recent years, this has been achieved by implementing a DevOps presence as a means to bridge communication gaps between personnel and secure a suitable environment for testing. With a 17% adoption increase in 2018, the value of adding DevOps to your organization’s internal arsenal will only continue to grow.
Without DevOps, finding that balance between quick, responsive turnaround that meets newfound business needs and stable, reliable IT service is tricky at best. As author and Tripwrire founder Gene Kim noted:
“[This conflict creates] a horrible downward spiral that leads to horrendous outcomes. Every time we cut corners, or manually deploy code, or write code that doesn’t have automated testing, it all leads to the accumulation of technical debt.”
While agile software development and DevOps are totally different concepts, it’s how well they play off each other that separates the efficient, reliable technical backbones of successful businesses from their inferior imitators.
As this Atlassian blog post puts it, “neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals.”
If you bring your company’s adoption of agile back to the core of the method’s Manifesto, you’ll see that DevOps can be an ally when constructing a set of simplified development practices that encourage rather than impede progress.
Avoid “Agile Fatigue” With Better Communication and Collaboration
Finally, let’s talk about “agile fatigue,” a concept that has gained a ton of steam in the back half of the current decade.
Despite the popularity of agile, more than a few IT professionals and their non-IT colleagues have probably rolled their eyes when they hear someone pump the method’s tires past the point of proper inflation. In short, more than a few people are tired of hearing about how flawlessly great agile software development is.
Blog posts like this one sum up the frustration felt by those who have correctly observed that, on some level, the concept of agile has lost its meaning in the mainstream:
“Today ‘Agile’ means anything and everything. Increasingly, it means nothing. Many organizations are ‘Agile’ fatigued and refractory, or resistant, to ‘Agile agile Agile agile agile agile Agile agile.’”
How do you combat this level of apathy? It goes back to the idea of democratized collaboration and using those tools to mold the agile mantra to fit your organization’s specific needs, goals, working habits, and software development style.
That process–one that involves gathering productivity insights through performance metrics and practical trial and error as you see what works best for your team–is ongoing. It may sound like a massive undertaking, but the core ideology is actually very easy to implement:
“Find out where you are. Take a small step towards your goal. Adjust your understanding based on what you learned. Repeat.”
If “agile fatigue” is diffused with a customized version of the methodology, you can increase productivity and fortify your organization’s potential to promote growth and scalability through software development and digital asset management.
Recap: Fixing Agile is Easier Than You Think
It’s clear that what it means to be agile has become less and less clear to many in the tech space in recent years. As a result, businesses looking to inject agility into their software development practices often fall short of what might be considered lofty goals.
The question I posed at the beginning of this post—whether the method or the implementors are to blame for agile adoption difficulties—doesn’t have a clear-cut answer or solution. In fact, fixing agile software development and reversing any negative ripple effect it has on an organization is, truly, bound by the context of the business in question.
In other words, it’s how you use agile principles and, more specifically, how you make them your own, that is the antidote that cures your company’s software-related ills. Whether that means better communication, more active leadership and guidance, or simply going back to basics and fostering a more collaborative environment, seize the day.
The future of your organization depends on it.
Originally published Jun 20, 2019 8:00:00 AM