Agile Manifesto and 12 Principles behind it
Advantages vs. Disadvantages
1. Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. (Agile Manifesto authors, 2001)
2. Principles behind Agile Manifesto
The following principles are based on the Agile Manifesto.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity – the art of maximizing the amount of work not done – is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
(Agile Manifesto authors, 2001)
3. Advantages of Agile Methodologies
Agile Methodologies are the most recent in software development. Nevertheless, the most undeniable and expected questions will be “What are the benefits of Agile? What can iterative development bring to our company? Or how effective is incremental delivery?”. It is important to understand the pros and cons, common problems, and when to apply it. Through exploring further into the 12 principles behind Agile Manifesto, I have come up with a number of advantages of Agile methods.
- Customer satisfaction [1+2+3+4]
- Agile projects involve the customer regularly through the whole project, not just at the beginning (for requirements) and the end (for acceptance). This customer involvement eases one of the most consistent problems on software projects: What they will accept at the end of the project differs from what they required us to accomplish.
- In addition to uncovering misunderstandings early in the project, this interaction helps the client to form a better vision of the product. Along with the ability to visualize the functionalities, the customers gain a better understanding of their own needs and know how to express it to the developers. It also allows them to identify when their needs change.
- All of these dynamics come together to enable the customer to steer the project on their own to meet what they need.
- Greater agility [3+4+5+6]
- The main reason why the Agile methods are called “Agile” is because the iterative lifecycle is designed to accommodate change.
- The iterative and incremental nature of the Agile planning process makes these changes much less disruptive and cause little or no rework there as well.
- Agility is more than an effective response to change. It makes communication more facile; the method adopts customers as a part of the team to eliminate the “us – them” attitude between the developers and the clients and to help them recognize that planning in an uncertain world has its limit and project plan must be flexible.
- Attainable customer expectation [4+5]
- As the customers become part of the team, Agile projects include them in all of the most important activities: defining User stories, answering question about the requirements, order of development, providing feedbacks and figuring how to adapt to change.
- All of this interaction has the effect of keeping the customer’s expectations reasonable. Because of the high visibility into the developers’ work, the customer quickly comes to appreciate the work and respect them.
- Motivated development team [5+11]
- Agile projects are not planned by a Project Manager, the customer, an executive, or anyone else. The Agile team (both the developers and customer) plans their own work, then works their own plan and are responsible for its success.
- Most software developers appreciate the trust and respect that is implied when management empowers them to operate as a self-directed team as it provides a good environment for knowledge-work.
- The dynamics are simple.
- The customers make sure that they end up with what is needed
- The developers figure out what it will take to make that happen
- Issues, complications, and trade-offs are discussed openly
- Compromises are negotiated and embraced by the team
- Productive development team [5+6+9]
- A motivated development team will definitely result in a productive one.
- There is always a deadline staring them in the face, the team can never afford to slack off. They are always driving toward a deadline that is really near.
- Agile developers focus on working to “pay down” technical debt. By attacking the problem this way, they make relatively small investments of time at the beginning to avoid the big timer-wasters later on.
- Collaborative nature of an Agile development team means that each and every member of the team is learning from his or her peers continuously, then they gradually become more and more capable with the project.
- Improving in process 
- At the end of each iteration, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The team derive a greater value and step by step polish themselves.
- They will very quickly refine their processes. Ineffective practices will be replaced with better ones, effective practices will be strengthened, and problems will be solved.
- Good quality software [3+4+9]
- Fitness for Purpose. The regular and continuous interaction between the customer and the developers assures that the product as built does what the customer needs for it to do. As long as the customer is effectively participating in the team, the developers will produce the right product!
- Fitness for Use. Again, the regular and continuous interaction between the customer and the developers assures the usability of the product as well. In addition, Agile projects assure usability by releasing the product into actual use as early and as often as possible during the project. Nothing confirms usability better than the actual users trying it out!
- Lack of Defects. The strong technical focus results in much better testing on an Agile project than in most other methods. As mentioned above, Agile developers take responsibility for the quality of the code they write. In addition to producing cleaner code, it means that if there are testing specialists on the project, they will start their testing with better software, which always results in more effective testing and a better resulting product!
- Reliability, Maintainability, etc. Again, the strong technical focus results in a technically superior product. In addition to the focus on testing and refactoring, some Agile teams use practices like coding standards, peer reviews, and pair programming to assure that the code they produce is technically solid.
- Improving in estimation [3+12]
- Because of the short feedback loops in an Agile project, developers can begin to learn about their estimating errors and become better at this crucial task.
- On time and on budget [8+10]
- The Agile methods all make the assumption that the project timeline is inviolable. In addition, they assume that the main driver of budget is people’s time, so the project time-box implies a fixed budget as well. Therefore, the team will always deliver on time and on budget.
- Early warning of problems [3+7+12]
- Agility doesn’t guarantee success. But failure is clear much sooner that with other approaches. Again, it is the iterative development pattern that provides this warning.
- After a few weeks, the first iteration is complete, and they deliver software. If it is significantly less than anticipated, an early flicker of red begins to show. After a second iteration delivers less than promised, the red light is clearly visible. If they continue for a third iteration and again deliver under plan, the red light is flashing and the siren is blaring.
- Meaningful milestones [3+7+8]
- Consider the types of milestones traditional projects rely upon: Requirements sign-off, Critical design review, Code complete, Testing complete, Customer acceptance, etc. Most of these milestones only have meaning to people who understand the software development process.
- Contrast that with the milestones on Agile projects: Customer Acceptance and only Customer Acceptance. At the end of each iteration of work, the project produces actual working software that the customer can evaluate and either accept or not.
- Management visibility [8+10]
- Manager will be able to see:
- The project’s roadmap and what it means
- Changes to that roadmap and their implications
- Early indications of customer satisfaction
- Early warning of problems
- Impact of changing the project’s budget or schedule
4. Disadvantages of Agile Methodologies
So far, we have had a look at the pros of Agile Development. However, everything has its all weaknesses, and Agile is not different.
- Active user involvement and close collaborator 
- Although these requirements are critical success factors for any project, it depends on having a customer who is willing and able to spend time with the development team and who can represent all system stakeholders. In many cases, customer representatives have other demands on their time and cannot play a full part in the software development. Where there are external stakeholders, such as regulators, it is difficult to represent their views to the agile team.
- Requirements emerge and evolve 
- This creates the very meaning of agile – flexibility. Flexibility to change course as needed and to ensure delivery of the right product. This leads to potential for scope creep, which we all know can create the risk of ever-lasting projects.
- Additionally, there is much less predictability, at the start of the project and during, about what the project is actually going to deliver, especially for large ones.
- Even though the Agile Manifesto take the value of “Customer Collaboration over Contract Negotiation”, a contract is needed in any case. This disadvantage can also 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.
- Moreover, prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders. Typically, each stakeholder gives different priorities to different changes.
- Testing is integrated throughout the life cycle 
- This does have the effect of reducing some very significant risks, that can cause many projects to fail. However, it implies that testers are needed throughout the project and this effectively increases the cost of resources on the project.
- Incremental delivery and Agile requirements are barely sufficient [3+10]
- This mean less information available to new starters in the team about features and how they should work.
- Moreover, rapid iterations and short-term planning for development does not always fit in with the longer-term planning cycles of business planning and marketing. Marketing managers may need to know what product features several months in advance to prepare an effective marketing campaign.
- Harmony of the development team [5+9+11]
- Individual team members may not have suitable personalities for the intense involvement that is typical of agile methods, and therefore may not interact well with other team members.
- 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.
- Clearly, as it requires a close collaboration, face-to-face conversation between each member of the team, it is not suitable for non-local team due to different in time-zone.
- Frequently delivery [3+8+10]
- Agile can be intense for the team. 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.
- Under pressure from delivery schedules, team members may not have time to carry out desirable system simplifications.
5. When to use Agile Models
According to these advantages and disadvantages discussed above, we can have a better idea when and where to use Agile methodologies.
|Project Size and Complexity||Small – Medium||x||x|
|Medium – Large||x|
|Customer Availability||Available throughout the entire project||x|
|Cannot commit to intensive involvement||x|
|Level Integration with External Systems||Simple or not needed||x||x|
|Numerous, unknown, complex||x|
|Customer Tolerance for Scope and Cost Changes||Flexible in budget and schedule is possible and welcome||x|
|Budget and/or schedule is fixed or difficult to modify||x|
|Time to market||Rapid deployment needed, can have limited feature set||x|
|Full feature application must be delivered within a determined deadline||x|
6. Real-life examples
Agile methodologies have been adapted in many company. Nevertheless, not all of them become success. I am going to introduce two examples; one is Agile gone wrong and one is Agile done right.
Healthcare.gov: an example of software development gone wrong
After working for several years, it turns out that they only had six days of testing. That is a total disaster. The team just pushed it live and nobody fessed up until after it was live that nothing works; visitors quickly encountered numerous types of technical problems. 10 million of dollars have been wasted on something broken. Many people dug into the project and saw the real problems behind.
- Lack of coordination between the front end and back end. The front end was an Agile project and they actually completed it in a few months, but the problem is they missed the second Agile manifesto – “Working software”. So, the people on the front end did their piece, but they never had anythingthat worked.
- Weak leadership. There were 20-25 consultancies working on the project, but no one steering the ship.
- They project should have been launched on a state-by-state basis. This would have allowed success for the states that did work and allowed developers to work on the back end to fix the other states.
Spotify: an example of Agile done right
One of the most interesting stories was Spotify. They’re very interesting because they’ve done a very elegant Agile implementation.
- Employing Scrum. Going Agile allows Spotify to be faster, better, and cheaper than industry Goliaths like Google, Amazon, and Apple.
- Spotify ensures its Scrum masters are also experienced Agile coaches. Some of the leading trainers in the world have been brought into Spotify to fill that kind of Scrum master job.
- Excellent team coordination. Employing “squads” and “tribes,” Spotify makes sure its teams are continuously deploying software and sprinting.
- Systematic waste removal. Knowing when to cut off slow teams is crucial to elegant Agile.
There are many ways to develop software but Agile methodologies really accomplish a win-win solution for clients and providers. Software development is not going away and how companies approach this service is key to their success. Working with Agile Methodologies has its challenges yet in the end, both client and provider win. Understanding the advantages and disadvantages of Agile models, we can know when our company should implement and make success out of them.
Agile Manifesto authors. (2001). Manifesto for Agile. Retrieved from http://agilemanifesto.org
Alan S. Koch, G. K. (2011). 12 Advantages of Agile Software Development. Global Knowledge Training LLC. .
Dawson, C. (2015). Agile Methodology – Advantages and Disadvantages. Retrieved from http://www.nearshoreamericas.com/agile-methodology-advantages-disadvantages/
Pressman, R. S. (2010). Software Engineering: A Practioner’s Approach (7th Edition ed.). McGraw-Hill.
Sutherland, D. J. (2014). Two Examples of Agile Done Right and Agile Gone Wrong. Retrieved from http://labs.openviewpartners.com/agile-done-right-agile-gone-wrong/
Waters, K. (2007). Disadvantages of Agile Development. Retrieved from http://www.allaboutagile.com/disadvantages-of-agile-development/