Pros and Cons of Agile Software Development

Before we get into what are the pros and cons of agile software development we first need to understand what actually is agile software development.

Software development

So what is software development? According to Robert “Uncle Bob” Martin, it is a craft. It is an art and not an assembly line. There is no process that can guarantee the success of a project, but there are certain disciplines that can increase the chances of success, that are now called agile.

Agile software development

Now to the next question. What is agile development and why does it exist? Initially, there was an effort to establish a process of software development called waterfall. Everyone is familiar with the waterfall process.

It looks so logical. First, analyse the requirements, design the solution and implement it. So what was the issue with this process? Well, the main problem was that the process was overused. Notations about documenting design and requirements appeared and there were months of analysis of requirements and design, producing documents before the system went into the implementation phase.

And many projects failed because of this. Half of the projects never made it to the end-users, because they significantly failed to meet the end-users’ needs. Another huge part of the software projects could only be used after extensive rework.

And this is not all. From the projects which actually made it to the end-users half of the implemented features were never used. The results showed that the waterfall process was not the way to produce software. So people started to invent new approaches, like extreme programming for example with short cycles.

The rise of Agile

So in 2001, those inventors of processes gathered together and produced an agile manifesto, which was put on a web page where other people could sign it. It is the agile manifesto, which is a set of principles and not a process. The principles are quite obvious. I could summarize them with one sentence. Don’t blindly follow a process, plan or continue to use tools when they are not working. So this is how the agile was born.

Pros of Agile Software Development

So what problems does agile development solve? Here is my top list of problems that agile development tackles.

Ability to adapt to requirements changes

I think the most common part of all approaches is the short cycle of development. For example in SCRUM usually, the teams have two-week-long sprints where certain features are implemented and at the end of the cycle, the stakeholders give feedback about the produced software. At any time if a requirement is changed the software can be adapted fast.

Constant communication with customers

Here in our bespoke software company we know from experience how important it is to be in constant contact with the customers. It is important because only then you could really understand their problems and produce software that actually solves them. Many projects fail because the connection between the business and the technical people is broken.

In those cases the software starts to diverge from what the end-users are expecting. New features are implemented in place of other more important features. In agile methodologies like scrum there are regular meetings with a product owner which constantly drive the software in the right direction and don’t allow it to diverge from what is important for the end-users. This pretty much aligns with the agile principle “Customer collaboration over contract negotiation”.

Transparency

In the agile methodologies customers are more engaged in the development of the software. They get informed early about the problems and what needs to be done in order to produce certain features. From experience, I know that when this transparency is missing a frustration starts to build in the customers. Every estimation that is given is only a guess of the development team how much time something will take because there are always uncertainties.

During the development process it might happen that a technical risk appears, for example a library gets deprecated and needs to be replaced. If customers don’t get informed about this they get frustrated that their expectations are not met at the end. The short cycles and the communication helps a lot in aligning the context of the technical side with the business side of software development.

Handles uncertainty

There are many uncertainties in a project. For example, we might have requirements uncertainty where the goals of the software are not clear and customers are not sure what they want. Or technical uncertainty when the team is not familiar with the technology behind the software. With agile development, uncertainty can be handled on portions. Delaying to make any decision until everything is clear leads to analysis paralysis and nothing is achieved.

Motivation

This is something that I personally felt and to be honest, I think it’s one of the main things that make agile development more successful compared to the waterfall method. How does agile methodology help with motivation?

In my personal experience I notice that when people get positive feedback about something they did, they get very motivated to make the people giving the feedback (the stakeholders) happier and happier. It’s very motivating when someone tells you that this feature that you coded makes 50 users happier. And when you get this feedback regularly on every cycle the motivation levels stay up constantly.

Cons of Agile Software Development

Some of the problems with agile processes are related to particular methodologies. The methodologies are considered as processes and followed to the extreme. Here are some of the issues that I personally faced.

Overuse

My main concern is that agile methodologies like scrum, for example, are used as processes. People blindly follow the process without thinking if it’s working for their case. Let me give an example. Imagine a project where the initial development was done using scrum with two weeks iterations. At some point the project gets released.

Now, this software goes into another stage of its life cycle. The software needs support. The sprint scope is getting constantly changed because there are bug fixes that need to be applied with priority on production.

As a result, the team never achieves the goals that are planned during the planning meeting. Motivation drops down. Scrum is not working well for supporting, at least from my experience. Kanban is much better and handles better the described situation where priorities change very quickly.

Technical debt and technical tasks

The agile methodology always leads to technical debt. Developers don’t have all the context around the system to be able to produce proper code design and architecture. If the customers are not sure yet what functionalities exactly they need, how are the developers supposed to come up with the perfect domain design which stands the test of time? 

I am a hundred percent sure that every software project on the planet has technical debt. If we get for example the scrum methodology it is not mentioned anywhere how the technical debt tasks should be handled. They are not tasks that produce functionality and it’s sometimes very difficult to convince a product owner that they need this technical debt to be handled. 

Agility to the extreme

Sometimes from my experience, people get the agility term and the agile principles to the extreme. For example, it happens at the beginning of a project to get a story described for example as “As a user, I want to have a gift module”. This is such a generic description that requires someone to spend a lot of time to refine, make some wireframes and come up with some MVP for this module.

Basically to collect the requirements. And this process might involve some focus groups to be engaged for example. So it is something time-consuming. Although I agree that agile methodologies help with uncertainty, it’s best if part of this initial work is done before the story appears in the backlog or to have a clear distinction that it’s not even ready for technical refinement. It really depends on how the team is structured but those tasks for requirements gathering can also be the responsibility of the development team.

Misunderstood methodology “rules” which are not working

In the Scrum Guide, the sprint is described as:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. 

And I notice from my experience that this sentence is misunderstood a lot. It happens from time to time to get a comment that this sprint is not releasable with a note of frustration. However, nowhere it’s mentioned that each sprint should produce something releasable. It might be potentially releasable but this is something to be decided not by the scope of the sprint. What is certain is that the project should be usable.
There are other examples of such misunderstandings where the main focus is on the business aspect of development. Uncle Bob summarizes them as Flaccid Agile, described as trying to do agile without technical disciplines, in his clean coders training.

Conclusion

As conclusion, I would like to say that what makes a project successful is not the process or methodology which is used but the team. If the team is motivated to do the project and feel passionate about it they will manage to do it the right way even without following specific rules. So what issues or success stories do you have with agile?