It's all about Agile...

Conventionally, when someone thinks software (mobile applications, desktop, websites, you name it) development, brightly colored text over a dark background comes to mind. Curly brackets, walls of code, and complicated software are the poster child of software development, to be sure. But in the real-world text editors, special formatting, and even whole programming languages are just the tools to programming nearly anything. Sitting behind those tools are real humans channeling all their efforts into crackling and snapping fingers. So, for this article let us shift our focus from the tools and onto the real heroes of software development; and there is a lot to say about humans and working with humans.

People bring their own complications to the table and, more often than not, developers are more proficient with handling complex code than simple humans. Working with different people of different perspectives and backgrounds can get ugly if not managed well so someone had to figure it out; enter Agile Software Development. Agile is one of the most popular (and growing) methodologies to handling and working within the cross-functional teams that produce expertly crafted software.

So what is Agile Software Development?

Before explaining what the Agile methodology is, you have to be aware of what came before it; the waterfall methodology. The Waterfall methodology was developed in the 1970s, inspired by the manufacturing techniques used at Ford. It is based on heavy documentation and preset, rigid requirements. For example, during the beginning of a project, the business team will collect the requirements from clients and document all the details, from features and functionality to design and colors used. Needless to say, these documents needed to be fairly large and detailed. After that, this document gets passed on to the technical team, where they are to set the technical requirements based on the client’s needs. Then, a final document - nicknamed “Specs” by developers of the time - would be passed onto those who will implement it, and they would now be required to know all the details of that document. They are also required to document all they did and stick to the strict deadlines. You can only imagine how long this process would be, not to mention how inflexible and expensive.

The Waterfall methodology was still somewhat acceptable during the days when software was built with the idea that it will probably last and be used 5 or even 10 years into the future. However, with the rise of the Internet, and web applications, this methodology would only have you release an application that is already 5 years outdated at release.

Gradually startups and smaller companies started adapting to the fast-paced industry and to smaller teams. This birthed the Agile methodology through the Agile Manifesto, which was written by software developers to bring a new philosophy that puts working applications above documentation, and individuals and collaboration above processes and tools.

So how it works is that after the requirements are set and agreed on, the project is divided into 3-4 week phases called Sprints. The developers meet and agree on what parts of a project can be done in a single sprint, then they move on to development, then it moves on to testing and deployment. The focus here (as the name implies) is on speed and agility: if a task assigned to a sprint is not finished on time, the Agile process does not stop - it goes on. Once a sprint is completed the team meets to evaluate their work and find out what they can improve on and what they should keep doing. If you are having a hard time visualizing, it can help to think of it in simpler terms: plan, implement, evaluate, rinse and repeat.

The Agile methodology is built on interaction and collaboration, which means that the developers, testers, and project managers all work together at every step to make sure that all aspects are well-communicated. This is usually done through daily standup meetings to get everyone up to speed on the progress done, or if there are any challenges.

What it does right...

There are a couple of things Agile is really good at doing. After all, a company like IBM wouldn’t adopt the methodology just because it is trendy. One of the more apparent, and significant upsides of adopting an Agile software development workflow is to ensure customer satisfaction. This is caused by the continuous and frequent communication that’s embedded within Agile, as well as the more frequent software delivery (weeks rather than months). Another thing that Agile gets right is through its encouragement of face-to-face communication. Simply put, this is the perfect way to avoid confusion and miscommunication especially in a cross-functional team. Another advantage brought about by being Agile is - and this is a part of the “sprint” routine - is that changes at any stage are welcomed. At every step, the process is revised and a short-term plan is put in place making changing and adapting the process incredibly easy even for relatively larger teams.

What it does wrong...

There are, however, serious pitfalls Agile and Agile adoptees struggle to avoid. The strongest points in favor of Agile also play a part of its weakest. Because of constant meetings and planning and short cycles, working in an Agile workflow can seriously tire out all who are part of it. There is a lot of time and commitment needed to stick to an Agile workflow till project completion. Which brings us to the second drawback: Agile is a strictly short/medium-term methodology. Going on sprints after sprints for a few months is a great way to be focused on the nitty-gritty details of what to do on the daily. But the 2-4 week work cycles of Agile means that there is hardly time for raising your head up and fully taking in the bigger picture. The last point we noticed - but far from the least - comes perhaps from the purpose Agile was created for; it is no secret that a company following Agile will produce weaker and less useful documentation. Remember, Agile came to replace waterfall and its rigid time-consuming documentation, but it might have just gone to the opposite extreme.

Wrapping-up

Here at Intcore, we are strong supporters of Agile development. Our own teams believe in the philosophy behind the method and we just find ourselves naturally gravitating towards it. That said, we are not oblivious to the pitfalls of Agile software development - it was developed by humans after all. Our rule of thumb is to never take anything as is. We’re always on the lookout for pushing our processes to even greater efficiency, and textbook-Agile can sometimes be counterintuitive. We follow the adaptability deeply embedded in the spirit of Agile and adapt even the methodology itself to our goals and capabilities.