Intro to agile software development
Monday, January 12th, 2009At some point, you’re going to need to have custom software built for your business. Maybe your website will need some sort of application that helps you better serve your customers. Or maybe you have some sort of business process that is growing beyond what can be accomplished with a spreadsheet.
When that time comes, you will need to step into the realm of managing a software project. Unfortunately, it’s not as easy to have a successful project as a programmer may try persuading you into believing.
Frustration at both ends of the table
This infamous cartoon sums it all up (click to enlarge):
Building software is a very abstract process. If you think about it, you can’t really touch, feel, or hold software. It’s this thing that floats in a computer somewhere, stores information, and makes things appear on the screen.
It would be great to know exactly what you’re getting up front, but unfortunately a successful software project cannot be predicted like that. Something will ultimately happen that changes the direction of the project. And if you don’t catch it early on, you’re going to be frustrated, you’re going to waste time, you’re going to waste money, and your software developer is going to be frustrated as well. Nobody ends up happy.
Agile software development to the rescue
Some technology agencies will describe themselves as “agile” without really knowing what that means. Or they may mask it with a process that appears to be agile but isn’t really.
To make the definition as simple as possible, agile software development is a way to communicate and refresh expectations throughout the entire development process. This is done with constant communication between the developer and the business owner. And it involves constantly iterating and improving based on the business owner’s feedback.
What agile is not
If your process involves explaining requirements, receiving a lengthy requirements document, and signing an unmoveable contract for those requirements, then the process is not agile.
If a requirements document drafted at the beginning of the process is your only chance to communicate with your programmer, then you’re going to end up receiving software that doesn’t fit your needs. Imagine a scenario where you spend a lot of time defining requirements, and then you receive your software 6 months later. You’re likely to be surprised by the nonsense that those kooky programmers will end up producing.
Pains of agile development
Probably the biggest danger that you can get into with agile development is to be too loosy-goosy. I’ve heard someone joke before that agile development is for teams that don’t want to plan anything anymore. That’s not the truth in many cases. The point is to develop a small part of the project, react to it, and quickly adjust to needed changes.
It’s not like there can’t be a “master plan” and schedule. It’s just that keeping rigidity is not realistic for these types of projects. There are too many risks and unknowns before the project even begins, no matter how hard you try to explain things before development begins.
One thing that can hurt too is how realistic things get for the business. Having Feature X can quickly become a lot more trouble than expected. So agile development forces you as a business owner to decide whether it’s worth the trouble—and the extra budget—to continue development.
In a way, this methodology really helps you to prioritize and live with sunk costs that could have ended up going out of control. When things are tight, this can be painful, even if it is healthy and helpful.
Comfort of a contract
I just wanted to take a few minutes to educate you on another option and to debunk misconceptions on what agile development is. You can still hire developers on a rigid contract if that’s what makes you most comfortable. But you may also be stilting your relationship with your programmers, and you may actually be blowing your money low quality output.
