A brief review of agile software development gone wrong, some of the common causes of failure, and things we can do to overcome these obstacles

1. You Can’t Buy Agile
what’s broken, why we broke it, and how to fix it
Chad McCallum
Senior Software Developer
iQmetrix Software
@ChadEmm
www.rtigger.com

2. Agile is Broken.

3. Complacent Scrum
• You meet every morning and chat about your work day
• Maybe every few weeks you meet as a team and do the same thing
• But nothing ever changes
• Best case scenario, it’s a fun way to kill 15 minutes while you sip
coffee
• Worst case scenario, it’s a boring way to kill 45 minutes while you
really have to go pee

4. Waterfall Agile
• Your manager finally approved your change request form to try agile!
• That was 3 months ago
• PMs, BAs, and management are still discussing how it’s going to work
• Best case scenario: You can convince your manager you need a 3rd
monitor cause it’s more agile
• Worst case scenario: You end up having to do compliance scrum while
still expected to fill out your TPS reports

5. Thou Shalt Agile
• Jeff’s new agile Ruby on Rails team is doing great – churning out
projects like butter
• Now management wants everyone to be like Jeff’s team!
• Your team is expected to copy-paste Jeff’s approach, without
spending any time on change management
• Best case scenario: you also get a beer tap and xbox one installed on
your side of the office
• Worst case scenario: You arrive on Monday to find your desktop
attached to two keyboards and a shared monitor

6. Agile To The Rescue
• Your project contract ran out a year ago and your team still hasn’t
delivered on the (constantly changing) requirements
• You end up with a new manager (again) – but this one’s from an Agile
team.
• Now you’re “agile”, and that will definitely save the project. Here’s a
new deadline.
• Best case scenario: you can drag that government sharepoint contract
out another year
• Worst case scenario: you have to drag that government sharepoint
contract out another year

7. Terminal Velocity
• The “agile team” starts reporting their burn down charts and velocity
up the chain
• Now upper management wonders why your velocity is 17 and theirs
is 31
• Best case scenario: you convince the exec to equip everyone’s chairs
with jet packs (to increase your velocity)
• Worst case scenario: the exec convince you to equip everyone with
energy drinks and pizza and lock the doors (to increase your velocity)

8. How did we get here?

9. You Can’t Buy Agile
• Agile has been sold to organizations & teams
• Marketing and hype has created the image of a cure-all for teams and
projects
• Suddenly you need “agile” on your careers page to attract any talent
• Starting to leak into other industries

10. Religion of Agile
• Team members adopting agile because it’s the “cool new thing”
without fully understanding it
• They copy what another team or blog post is doing, put stickers on
their laptops, go to one conference, and then call themselves agile
• Worst of all, they show an initial period of improvement

11. Abuse of Measurement
• Stat-focused managers abuse terms like “velocity” and “burn down
chart” without actually realizing their purpose or benefit
• Teams are coerced into spending time creating reports and metrics to
prove they’re doing something (instead of actually doing something)
• Reports and metrics get compared in inappropriate ways
• Goodhart’s Law – When a measure becomes a target, it ceases to be a
good measure

12. Agile Confusion
• Voke Media survey of over 200 developers on an agile team
• 64% of survey participants found the transition to agile confusing,
hard, or slow
• 40% of participants did not identify a benefit to switching to agile
• 28% report success with agile

13. No One’s Asking the Hard Questions
• Why are you trying agile?
• What problem(s) are you trying to solve?
• Does agile address those problems?

14. What Agile Should Be

15. Agile Has Nothing to do with Your Success
• Teams, not processes, fail at delivering software
• A waterfall team with problems becomes an agile team with
problems
• Agile is meant to make good teams great by identifying areas of
improvement

16. Agile is your In-Laws
• They constantly point out your shortcomings
• Agile doesn’t fix issues, it helps identify them
• Older methodologies have such a long feedback loop that it’s too late
to fix anything that may show up
• Most agile methods are designed to surface issues early, as well as
provide multiple opportunities to address issues

17. Agile Culture
• Need a culture in your team and organization that supports
identifying, reporting, and fixing problems
• Without this support, you get compliance agile – going through the
motions without any actual change
• Requires buy in from the management / exec level

