Editing Agile software development (section)

===Common agile software development pitfalls===
Organizations and teams implementing agile software development often face difficulties transitioning from more traditional methods such as [[waterfall development]], such as teams having an agile process forced on them.<ref name="The Art of Agile Development">{{harvnb|Shore|Warden|2008|p=47}}</ref> These are often termed ''agile anti-patterns'' or more commonly ''agile smells''. Below are some common examples:

====Lack of overall product design====
A goal of agile software development is to focus more on producing working software and less on documentation. This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation. However, this does not justify completely doing without any analysis or design at all. Failure to pay attention to design can cause a team to proceed rapidly at first, but then to require significant rework as they attempt to scale up the system. One of the key features of agile software development is that it is iterative. When done correctly, agile software development allows the design to emerge as the system is developed and helps the team discover commonalities  and opportunities for re-use.<ref>{{cite book|last1=Beck|first1=Kent|title=Extreme Programming Explained|date=2000|publisher=Addison-Wesley|isbn=978-0201616415|pages=[https://archive.org/details/extremeprogrammi00beck/page/48 48–49]|url=https://archive.org/details/extremeprogrammi00beck/page/48}}</ref>

====Adding stories to an iteration in progress====
In agile software development, ''stories'' (similar to [[use case]] descriptions) are typically used to define requirements and an ''iteration'' is a short period of time during which the team commits to specific goals.<ref>{{cite web|last1=Rouse|first1=Margaret|title=Sprint (software development) definition|url=http://searchsoftwarequality.techtarget.com/definition/Scrum-sprint|website=searchsoftwarequality.techtarget.com|access-date=2 October 2015}}</ref> Adding stories to an iteration in progress is detrimental to a good flow of work. These should be added to the product backlog and prioritized for a subsequent iteration or in rare cases the iteration could be cancelled.<ref name="axisagile.com.au">{{cite web|last1=Goldstein|first1=Ilan|title=Sprint issues – when sprints turn into crawls|url=http://www.axisagile.com.au/blog/planning-and-metrics/sprint-issues-when-sprints-turn-into-crawls/|website=www.axisagile.com.au|access-date=2014-06-08|date=11 October 2011}}</ref>

This does not mean that a story cannot expand. Teams must deal with new information, which may produce additional tasks for a story. If the new information prevents the story from being completed during the iteration, then it should be carried over to a subsequent iteration. However, it should be prioritized against all remaining stories, as the new information may have changed the story's original priority.

====Lack of sponsor support====
Agile software development is often implemented as a grassroots effort in organizations by software development teams trying to optimize their development processes and ensure consistency in the software development life cycle. By not having sponsor support, teams may face difficulties and resistance from business partners, other development teams and management. Additionally, they may suffer without appropriate funding and resources.<ref>{{cite web|url=http://agile-only.com/master-thesis/project-mgmt/pr-and-rd|title=Project Roles and Responsibility Distribution|website=agile-only.com|access-date=2014-06-15}}</ref> This increases the likelihood of failure.<ref>{{cite web|last1=Bourne|first1=Lynda|title=What Does a Project Sponsor Really Do?|url=http://blogs.pmi.org/blog/voices_on_project_management/2012/04/what-does-a-project-sponsor-re.html|website=blogs.pmi.org|access-date=2014-06-08|archive-date=7 June 2014|archive-url=https://web.archive.org/web/20140607221010/http://blogs.pmi.org/blog/voices_on_project_management/2012/04/what-does-a-project-sponsor-re.html|url-status=dead}}</ref>

====Insufficient training====
A survey performed by VersionOne found respondents cited insufficient training as the most significant cause for failed agile implementations<ref>{{cite web|url=http://www.versionone.com/state_of_agile_development_survey/09/page5.asp|title=9th State of Agile Report|website=Stage of Agile Survey|publisher=VersionOne|access-date=2014-06-08|archive-url=https://web.archive.org/web/20150112225122/http://www.versionone.com/state_of_agile_development_survey/09/page5.asp|archive-date=12 January 2015|url-status=dead}}</ref> Teams have fallen into the trap of assuming the reduced processes of agile software development compared to other approaches such as waterfall means that there are no actual rules for agile software development. {{Citation needed|date=May 2018}}

====Product owner role is not properly filled====
The [[product owner]] is responsible for representing the business in the development activity and is often the most demanding role.<ref>{{cite book|author1=Sims, Chris |author2=Johnson, Hillary Louise |title=The Elements of Scrum|date=2011-02-15|publisher=Dymaxicon|page=73|edition=Kindle}}</ref>

A common mistake is to fill the product owner role with someone from the development team. This requires the team to make its own decisions on prioritization without real feedback from the business. They try to solve business issues internally or delay work as they reach outside the team for direction. This often leads to distraction and a breakdown in collaboration.<ref>{{cite web|last1=Rothman|first1=Johanna Rothman|title=When You Have No Product Owner at All|url=http://www.jrothman.com/blog/mpd/2011/08/when-you-have-no-product-owner-at-all.html|website=www.jrothman.com|access-date=2014-06-08|date=25 August 2011}}</ref>

====Teams are not focused====
Agile software development requires teams to meet product commitments, which means they should focus on work for only that product. However, team members who appear to have spare capacity are often expected to take on other work, which makes it difficult for them to help complete the work to which their team had committed.<ref>{{cite web|last1=Fox|first1=Alyssa|title=Working on Multiple Agile Teams|url=http://techwhirl.com/working-multiple-agile-teams/|website=techwhirl.com/|access-date=2014-06-14|date=8 April 2014}}</ref>

====Excessive preparation/planning====
Teams may fall into the trap of spending too much time preparing or planning. This is a common trap for teams less familiar with agile software development where the teams feel obliged to have a complete understanding and specification of all stories. Teams should be prepared to move forward with only those stories in which they have confidence, then during the iteration continue to discover and prepare work for subsequent iterations (often referred to as [[refinement (computing)|backlog refinement]] or grooming).

====Problem-solving in the daily standup====
A daily standup should be a focused, timely meeting where all team members disseminate information. If problem-solving occurs, it often can involve only certain team members and potentially is not the best use of the entire team's time. If during the daily standup the team starts diving into problem-solving, it should be set aside until a sub-team can discuss, usually immediately after the standup completes.<ref>{{cite web|title=Daily Scrum Meeting|url=http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum|website=www.mountaingoatsoftware.com|access-date=2014-06-14}}</ref>

====Assigning tasks====
One of the intended benefits of agile software development is to empower the team to make choices, as they are closest to the problem. Additionally, they should make choices as close to implementation as possible, to use more timely information in the decision. If team members are assigned tasks by others or too early in the process, the benefits of localized and timely decision making can be lost.<ref name="Effective Sprint Planning">{{cite web|last1=May |first1=Robert |title=Effective Sprint Planning |url=http://www.agileexecutives.org/Blogs/tabid/66/EntryId/18/Effective-Sprint-Planning.aspx |website=www.agileexecutives.org |access-date=2014-06-14 |url-status=dead |archive-url=https://web.archive.org/web/20140628102810/http://www.agileexecutives.org/Blogs/tabid/66/EntryId/18/Effective-Sprint-Planning.aspx |archive-date=28 June 2014 }}</ref>

Being assigned work also constrains team members into certain roles (for example, team member A must always do the database work), which limits opportunities for cross-training.<ref name="Effective Sprint Planning"/> Team members themselves can choose to take on tasks that stretch their abilities and provide cross-training opportunities.

====Scrum master as a contributor====
In the Scrum framework, which claims to be consistent with agile values and principles, the ''scrum master'' role is accountable for ensuring the scrum process is followed and for coaching the scrum team through that process. A common pitfall is for a scrum master to act as a contributor. While not prohibited by the Scrum framework, the scrum master needs to ensure they have the capacity to act in the role of scrum master first and not work on development tasks. A scrum master's role is to facilitate the process rather than create the product.<ref name="agileconnection.com">{{cite web|last1=Berczuk|first1=Steve|title=Mission Possible: ScrumMaster and Technical Contributor|url=http://www.agileconnection.com/article/mission-possible-scrummaster-and-technical-contributor?page=0%2C1|website=www.agileconnection.com|access-date=2014-06-14}}</ref>

Having the scrum master also multitasking may result in too many context switches to be productive. Additionally, as a scrum master is responsible for ensuring roadblocks are removed so that the team can make forward progress, the benefit gained by individual tasks moving forward may not outweigh roadblocks that are deferred due to lack of capacity.<ref>{{cite web | url=https://aristeksystems.com/blog/how-not-to-burn-your-budget-with-agile-scrum/| title=How to Implement Agile Scrum | accessdate=2022-01-04}}</ref>

====Lack of test automation====
{{Further|Test automation}}
Due to the iterative nature of agile development, multiple rounds of testing are often needed. Automated testing helps reduce the impact of repeated unit, integration, and regression tests and frees developers and testers to focus on higher value work.<ref>{{cite web|last1=Namta|first1=Rajneesh|title=Thoughts on Test Automation in Agile|url=http://www.infoq.com/articles/thoughts-on-test-automation-in-agile|website=www.infoq.com|access-date=2014-06-14}}</ref>

Test automation also supports continued [[refactoring]] required by iterative software development. Allowing a developer to quickly run tests to confirm refactoring has not modified the functionality of the application may reduce the workload and increase confidence that cleanup efforts have not introduced new defects.

====Allowing technical debt to build up====
{{Further|Technical debt}}
Focusing on delivering new functionality may result in increased [[technical debt]]. The team must allow themselves time for defect remediation and refactoring. Technical debt hinders planning abilities by increasing the amount of unscheduled work as production defects distract the team from further progress.<ref name="Technical Debt + Red October">{{cite web|last1 = Band|first1 = Zvi|title = Technical Debt + Red October| work=Zvi Band |url = http://zviband.com/posts/technical-debt-red-october/|access-date = 8 June 2014|date = 22 March 2014}}</ref>

As the system evolves it is important to [[Code refactoring|refactor]].<ref>{{cite web|last1=Shore|first1=James|title=The Art of Agile Development: Refactoring|url=http://www.jamesshore.com/Agile-Book/refactoring.html|website=www.jamesshore.com|access-date=2014-06-14}}</ref> Over time the lack of constant maintenance causes increasing defects and development costs.<ref name="Technical Debt + Red October"/>

====Attempting to take on too much in an iteration====
A common misconception is that agile software development allows continuous change, however an iteration backlog is an agreement of what work can be completed during an iteration.<ref>{{cite web|title=Step 4: Sprint Planning (Tasks)|url=http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-4-sprint-planning-tasks/|website=www.allaboutagile.com|access-date=2014-06-14|archive-url=https://web.archive.org/web/20140629145319/http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-4-sprint-planning-tasks/|archive-date=29 June 2014|url-status=dead}}</ref> Having too much [[Work in process|work-in-progress (WIP)]] results in inefficiencies such as [[Human multitasking|context-switching]] and queueing.<ref>{{cite web|url=http://leankit.com/blog/2014/03/limiting-work-in-progress/|title=Why Limiting Your Work-in-Progress Matters|website=leankit.com|last1=George|first1=Claire|date=3 March 2014|access-date=2014-06-14}}</ref> The team must avoid feeling pressured into taking on additional work.<ref>{{cite web|url=http://www.mountaingoatsoftware.com/agile/scrum/sprint-planning-meeting/|website=www.mountaingoatsoftware.com|access-date=2014-06-14|title=Sprint Planning Meeting}}</ref>

====Fixed time, resources, scope, and quality====
Agile software development fixes time (iteration duration), quality, and ideally resources in advance (though maintaining fixed resources may be difficult if developers are often pulled away from tasks to handle production incidents), while the [[Scope (project management)|scope]] remains variable. The customer or product owner often pushes for a fixed scope for an iteration. However, teams should be reluctant to commit to the locked time, resources and scope (commonly known as the [[project management triangle]]). Efforts to add scope to the fixed time and resources of agile software development may result in decreased quality.<ref name="adeptechllc.com">{{cite web|last1=McMillan |first1=Keith |title=Time, Resources, Scope... and Quality. |url=http://www.adeptechllc.com/2010/05/13/time-resources-scope-and-quality/ |website=www.adeptechllc.com |date=13 May 2010 |access-date=2014-06-15 }}</ref>

====Developer burnout====
Due to the focused pace and continuous nature of agile practices, there is a heightened risk of burnout among members of the delivery team.<ref>{{cite journal|title=Current study on limitations of Agile|journal=Procedia Computer Science|volume=78|pages=291–297|date=January 2016|doi=10.1016/j.procs.2016.02.056|doi-access=free}}</ref>