Download as PDF, PPTX
Uploaded byTom Stiehm
Agile Software Development Antipatterns and how to avoid them
The document discusses various antipatterns in agile software development that can create long-term issues despite providing short-term solutions. It outlines specific antipatterns such as inefficient meetings and overlooking technical excellence, along with their symptoms and recommended practices to avoid them. The author emphasizes the importance of addressing issues like work-in-progress limits, gathering user feedback, and maintaining consistent team composition to foster a healthier development environment.
Agile Software Development Antipatterns and how to avoid them
- 2. Tom Stiehm Agile SoftwareDevelopment Antipatterns and How to Avoid Them
- 3. About Tom Stiehm •CTO of Coveros, Inc. • Agile Practitioner since 2002 • Worked in Application Security since 2004 • DevOps Practitioner since 2012 • Works at the intersection of Agile, DevOps, and Application Security
- 4. What is anAntipattern? An antipattern is a way to solve a problem that works in the moment but creates long-term problems.
- 5. What is sobad about Antipatterns? The insidious thing about antipatterns isn’t that they fail outright but that they work in the short-term while causing long-term failure and pain.
- 6. So why dopeople use Antipatterns? An antipattern can solve your current problem Like technical debt, you promise to fix the long-term problem, just as soon as you can Or not because you will not be affected by them
- 7. Antipattern Format Name ofthe antipattern Symptoms & Consequences What to do instead
- 8. Expecting change withoutchanging incentives Not changing what gets you promoted Not changing what gets you a raise or bonus Not changing what gets you fired Incentives inform culture, culture is how people behave Change your incentive system to reflect what you want
- 9. Inefficient Meetings Too manymeetings with too many people Hour long daily stand ups No agenda to meetings Stick to process defined meetings only Stick to the meeting agenda, offline anything else All other communications default to email
- 10. High Work inProgress The work queue has too many active items The high work in progress is just accepted The team can’t make acceptable progress on work Limit the work in progress to the point where people can make progress. Most developers can handle 1 or 2 items
- 11. Unrefined Backlog The ProductBacklog Items only contain high level feature descriptions No refinement or no work breakdown happen The team must guess at the detailed requirements Create a definition of ready that must be met before work can begin
- 12. Constantly changing teamcomposition Team composition is changed on a regular basis People are viewed as interchangeable parts Sometimes changing the team during the sprint Keep teams together and bring the work to them
- 13. Ignoring Technical Excellenceand Practices The team is viewed as a feature factory All efforts to refactor or improve are denied Over time new feature creation slows down Include refactoring in estimates for work Make new feature creation contingent on the technical improvement of the software
- 14. Not having retrospectives NoValue, No Retro Nothing Changes Retro is only a complaint session Try different formats Action Items decided by team Mix it up with team building No value Lot of fun Great Value Great time No value Boring Great value Boring
- 15. Continuous Build (CB) Usinga Continuous Integration (CI) server without tests or static analysis No CI feedback on build health No feedback in integration health Put the confidence back in CI with tests and analysis, start test automation from the beginning
- 16. Turning Quality Gatesoff to get past a hurdle Special process for creating a build skipping feedback No test automation or quality checks means no confidence in the software Test automation and quality checks are the way to build confidence in the software Get and use feedback on all builds
- 17. No production-like testenvironment Not testing in an environment configured like production You are putting unproven software in production, it will fail at some point Create prod-like test environments Use canary releases to test in production Don’t test something first in production
- 18. Multiple Sources ofTruth More than one source is needed to find out what the current state of a project or product Multiple sources need to be queried to get latest data Multiple sources need to be updated and kept in sync Have one source of truth with dashboards getting data from that source for reporting
- 19. Management Metrics DrivenDevelopment Management dictates all the metrics used to evaluate progress Example: velocity is used to evaluate teams The metrics drive unintended consequences Focus management on business outcomes rather than team metrics
- 20. Chasing latest softwaretrends The team is focused on how to use the latest languages || techniques || frameworks || technology The codebase is littered with half developed remnants of former latest things Focus on using the simplest tools and processes to deliver value
- 21. Performance & securitytesting only at the end Performance and security testing are only done at release Defects are negotiated into production Shift Left – add perf and sec indicators in the pipeline Triage & fix perf and sec issues as they come up
- 22. Always sprinting, notime to regroup The only activity the team engages in is creating new functionality as fast as they can No refactoring, No fixing Sec or Perf issues No training, No team building Slow down to speed up, take the time to get better and fix issues, take time off from sprinting to let them team recover
- 23. Never asking theusers for feedback Ignoring the most valuable feedback The voice of the user is undervalued On a regular basis ask your users for feedback Watch them use the software