Is your agile software development methodology truly mature? Start with these questions
7 minute read
Many companies today are attempting to adopt agile software development methodology—but attempting is the operative word here. Over half of respondents in one recent survey by Digital.ai said at least some of their teams were using agile, but 30 percent also said they encountered various challenges such as inconsistencies in practices and a lack of leadership participation. These hurdles keep many companies from adopting agile to the fullest, and for many, agile maturity is still a long way off.
It's understandable: When it comes to product development, many companies have long been accustomed to the more linear, rigid waterfall approach that works pretty well for traditional project management. Breaking old habits in favor of agile isn't easy, but it is necessary for companies to stay ahead of the competition in today's fast-paced technology landscape because at its core, software development doesn't have projects and can't be managed in that way.
An organizational commitment to truly adopt agile software development methodology can help you create better software(opens in new tab) and take advantage of new market opportunities faster. It will help you create a product that customers truly want and adapt quickly to user feedback. And if you're reading between the lines here, good. This can mean the difference between success and failure for your products, teams, or organizations in general.
But if you’re finding that agile isn’t getting you the results you want, it's likely because you’re still missing some essential pieces to the puzzle. And an honest evaluation of where your teams or leadership are falling back on traditional project management methods will likely uncover the sources preventing your company from achieving all the tremendous results agile offers to your organization.
Answering a few simple and effective questions as thoroughly and honestly as possible will help you determine your true level of agile maturity and where there's room to improve to become more agile over time. Start with these:
The general framework of project management doesn't work as well for software development. Setting tight schedules and budgets from the get-go might work in other product cycles, but software development doesn’t have a predictable formula that makes it possible to calculate ahead of time. This problem of even demanding a timeline and budget for software development is flawed and demonstrates a disconnect between the business and the engineering teams who are operating under different methods and mindsets.
The agile software development methodology is specifically designed with this fact in mind. If you have a fully matured agile approach at all levels of the organization, you should be able to replace long-term, high-level budget and planning meetings with more ongoing, continuous planning in smaller cycles just before the development teams build or test concepts. This way, you're likely to set more achievable goals rather than unrealistic outlooks that can only lead to disappointment.
Rather than trying to deliver one massive product at some distant endpoint, agile breaks a project down into more digestible chunks that can be delivered in small stages while still providing value to customers and learning to the business. The outcomes of each of these smaller-scoped projects then happen at a faster pace, providing project leaders with more accurate ongoing information, leading to an approach that emphasizes results and learning rather than arbitrary deadline and budget adherence.
Are you (and your end-users) satisfied with the final software product you've delivered, or do you end up spending too much time going back to fix bugs, improve design, and address customer complaints? Even if you’re delivering on deadline, if what you put out into the world keeps coming back to you in a surprising way, chances are there’s room for improvement in your development methodologies.
This problem often stems from the same issues present in the first question: rigid deadlines and unrealistic budgets. Strict deadlines often make developers feel like they have no choice but to sacrifice quality in favor of timeliness because teams are being managed against budget and deadline constraints. While this accrual of technical debt is a natural part of the software development process, without a fully baked agile development methodology, there's no system in place to consistently address this accumulation of hidden work. The results manifest in poor code quality and sluggishness of agile development teams that just get worse over time.
Agile is designed to focus on the product delivered to the customer—not on a deadline or budget. This is because agile software development relies on short development cycles and compact feedback loops intended to detect and address issues within each cycle instead of once the final product is complete. While this might result in missing a deadline or two, the finished product will be in much better shape.
Waterfall development is a stubbornly linear process, relying on specific gated stages to happen one after another, without fail. Discovery must lead to analysis, which leads to design, then building, then releasing to customers—and only then does the company learn if the solution delivered on the business results, if those were even clear to begin with. This is fine for traditional project management (though, arguably, all types of projects can benefit tremendously from agile), but software development is fundamentally different and is representative of a deeply creative and complex series of processes that are anything but linear.
In many ways, development processes look more like a brainstorming chart, with different lines connecting different aspects of the stream and new lines with each new issue or piece of user feedback. There just isn't room for traditional methods of management because it's not a traditional linear process.
In agile software development methodology, deviation from the plan is the norm. In fact, lengthy, detailed requirements documentation is exactly what seasoned agile practitioners vehemently oppose. And for good reason. It's exceptionally time-consuming, and as soon as it's written, it becomes out-of-date. Companies understand that agility leads to better products because planning is responsive, lightweight, and adaptable—exactly what modern businesses need to survive.
The method gives developers more flexibility to respond to new opportunities and challenges as they occur. On the other hand, with the waterfall methodology, addressing these things would mean an inefficient approval process for deviating from the plan. And that lack of agility can cause serious issues. In one extreme example, a coding error that developers couldn't quickly resolve led to Knight Capital Group going bankrupt in 45 minutes. In the market and industry in which the company operated, the business was all but required to be as agile as possible to handle this kind of situation, and they failed to do so. A lack of IT agility won't likely cause such dire problems for most, but it can still lead to significant operational bottlenecks, slow innovation, lost customers, and ultimately a loss of market share or market leadership against competitors who likely have this figured better than you.
Unlike a physical product, which tends to function pretty much in the way it was designed, software rarely works exactly as expected right out of the gate. Users might find surprising ways to take advantage of specific features or hate something developers thought would be the software’s crowning achievement. Without seeing each feature in action, there’s no perfect way to predict how end-users will receive it.
The waterfall method doesn't allow for this reality. There’s no way to evaluate how features will actually work in a practical setting because the learning loops are far too long for the business to benefit from them in any meaningful way. Instead, the business and developers have to make educated guesses about each feature's value to the customer and resulting business impact and then cross their fingers, hoping that these assumptions will pan out. Teams have no ability to change course if they learn anything along the way that may suggest an alternative approach may be better. They are often forced to execute on projects that they know will fail as a result.
However, with mature agile software development, feature testing and user feedback are integral parts of the process and are reflected in small iterations or learning cycles that help teams to learn quickly as they go by running continuous experiments, gathering results, and making decisions for how to increment toward their goals all based on measurable outcomes and impact to the business. This allows developers to move forward quickly with the confidence—and clear evidence—that the features they’re implementing are ones customers want and the business benefits from.
A key aspect of true agile maturity is that everyone works together toward the same goals and objectives. Developers' objectives shouldn’t be at odds with business objectives, which shouldn’t be different from customer goals. In other words, for agile to work properly, there needs to be buy-in from the top down throughout the entire operation and a direct line of sight from leadership down to the customer.
If you’re struggling with this aspect of your agile software development methodology, the best place to start is with building internal champions. It’s their job to take tech goals and translate them into business objectives that executives can get behind. Specifically, champions must be able to explain and coach individuals and teams on the differences between agile and waterfall software development techniques and demonstrate how agile can help improve the company's business side. This can be most quickly achieved through hiring individuals with agile experience, tapping into the collective experiences already housed on the team, engaging in paid training or workshops, or even taking online courses or reading books on the subject.
When fully matured, agile software development can be a powerful asset to your business. But the transition from more traditional product development methods takes commitment, and figuring out how far you have to go isn't the most clear-cut. Use your answers to this agile maturity assessment to determine where you are and plan how to get where you need to be to help make the business case for agile adoption across the entire company.