I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.
In this article I want to cover some of advantages and disadvantages of agile software development. I have already written a number of articles about agile development, agile misconceptions, agile benefits and common mistakes make by new agile teams.
Advantages of Agile
Customer Satisfaction by Rapid, Continuous Delivery of Useful Software
Your customers and users will be satisfied because you are continuously delivery value to them with usable software.
This is a stark contrast compared to that of a traditional waterfall product delivery, that if your customers are used to waterfall, they may find it strange adjusting to having working software sooner.
The big downside of waterfall is that you deliver large pieces of functionality towards the end of the project life-cycle. This means that all throughout the development stages of waterfall, your project is incurring costs with no return on investment.
By delivering working pieces of functionality sooner and more regularly you are giving your users an opportunity to get a return on their investment sooner. Sure, they may not have all the functionality they need upfront, but they can start to make use of the solution to make their lives easier and start realising the benefits sooner.
People and Interactions are Emphasized Rather Than Process and Tools
Agile is focused very heavily around people and the interactions between people, rather than process and tools. This is a core value of the agile manifesto.
The reason this is important is because it is the input from your team and customers that will ultimately make your project a success as opposed to what tools you use. Continual collaboration throughout the entire development cycle of your project enables everyone involved to build up a good working relationship that will be based on trust. This trust based working relationship is crucial when building software incrementally.
Continuous Attention to Technical Excellence and Good Design
When working agile your work in shorter iterations and only build what is necessary to satisfy the requirements for that iteration and nothing else. This forces you to keep you designs simple which is very important as simplicity helps you design testable and therefore more reliable systems.
Developers understand, and choose from, many possible technical ways to satisfy business need and these are choices that reflect a craft that balances design, use, and support. They provide the technical underpinnings that enable us always to move forward at a steady pace, and keep code quality consistently high. They do this using principles of truly simple design, combined with a grasp of technical debt and the means to keep it under control. Developers like to use the best techniques for keeping the design under control without excessive work or rework.
Some of these techniques include :
- Refactoring : Refactoring is the process of improving the design of existing code without changing its externally observable behavior. In order to make big changes to the structure of the code, refactoring uses a quick succession of small, well-known steps that can each be verified as safe (functionally equivalent). Refactoring is most often done in the context of Test-Driven Development/Design where extensive tests and simple design make it easy to refactor safely.
- Simple Design : Keeping your design simple and not repeating code helps you keep your code maintainable. If you design your code to be modular and interface driven then you can reduce coupling between objects which leads to more robust systems.
- Test Driven Development : Test-Driven Development is a way of driving the design of code by writing a test which expresses what you intend the code to do, making that test pass, and continuously refactoring to keep the design as simple as possible. TDD can apply at multiple levels, e.g. Customer Tests, Integration Tests, Unit Tests.
Test-Driven Development/Design follows a rigorous cycle. Start by writing a failing test. Implement the simplest solution that will cause the test to pass. Then search for duplication and remove it. This is often called RED-GREEN-REFACTOR has become almost a mantra for many test driven design practitioners. Understanding and even internalizing this cycle is key to being able to use test driven design to solve problems.
Regular Adaptation to Changing Circumstances
Your customer or business sponsor may change their mind about what is being built. This may be because you have given them new ideas from the software you delivered in a previous iteration. It may be because the companies priorities have changed or a new regulatory change comes into force. They key thing here is that you should embrace it. Yes, some code may get thrown away and some time has been lost, but if you are working in short iterations then this lost time is minimized Change is a reality of software development, a reality that your software process must reflect.
Change can be scary at first, for clients and partners alike, but when both sides are prepared to take the leap, it can be mutually rewarding. It’s fair to say that Agile is a journey and Web Technology Group is working hard to offer clients in the private and public sectors ways to adopt Agile practices.
- Get used to prioritising your Product backlog or Work Items : Clients need to be heavily focused from the outset on prioritising the Product Backlog in order to get the most ‘bang for their buck’. To keep delivery focused and optimise the output, the Product Manager needs to be able to have some ‘tough conversations’ about what features are must-haves and when they need to be delivered.
- Make sure you’re ‘bought-in’ to the Agile process : Your team and customers need to be bought into the agile process. The reality of Agile is that once the sprints or iterations are complete, the delivery can be less – or more, of course than what was expected for the budget. Friction can occur if the budget is spent and further sprints are needed. Agile is about clear, frequent and open communication.
- Encourage frequent, open communication : It can’t be overstated, but regular engagement needs to take place between the development team and customer or users. At the end of each sprint or iteration, there will be a formal opportunity to inspect the increment, ensuring that the delivered software is consistent with requirements. Through the whole process, though, discussions need to be open and realistic.
Value cross-functional team members : Your development team should be self-organising and cross-functional. Both of these characteristics are key strengths for Agile delivery. In some ways Agile is a simple idea but the reality is that it can mean different things to different people – especially depending on their role in the software development process. One of the key things, though, is to be open to change. Not just in order to move from traditional ways of organising projects but to adapt your use of Agile itself.
Disadvantages of Agile
Difficult to Assess the Effort Required at the Beginning of the Software Development Life Cycle
A complaint I have often heard from business leaders and project managers alike is that compared to waterfall it is hard to quantify the total effort and cost to deliver a project. On one hand I can see why they would think this, especially when they come from a regimented waterfall process world.
It is indeed harder to fully quantify how long the total project will take, but the mitigation for this is that features product will be delivered incrementally by giving the users the most valuable requirements first.
Can be Very Demanding on the Users Time
Active user involvement and close collaboration are required throughout the development cycle. This is very engaging, rewarding and ensures delivery of the right product. It’s the fundamental principle in agile that ensures expectations are well managed. And since the definition of failure is not meeting expectations, these are critical success factors for any project. However these principles are very demanding on the user representative’s time and require a big commitment for the duration of the project.
Potential for scope creep
Requirements emerge and evolve throughout the development. This creates the very meaning of agile – flexibility. Flexibility to change course as needed and to ensure delivery of the right product. There are two big flip sides to this principle though. One is the potential for scope creep, which we all know can create the risk of ever-lasting projects. The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver. This can make it harder to define a business case for the project, and harder to negotiate fixed price projects. Without the maturity of a strong and clear vision, and the discipline of fixing time-scales and trading scope, this is potentially very dangerous.
Harder for new Starters to Integrate in the Team
Agile requirements are normally barely sufficient. Requirements are clarified just in time for development and can be documented in much less detail due to the timeliness of conversations. This can mean less information available to new starters in the team about features and how they should work.
It can also create potential misunderstandings if the teamwork and communication aren’t at their best, and difficulties for team members (especially testers) that are used to everything being defined up front.
Costs can Increase as Testers Required all the Time Instead of at the End
Testing is integrated throughout the lifecycle. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end of the project.
However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project. This does have the effect of reducing some very significant risks, that can cause many projects to fail. The cost of a long and unpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs. However there is an additional cost to the project to adopt continuous testing throughout.
Agile can be Intense for the Team
Finally, common feedback is that agile development is rather intense for developers. They need to really complete each feature 100% within each sprint or iteration, and the relentlessness of iterations, can be mentally quite tiring so it’s important to find a sustainable pace for the team.