This blog was cowritten by Russell Craxford, Head of Quality Management at Infostretch
Several years ago, we had the opportunity to work on an exciting new waterfall project that was quite large in scope. It was hard, continuous work with no interruptions, no iterations, and no feedback. For three years, we pushed our limits every day to create bespoke software. But when we presented it to the client, the client wasn’t satisfied—what we built was completely wrong.
Years of hard work down the drain. And then came the meetings where people questioned what went wrong. There were endless conversions where fingers were being pointed at every person, every graph, and every deliverable. And that was how I spent a long winter trying to make sense of what happened with our first Waterfall software development project.
There is no doubt that this methodology has served as a foundation for creating many methodologies that are popular today. But considering the dynamics of the modern world, we cannot remain within the confinement of this tight methodology.
Over the years, we experimented with many software development methodologies. Finally, the Agile methodology emerged from the trenches. While we were on the edge of stressful developments, this methodology surfaced and served as an emollient that simplified and smoothened the software development journey. Previously, my days were filled with stories of backlogs, but the new journey introduced new terms: stand-ups, retros, sprints, ceremonies, and more.
Key Agile Differentiators
If you are a veteran in the software development field, you might be familiar with the Agile Manifesto that iterates 12 principles and 4 values.
Now, let’s talk about how these bullets work in practice. Traditional development projects are heavily regulated, and teams must comply with tried and tested methods. And while they follow strict routines, a client can suddenly come up with a change in requirement. Sometimes, these changes can be nightmares because they might require a complete rework from the start. If such situations are not handled properly, they can result in a loss of revenue or a loss of a customer’s trust.
Agile says that requirements keep changing. So instead of dreading changes and hoping that a customer would not come up with a requirement out of the blue, why not be prepared to deal with changes? If you were working on a construction project, such changes may be unwelcomed. However, a software development team might require flipping between low-level and high-level designs as customers demand flexibility with requirement changes.
Agile is a departure from traditional methodologies because Agile makes teams take ownership. They are not just responsible for performing assigned tasks but also feel accountable to deliver results. And this is what gives them the power to progress. While the waterfall approach is tied to outputs and stages, Agile is more interested in outcomes and solutions.
Here’s an example of how Agile can make a difference to your customers:
Traditionally, after a long time spent on development, a solution—perhaps a mobile application—is delivered to a customer. The customer finds the interface challenging and confusing. Thus, they are not happy with what you delivered. You talk to the customer and explain the solution to reduce their stress. Now, you are waiting for an acceptance. However, the client has no clue what parameters to judge you on.
This is one place where the Agile approach can help. Your customer would not be given the full solution after months or years of work, but you would be delivering one user story within a few weeks. And while creating a user story, your team is focused on the results and value they create for the customer. And this story will have pre-defined acceptance criteria identified based on your customer’s requirements. Your delivery clearly states the outcome and value and presents a user story to connect with.
With this clarity, a customer would either accept the story or would suggest improvements to go into the next iteration of the development cycle. There are several benefits of this approach:
Let’s explore one more example.
If you are a developer, you must be familiar with dashboards. For every new project, you have a dashboard that monitors everything in progress. You have a Sprint dashboard, JIRA dashboard, and a Kanban dashboard. A dashboard is supposed to present a comprehensive view of your system, so why use multiple dashboards? A single dashboard capable of providing an overview of all projects at once is the way to go. An Agile system would push the consolidation of views, backlogs, stories, and issues.
Cultural Shift of Agile
Agile transformation is promising but not easy, especially because of resistance to change. Adopting Agile methodology requires a 360-degree transformation that will not just happen in technologies and processes but majorly in your organizational culture. A culture shift is essential to enact change. For true adoption of Agile culture, you might have to change your beliefs and working patterns. While traditionally, you may have discussed all requirements and project needs within your team of developers, Agile pushes you to open the conversations to include more stakeholders like customers, architects, and testers. This is not an easy job and thus, is often met with resistance from those uncomfortable with change.
Let us see how an Agile organization would appear different from a non-Agile one in the context of culture:
Agile Myths
There are also some myths surrounding Agile that put limitations on organizations when considering adoption. Many people believe that Agile is suitable only for software development projects or to fulfill high-speed IT needs. That is not true. Take the example of Proctor & Gamble, the global commerce giant, that adopted the Agile methodology in 2017. Before this adoption, the company was facing challenges related to marketing, costs, supply chain, and technology adoption. Post-implementation, the organization became progressive in marketing and was able to enhance its production efficiency by 40%. With Agile, GE improved its desk utility in offices while Lego eliminated duplication and improved planning.
Another myth about Agile is that it is less disciplined than traditional approaches. The truth is that Agile fosters discipline not by restricting activities but by enforcing a customer-centric culture, directing teams towards goals, maintaining communication with stakeholders, speeding deliveries, and encouraging continuous improvement.
Some new adopters think that since Agile encourages faster deliveries and development over documentation, it doesn’t need any planning and documentation. On the contrary, Agile simplifies planning and documentation by removing rigidity from the traditional methodologies. What Agile suggests for documentation is simplification, no duplication, and documentation of executable specifications. Documentation is pushed to later stages of the development life cycle and is produced close to when it is needed or just before the release.
Embracing the Agile Culture to bring transformation
Organizations toying with the idea of implementing Agile often ask themselves: Why Agile? We suggest you instead ask: Why not Agile? Why not implement a methodology that can address traditional software development challenges like communication issues, inaccuracies, quality problems, and no sharing of responsibility?
Why not unlock all these competitive advantages:
What you adopt by embracing Agile is mainly a culture driven by solutions and customer needs. Agile culture has some striking features adopted from its principles and values that distinguish it from other approaches such as centralized decision-making, stakeholder inclusion, interim deliveries, continuous improvement, and consistent communication. The difference that Agile creates as compared to traditional approaches clearly provides you with enough reasons for adoption. However, for successful adoption, you need to step out of your comfort zone that is created by legacy systems. And when implementing, don’t fall for myths and stay put with best practices.
Agile takes organization-wide effort to adopt successfully, but in the end, it is truly worth it.
To learn more about Agile transformation or scaling your agile practices to accelerate your digital initiatives, check out Apexon’s Agile services or get in touch directly below.
Also read: Innovating at Scale: How We Leveraged AWS Elastic Beanstalk for Agile Development