18. Agile has Nothing to do with Development
• Most agile methodologies have little to nothing to do with actual
software development
• They focus on project management
• You still need strong software engineering practices

19. Personal Practices
“Having conferences about agility is not too far removed from having
conferences about ballet dancing, and forming an industry group
around the four values always struck me as creating a trade union for
people who breathe.”
- Dave Thomas
If you and your team don’t agree with Agile, then don’t use Agile.

20. What can you do about it?

21. All For One
• The entire team should be buying into an approach
• If someone has a problem with it, they should speak up and provide a
solution
• “If you bring a dead cat, bring a shovel”

22. One For All
• Instil a sense of team accountability
• You’re not working because you get paid to, you’re working because
you’re contributing to a team of peers to accomplish a goal
• Share responsibility and authority for success

23. Create an Agile Slice
• Empower a slice of your organization to try new things, report what
works, and fix what doesn’t
• Without having to ask permission or micromanage
• All the way from exec to teammate
“[Agile] is entirely based on transparency, inspection, and adaptation”
- Tim Ottinger

24. Retrospect Like You Mean It
• Regularly set aside time as a group to identify things that went well,
things that sucked, and identify what to fix
• Every member of your team is capable of (and the most qualified to)
identify wasteful processes in their day-to-day jobs
• As a team, commit to fixing one or two things each iteration
• Commit to the fix

25. Seriously, Commit to the Fix
This is the difference between going through the motions and actually
being agile

26. Agile is Hard
“Being great requires making waves. It requires taking risks. And it
requires saying "no" to people who want to hear "yes.“ … [It requires]
people who aren't satisfied just fitting in. People who are willing to take
risks, rock the boat, and change their environment to maximize their
productivity, throughput, and value.”
- James Shore

27. Agile is Hard
“Summarizing I think most reactions are related that becoming agile
requires a culture change. But just that seems really hard and can
immediately feel overwhelming. Just adopting practices will give you
some results / improvements, but won’t make you more agile. Just
adopting practices without paying attention to the human dynamics
will easily get you into a mess.”
- Rudd Wijnands

28. Agile is Hard
“Learning [agile] requires engagement and pre-permission and
agreements to let people explore and grow (and sometimes purchase)
in ways that seem new and sometimes scary to all the layers and
departments in old-school organizations.”
- Tim Ottinger

29. Agile is Actually Easy :P
Agile really means nothing more than working as a group to produce
the best you can.
“Here is how to do something in an agile fashion:
1. Find out where you are
2. Take a small step towards your goal
3. Adjust your understanding based on what you learned
4. Repeat”
- Dave Thomas

30. References
Dave Thomas (2014). Agile is Dead (Long Live Agility). http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
William Caputo (2004). Why I don’t care what Gerold Keefer Thinks. http://www.williamcaputo.com/archives/000032.html
Tim Ottinger (2013). Scrum Managers: are they they worst? http://agileotter.blogspot.ca/2013/11/scrum-managers-are-they-
worst.html
Tim Ottinger (2014). Defending Scrum Against Stupid Arguments. http://agileotter.blogspot.ca/2014/05/defending-scrum-
against-stupid-arguments.html
James Shore (2008). The Decline and Fall of Agile. http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
Martin Fowler (2009). FlaccidScrum. http://martinfowler.com/bliki/FlaccidScrum.html
James Shore (2009). Stumbling Through Mediocrity. http://www.jamesshore.com/Blog/Stumbling-Through-Mediocrity.html
David Ramel (2012). New Analyst Report Rips Agile: Says It’s ‘Designed To Sell Services,’ a ‘Developer Rebellion Against
Unwanted Tasks’. Application Development Trends. http://adtmag.com/articles/2012/07/13/report-says-agile-a-scam.aspx
Goodhart’s Law (n.d.). In Wikipedia. Retrieved June 10th, 2014, from http://en.wikipedia.org/wiki/Goodhart%27s_law
Ben Linders (2014). Taking Back Agile. InfoQ. http://www.infoq.com/articles/taking-back-agile

31. Questions? Anecdotes? Complaints?
Chad McCallum
chadm@iqmetrix.com
@ChadEmm
www.rtigger.com