Agile scrum development is a philosophy for building and deploying software quickly, cost effectively, and with minimal risk. When I lead a software development team I insist on agile methodology for our team and projects because of its clear advantages for client involvement, creation of business value, transparency, and responsiveness to change. An agile philosophy, however, means by definition that projects don’t have a clear scope, defined endpoint, or even a master plan.
It takes time and training for clients, management, and operations to understand agile development. I can’t tell you how many times I’ve explained that I don’t choose what we’re building. The business's priorities decide. The flexible nature of agile methodology can make it difficult to sell the approach to new clients. In this article, I’ll explain the problems with the old school approach to software development, how agile addresses those problems, and why clients should see agile as a business asset rather than a liability.
The Problem with the Old Way
The old method of software development is called waterfall development because every new update comes in a huge torrent of code with long stretches between updates. Before each waterfall, all the project’s stakeholders would create a huge document of specifications for the entire project. The software development company would then estimate how much each segment of the development process would cost and how long it would take. From the client’s perspective, having a clear budget and timeline for a completed project is important. They can evaluate if the software project makes business sense and they can sell the clear benefits of the completed project to executive leadership to get the go ahead.
However, this method of software development comes with serious drawbacks. Over the course of months or even years, the software firm would build the product. When business conditions changed for the client so did the scope of the project. It wasn’t uncommon for developers to have to completely rewrite all their work from the past few months, often having to request larger budgets and wasting developer productivity. In some cases business conditions changed so much over the course of development that the finished product was useless to the client by the time the software firm delivered it.
Here’s an Example
Over a year ago, a client asked us to implement an advertising and budgeting system that communicated with dozens of other websites and automatically monitored and controlled spending for various customers. Using the waterfall approach to development, we met with the client over several weeks to nail down how the entire system would work. We then spent three months building this complicated, interconnected system.
After months of development, we were ready to launch the completed software. To our dismay, we learned from the client that while the project had sounded like a good idea three months ago, they now weren’t ready to implement it. We discovered they had requested a lot of features they didn’t currently need. They were trying to future proof the system. The end result was more code that needed to be maintained, software going unused, and a large amount of technical debt.
For software firms and developers, spending months building software that doesn’t get used or changing large portions of it based on feedback kills morale and is very frustrating. Developing and deploying large chunks of code make estimating and scheduling difficult. This also introduces significant technical risk. The key to solving this problem is breaking software development down into its most essential parts and assembling those parts one by one as dictated by business priorities.
Agile Solves These Problems
When I explain agile development to clients it often takes a while for them to get on board with the idea of making software development less predictable and more flexible and responsive. However, once a client begins working with an agile development team they quickly see the benefits.
The basic idea behind agile starts with building the minimum viable product that solves a significant and real need for the client. We use scrum methodology, a variation of agile that involves development sprints where our developers work intensely for a short timespan (a few days to a month) in order to build a specific feature. At the end of the sprint, we deploy that specific change to the client, let them try it out, and ask them for one specific thing they need us to build next.
The beauty of agile is we can estimate costs and timelines much more effectively because we’re building specific features or components. We can also change development priorities when the client’s business needs change. We can begin building our client's next new feature as soon as the next sprint starts. As a result, our clients get more useful software, customized to their current needs and frequently updated, at a more predictable price.