Agile, a software industry buzzword, is a methodology infused with promises of speed and the ability to produce outcomes that can turn a struggling business around.
But there’s more to agile than just moving quickly and pivoting at will. For the true effects of agile to materialize with maximum gains, the software that supports the business also needs to be able to handle the change of pace. That’s not always the case.
What Agile Is, What Agile Is Not
Agile is a methodology that allows software teams to release features and applications quickly. It’s laced with other buzzwords and jargon like sprints, scrums, flexibility, continuous improvement, iterations and release cycles. While these are fantastic tools for executing agile, many businesses don’t know the fundamental requirements that make agile successful in capturing a market and increasing the bottom line.
Software leaders including Robert C. Martin and Martin Fowler first codified the methodology was first established through the Agile Manifesto.
What Is Agile Methodology?
- Agile is a project management strategy made for software teams to deliver features and extensions to existing applications at scale and speed.
- Agile focuses on making sure the final product works (rather than documenting every possible step required to get to the end goal).
- Agile anticipates there will be unexpected obstacles in the project and gives developers the flexibility to make decisions rather than work through company bureaucracy to do their work.
Agile Methodology Is Not...
- A series of plans and features that needs to be implemented in a particular sequence and delivered as a whole.
- The act of extending legacy software that’s past its use-by date.
- A free-for-all approach with no discipline that results in low-quality deliverables.
While agile is written by software developers, it’s nevertheless a business-centric methodology. Why? Applications exist to serve the business, which means the process of developing software needs to be able to attend to the needs of the market.
The Problem With Agile
The ability to respond to market needs quickly is great. That said, if legacy code, outdated frameworks and insecure libraries hinder software platforms that enable a business, it’s impossible to become a truly agile-driven enterprise.
Imagine driving an old car. It’s already got more than 180,000 miles on it and can’t run over 40 miles per hour without sputtering. It’s also a gas guzzler, drinking each gallon like it’s made out of air. But you’ve had the car a long time and want it to be better — a modern, cost-effective hybrid with AI consoles and self-driving capabilities.
You start chopping and changing things — from the seat coverings to a fresh coat of paint. You might beat out that dent in the back and put in a new windshield. These are all cosmetic fixes. Under the hood, it’s still the same old car. This is what happens when you try to take outdated code and re-vamp it with agile. You might be making the process look pretty but once you take a peek under the hood, you’ve still got a clunker on your hands.
Everything ages and eventually degrades. The more features and functionality you push on to an existing application without refactoring to ensure cohesion eventually overextends the engine. Sometimes, refactoring can’t save the application because the engine wasn’t designed for the change in the first place.
You might be making the process look pretty but once you take a peek under the hood, you’ve still got a clunker on your hands.
Agile is a full-package deal. You need the methodology but you also need a software platform that can actually handle the . . . well, agility. You can’t have one without the other.
Clarity, Code, Cohesion
Code is a representation of ideas. Agile is the ability to implement ideas at speed. When the design and development teams are able to work together and at the same pace, you can achieve agile.
However, code and acts of coding are often the bottlenecks of deliveries. This is not the engineers’ fault but the code with which they’ve been saddled. Code ages poorly and can incur security vulnerabilities when packages, frameworks and libraries need updates. Maintenance is often an afterthought because non-coders often see code like a building — you build it once and call it a day.
Not so fast...
A Tale of 2 Payment Platforms
Going agile doesn't always mean completely discarding the old and bringing in the new. Rather, it's an honest assessment of what you currently have and whether or not it’s worth investing time, money and resources.
Let’s take a look at PayPal as an example.
Their product is simple — it’s an online payment capture system used by millions of people all over the world. However, back in the early 2010s, it would take months for anyone to make a change to the code. Developers found that the software’s infrastructure and architecture hampered their ability to move quickly and make changes.
Stripe, a fledging competitor at the time, was growing rapidly and making headway in terms of heir ability to make improvements quickly. For example, Stripe’s API integration documentation was much easier to navigate and understand. The data structure, reporting availability and developer support from Stripe were much more user-friendly than PayPal. In addition, the development community got excited over JavaScript’s exponential growth after Apple banned Flash from their mobile and tablet devices. If PayPal did nothing about their platform and their inability to respond to change through feature deployments, they risked losing their market share.
So what did they do?
PayPal knew that they needed speed but rather than investing in a system they knew wasn’t working, they re-built their existing system in parallel — but with completely different continuous delivery and continuous integration (CD/CI) pipelines, tech stack and architecture.
PayPal’s ability to respond to change and ship out new features took six months to a year.
PayPal built its new platform alongside the platform currently in use and had a small core teamwork on the new architecture. The switch only happened when the new platform, built on the mentality that speed and the ability to add features quickly, was an exact visual replica of the live platform actively in use by customers. While it seems counter-intuitive to build the same product without any cosmetic changes, the underlying code was completely different.
Once PayPal made the switch, they created new reporting features and shipped them within weeks rather than months. Developers deployed UI and UX design changes in small pieces rather than large chunks because the new software could handle small, constant change.
What does this have to do with the agile methodology? PayPal recognized the validity of their business model but their platform created a bottleneck for their operations and growth. They can’t be agile — that is, release new features at speed — because their legacy platform wasn’t developed for such a fast-paced environment. Before the migration, PayPal’s ability to respond to change and ship out new features took six months to a year. If they continued on that path, emerging competitors like Stripe surely would have captured a good deal of PayPal’s market share.
The Takeaway
Agile is more than just coming up with an idea and getting it implemented as quickly as possible. It’s also more than just tacking on more code to existing, clunky, outdated software.
Agile is a structured process requiring software that can change quickly. This means the underlying code, app, widgets, systems and plugins that support the business need to be elastic enough to respond to updates and new features. Unfortunately, not all systems can. Before implementing an agile methodology, take a good hard look at what you currently have to assess if it can support the demands of agile practices and methodology.
