Everywhere you turn these days, people are touting the virtues of agile. Large corporations are adopting it in droves, and you won't find a IT-related job spec that doesn't ask for it. But what does agile really mean, and should you really care?
When you want to get a website platform or mobile app built, your developers are most likely going to tell you that they use "agile", as if it should be this massive selling point for you.
It is and it isn't. In this article, I'll explain why and also explain what it means to you.
What is agile?
Agile is a software development methodology. It's mainly an approach that developers use to build websites, apps and other complex technology systems. There are different types of agile too. You might hear words like Kanban or scrum. These are different ways that people implement agile.
What does agile involve?
Agile is about people working together collaboratively - all at the same time - to define, design, build and test software. In true agile, this means you, developers, designers and testers are working together on a daily basis to get your platform or app built.
The idea is to build quickly and deliver often. It's meant to reducing your immediate upfront costs, so that you can get your product into the hands of real users as soon as possible. This allows you to get feedback on your product; which in turn, helps you to decide what features to add next.
Sound good? What's the catch?
1. Only the development team is involved
Generally, when developers and agencies talk about agile, they're only talking about their team - not you. This means that you don't end up being involved in the day-to-day, and as a result, you sometimes only end up seeing something at the end of each delivery - after it has been built. As a result, you lose the collaboration and synergies that come from working with someone on a daily basis.
2. The potential for rework
Unless you're involved in the day-to-day development of your platform or app, or you receive a wireframe for each screen in it, there's a good bet you'll end up having to pay for some rework.
This is because you won't get a document that gives you a complete view of how your product will work. You'll probably see bits and pieces as the project progresses, but you won't get a whole end-to-end view until the project is done. This means that things might need to be re-visited, and re-worked as your project progresses.
Also, when your developers don't have a full view on what comes next, and they’re building under short timeframes and tight budgets, you can end up with something called “technical debt”. This means that the system has been designed to deliver what you want today, but it may not be the best way to do it, and it may leave you with a bunch of rework to do down the track.
3. Inaccurate estimates
The idea of agile is that you want to be flexible, and spend your time doing rather than documenting stuff. That's not to say that there's no documenting. It's about being smart about it. You don't spend writing a massive document with everything that you want the product to do, and there isn't a massive document showing you how the developers have designed your product.
Instead, you start with something high level and expand it as the project progresses. However, without these documents, it's very difficult to get an accurate estimate for how much it will cost to build your whole platform or app.
Developers and agencies get around this by having a bit of a discovery period. Here, they try to understand as much about your business and your product as possible. This (hopefully) gives them an opportunity to give you a more accurate estimate. However, there will still be a lot of detail missing at this stage, so you should expect them to ask for more money down the track.
Where does that leave you?
All of the above gets in the way of developers being truly agile. However, the alternative approaches for development, such as waterfall, have their disadvantages too.
I believe agile truly works best when you're not paying by the hour for your developers, and when you're working hand-in-hand with them to ensure that your vision is transferred to them.
The overall message is to be informed and be prepared. You want to be able to understand how the methodology works and how your developer plans to use it. This will help you to know what to ask for, and to get the confirmation you need that they are building the product you envisage.
Looking for a developer?
Get my 10 essential tips for hiring the right developer for your project.Download it now for free!