4.7 Summary – pros and cons of Agile

Figure 4.7: Strength, weaknesses, opportunities and threats (SWOT) analysis on Agile methodologies



  • Quickly adapts to changing business requirements and ever changing business priorities because of intensive communication and analysis on frequently delivered work packages

  • Time to market and costs can be easily controlled; sign-off date of a product can be flexible as each deliverable is working stand-alone

  • Risks arise in early phases, as even the first sprint is likely to include all project activities, including implementation. Impediments will surface early and can be solved more effectively


  • Business goals are clear from the beginning due to frequent communication

  • Team members understands business goals and can easily be motivated due to that fact (development is not a black box, goals are common)

  • Commitment increases motivation too


  • Customer must be involved and frequently communicate with the developer team; needs personnel and infrastructure to achieve that (results in costs)

  • As development is rapid, emphasis on testing is a must

  • Communication is the most effective in person – offshore development takes more time, cultural differences can further reduce effectiveness


  • Communication in mission critical developments: threats in security – low quality could also cause problems, misunderstanding of scope


More thoughts on the “dark side” of Agile:

  • Software development stays a complex process – cures the symptoms but not the problem itself

  • Velocity must be assessed: an average team has evolution states of “storming, norming and performing”. To get to know to the capabilities and motivation of the team, time should pass. While this time passes, some failures in deliveries, “failed sprints” are likely to happen, which reduces customer trust

  • Stakeholders expectations will still be high and should be managed by an account specialist

  • Specialization is increasing productivity, while Agile promotes generalists

    • Officially no business analysts role is present; misunderstandings are often amongst client and vendor

    • Every team member is responsible to deliver some stories (not mandatorily is implementing it but is responsible and accountable for it). Some engineers are not ready to be responsible for deliveries. Language barriers, lack of business analysis skills of team members, not effective communication can further increase the likelihood to wrongly implement stories