Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

You Can't Buy Agile


Published on

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

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

You Can't Buy Agile

  1. 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
  2. 2. Agile is Broken.
  3. 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. 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. 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. 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. 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. 8. How did we get here?
  9. 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. 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. 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. 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. 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. 14. What Agile Should Be
  15. 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. 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. 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. 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. 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. 20. What can you do about it?
  21. 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. 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. 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. 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. 25. Seriously, Commit to the Fix This is the difference between going through the motions and actually being agile
  26. 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. 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. 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. 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. 30. References Dave Thomas (2014). Agile is Dead (Long Live Agility). William Caputo (2004). Why I don’t care what Gerold Keefer Thinks. Tim Ottinger (2013). Scrum Managers: are they they worst? worst.html Tim Ottinger (2014). Defending Scrum Against Stupid Arguments. against-stupid-arguments.html James Shore (2008). The Decline and Fall of Agile. Martin Fowler (2009). FlaccidScrum. James Shore (2009). Stumbling Through Mediocrity. David Ramel (2012). New Analyst Report Rips Agile: Says It’s ‘Designed To Sell Services,’ a ‘Developer Rebellion Against Unwanted Tasks’. Application Development Trends. Goodhart’s Law (n.d.). In Wikipedia. Retrieved June 10th, 2014, from Ben Linders (2014). Taking Back Agile. InfoQ.
  31. 31. Questions? Anecdotes? Complaints? Chad McCallum @ChadEmm