Agile Software Development Antipatterns and how to avoid them

Software development is hard and poorly implemented or broken tools, techniques, and patterns just make it worse. Learn to spot software development anti-patterns and how to work your way back to a sane way of working.

Antipatterns can be hard to recognize and mitigate because they are solutions to problems. They can appear to solve the problem in the short run. The problem is that they create long-term consequences that are worse than the short-term problems you avoid by using them.

Continuous Build is an antipattern that I have often seen where a team will have a Continuous Integration (CI) in place but it only builds the code. No code integration tests are run and health metrics are collected. While this is better than not building automatically, it leaves a lot of health check information out. Without this information, you never gain the confidence that your build is healthy. The whole point of CI is the confidence that your build is healthy. You aren’t doing CI if you can’t get that confidence with test automation and code quality analysis.

Just like CI, other software development practices can be hard to understand, implement, and get right. Even with the best of intentions, we make mistakes or misinterpret the implementation of a technique. Learn how to spot common software development anti-patterns and how to correct them.

2. Tom Stiehm
Agile Software Development 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 an Antipattern?
An antipattern is a way to solve a problem that works
in the moment but creates long-term problems.

5. What is so bad 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 do people 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 of the antipattern
Symptoms & Consequences
What to do instead

8. Expecting change without changing 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 many meetings 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 in Progress
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 Product Backlog 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 team composition
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 Excellence and 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
No Value, 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)
Using a 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 Gates off 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 test environment
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 of Truth
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 Driven Development
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 software trends
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 & security testing 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, no time 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 the users 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