You Can't Buy Agile

  • Published on
    08-May-2015

  • View
    1.347

  • Download
    1

Embed Size (px)

DESCRIPTION

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

Transcript

<ul><li>1.You Cant Buy Agile whats broken, why we broke it, and how to fix it Chad McCallum Senior Software Developer iQmetrix Software @ChadEmm www.rtigger.com </li></ul> <p>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, its a fun way to kill 15 minutes while you sip coffee Worst case scenario, its 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 its going to work Best case scenario: You can convince your manager you need a 3rd monitor cause its 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 Jeffs new agile Ruby on Rails team is doing great churning out projects like butter Now management wants everyone to be like Jeffs team! Your team is expected to copy-paste Jeffs 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 hasnt delivered on the (constantly changing) requirements You end up with a new manager (again) but this ones from an Agile team. Now youre agile, and that will definitely save the project. Heres 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 everyones 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 Cant Buy Agile Agile has been sold to organizations &amp; 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 its 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 theyre doing something (instead of actually doing something) Reports and metrics get compared in inappropriate ways Goodharts 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 Ones 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 doesnt fix issues, it helps identify them Older methodologies have such a long feedback loop that its 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 dont agree with Agile, then dont 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 Youre not working because you get paid to, youre working because youre 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 doesnt 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 wont 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 dont 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 Its 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 Goodharts 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 </p>