Many of you looking at this title might think,
“Just why is Agile cool, and what is Agile anyway?”
Here at liquidfish, we do a lot of amazing work including branding, marketing, SEO, and software development. Today I am going to talk about the latter. Some people think that software development is a completely predictable process, but this is a misconception. Let me explain.
When a client asks for an application (website, mobile, etc.), usually there is a big, exciting vision. In an ideal world, software developers would spend significant time breaking down all the pieces, documenting each details and requirements, writing a plan, and finally, by using previous experience, estimate and predict total hours and cost for each project. But to write down everything could take forever. Clients usually want to know how much a project will cost and how long it will take to produce a product before paying for anything, or entering a contract. As you see, here we have a vicious cycle. Clients prefer to have promises before paying. Developers would like details and data before making promises. Someone needs to step out of the circle.
This is usually the project manager’s job—breaking projects down into big pieces and providing rough time estimations. Because of our team’s great experience, we do a good job of providing realistic quotes to clients.
This is a traditional process and is well known in the IT industry as the Waterfall approach model.
Using this technique, we provide an estimated total cost for the project and establish the deadline for when it will be delivered. Waterfall monoliths can be ideal for short-term projects that require a strict deadline and budget. The liquidfish team is committed to being overachievers and keeping processes simple for our clients.
At this point I imagine you have a question: “So, what is the problem? And still you have not answered: What is Agile and why is it so cool?” We will get there, I promise. First, I want to show the potential downside of this traditional process from a coder/developer’s perspective.
When Waterfall is not cool.
As our skills and expertise have grown exponentially, bigger fish with more complex projects are swimming to our current. Complex projects require many months of continuous coding, often without feedback, as clients await the final, finished product. The goal of most projects is nicely described and packaged in the beginning by project manager and clients alike. But while they look nice, these descriptions can be fraught with peril for a coder. Lots of positive emotions at project inception can overshadow and obscure issues that most of the time will not be clear at the initial planning stage. It’s no one’s fault; it’s just one of many steps of the process. And it’s normal for multiple people to have different interpretations of information. As I’m sure you can understand, if there is a misunderstanding during the initial time-estimation step, this can bring unhappiness later for both coders and clients.
Another challenge with the Waterfall approach is the potential lack of clear understanding on the coders’ part regarding the details of clients’ specific business processes. To successfully automate a process, we must know all the rules. Software requires precise checks on all conditions to make a right decision (output). Usually people don’t think in this way, and they don’t need to. In real life, the business process is easily executed heuristically. But for a program, every exception and detail must be accounted for. Of course, if detailed and unique business processes are fully known up front for each client, it can make accurate estimation a lot easier. However, this is rarely, if ever, the case. And even if it were, the understanding or desires can be changed without the coders’ knowledge.
A lot of times, our project is dependent on other services. Those services can significantly change the way our project works, or change pricing, as we would need to change our programming in a way that can interact with them. Other times, for various reasons, the multiple services are incompatible, or create environments that are completely unpredictable. We can’t remove this factor. The biggest misconception here is that software development is just about inputting a code that functions. A big chunk of the mission is to clearly understand the exact “whats and whys” of what will be written. Only then can top-notch code be efficiently designed and built. To change something after the whole project is done can be very expensive. Monolithic waterfall processes can result in wasted money and time, both for a designer and for a client. And this is a big risk that I will talk about later.
Summarizing this, we can highlight four big challenges with Waterfall approaches:
- Unclear global goals that may change over periods of time
- Misunderstanding of needs with lack of direct contact between coders and clients
- Lack of knowledge of customers’ unique business logic
- Dependencies on third-party applications
So, what is Agile?
I think you have guessed that I will propose it’s a solution that can cover these challenges. Agile is an approach/methodology that eliminates the pattern of a waterfall monolith. Many different approaches fall under the Agile umbrella, but it has a lot to do with providing micro-services throughout a project. There is even an Agile manifesto (https://agilemanifesto.org). It’s cool, right? :)
An Agile approach has different focus points: Scope changes and “fast failure” are encouraged. Any scope changes are processed as a natural part of development. Understanding how the process is envisioned to work can be changed with new insights or even because of some external factors (economic, political). Feedback is required at regular intervals. Feedback of real users can bring a lot of helpful and important changes in understanding. As a developer, I can say it’s always easier to make than to change something that was done a long time ago. The purpose of failing fast is to get fast feedback while correction is most efficient. Regularly presenting a demo of current status to product owners and business stakeholders helps them to make sure it is as requested, and even more important, to determine if progress is indeed in line with what they really want.
Agile processes involve iterative development. There will be many small steps toward the completion of a colossal project. Customers don’t need to wait for the totality of all massive documents to be finished for review. Finalizing of requirements can be done as the projects go along. There is a huge benefit of being able to start with tests as soon as possible. The ability to respond to feedback and adapt immediately saves everyone time and effort. This is also a benefit because final documents are usually burdensome to read anyway (if it’s not massive, then it usually doesn't include everything, resulting in a big risk of misinterpreting the requirements).
With Waterfall, there is a high upside prospective for continued business coupled with a high downside risk that can ultimately affect costs. Agile procedures remove the risk of unknown costs and delay by encouraging the principle of failing fast to allow for immediate adaptation in cost, scope, and timeframe. The idea of it is to reduce downside risk while keeping upside prospective.
Iterative development can be a little bit tricky, of course. Projects will be divided into pieces and will be complicated with various login screens, lists of users, downloadable documents throughout the process, etc. But developers can implement access levels piece by piece incrementally. Regular feedback is key. This is what makes the process iterative. Otherwise there is the risk of creating multiple mini-waterfall monoliths. Just doing sprints or iterations doesn’t make for Agile development. It’s the attention and adaptation to feedback that breeds efficiency.
Agile development allows for adaptive reprioritization in what can bring the most value to our clients. Iterative development allows our clients to receive a product before it is finished. Sub-portions of final products can be pushed to production and get tested by users, or at least run by higher managers. This would allow midstream corrections from those people whose feedback is the most valuable.
To summarize, I want to repeat the key principles of Agile:
- Highest priority is to satisfy customer needs rather than quickly complete a project
- Coders welcome changes early on and throughout the project
- Frequent feedback from end-users improves and transforms project parameters
- Iterative development is encouraged with fully transparent costs for changes
And that, dear readers, is why this software developer thinks Agile is cool! It’s fine to disagree. There are valid arguments and feedback on all sides. I’d love to hear yours.