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.

PHP World DC 2015 - What Can Go Wrong with Agile Development and How to Fix It

733 views

Published on

A talk I gave at the 2015 PHPWorld Conference. PDF Version of the slides at www.matt-toigo.com/files/phpworld_2015_presentation.pdf

Agile and Scrum are often pitched together as the definitive silver bullet for eliminating pain from software development, but they include their own sets of problems that commonly drag down development teams. Whether an agile team is executing an internal project or doing work for a client, a very similar set of problems begins to afflict all the members of such teams, regardless of their roles. The common root causes of these problems can be quickly identified, and complementary solutions can be easily implemented to ensure a happy team that continues to deliver high-quality work.

Published in: Software
  • Be the first to comment

  • Be the first to like this

PHP World DC 2015 - What Can Go Wrong with Agile Development and How to Fix It

  1. 1. November 20th, 2015 PHPWorld 2015 875 N St NW, Suite 205/ 202 350 4600/ hugeinc.com
  2. 2. What Goes Wrong With Agile Huge November 20th, 2015
  3. 3. And How We Can Fix It
  4. 4. 1. Intro 2.Agile Dysfunction 3.The Problems 4.The Fixes 5. Improve Your Team Agenda
  5. 5. Before We Dive In
  6. 6. Who are you: Matt Toigo or just @toigo since too many guys born in the 80s are named Matt
  7. 7. I’ve worked at agencies, startups, and large product companies. You have opinions, like everybody else, but are they valid?
  8. 8. All the way from PHP4 ClassName() constructors to the current vibrant ecosystem that Composer has enabled. I’ve seen PHP and software development evolve for 15 years.
  9. 9. Agile + Scrum
  10. 10. Every consultant and their dog are now shouting about them.
  11. 11. More Buzzwords? I’m sick of hearing about them. Why Are They Popular? The past was far worse.
  12. 12. We’ve all been on a waterfailure project and promised ourselves… never again. Alright, Let’s Give Agile a Shot
  13. 13. The rest of this presentation assumes a basic familiarity with Agile + Scrum.
  14. 14. Because nobody wants to sit through another pretty presentation that ignores the difficulties of our jobs while telling us how to do them.
  15. 15. Two Kinds of Agile Teams
  16. 16. Fresh Coat of Agile Paint We have the ceremonies, use the terms, develop to 6 month old specs, and have 20 people on our Scrum team!
  17. 17. What more do you want?
  18. 18. We’ll build that feature in our next 2 month sprint.
  19. 19. I’m not going to talk about fixing these issues.
  20. 20. Solid Agile Team Teams are autonomous, technical investment in Agile, supportive organization, and focused on constant improvement.
  21. 21. It’s all going to be rainbows and sunshine and everything will be easy and perfect!
  22. 22. NOPE
  23. 23. What Goes Wrong
  24. 24. Ticket Quality
  25. 25. The root of most Agile dysfunction and the source of pain for EVERYONE on a team. If you listen to only one part of this presentation
  26. 26. Downstream effects: 1. Bad Estimates 2. UnstableVelocity 3. Slower Work 4. Missed Requirements 5. Terrible for Testers 6. Stakeholders Don’t SeeValue
  27. 27. Write With Specificity
  28. 28. Take the time to write great user stories that anyone can quickly understand.
  29. 29. Also add the details that developers need.
  30. 30. Give everyone on your team the chance to punch holes in them.
  31. 31. Hidden Complexity
  32. 32. Now we think it’s more like a week… We said this was going to take a day.
  33. 33. There is only one cause for this.
  34. 34. Work was started before a problem was fully understood.
  35. 35. Prepare with Spikes
  36. 36. Pause before you dive into coding to make sure you have every detail you need. Let’s just start the work!
  37. 37. Clarify: 1. Product / UX / Design 2. Technical Architecture 3. Sequencing 4. How Will We Test 5. Organizational Limitations
  38. 38. Write down every detail so someone can refer back to everything that was learned. Take as long as you need to get all the answers.
  39. 39. Never Removing Work
  40. 40. Then realized we were totally unprepared. We committed to finishing this feature this sprint
  41. 41. It was in our sprint commitment though so we HAVE TO FINISH IT.
  42. 42. We’ll be making uneducated choices and possibly do shoddy work. Let’s just get it done!
  43. 43. Remove the Work
  44. 44. Don’t let it drag down everyone on the team for the remainder of the sprint. Acknowledge you made a mistake starting the work.
  45. 45. Remove the problem work so you can focus on work that is ready.
  46. 46. You probably aren’t being good enough about policing Definition of Ready. Discuss what went wrong in a retro.
  47. 47. Task Level Planning Only
  48. 48. The best way to have a productive heads down team. Punch lists of clearly defined work
  49. 49. You can miss the big items though.
  50. 50. No where for someone to understand how a system works or review it. Details are spread out in different tickets.
  51. 51. Problems: 1. Features Don’t Fit Together 2. Inconsistent Coding Patterns 3. Architecture is Short Sighted 4. Team Output is Unknown
  52. 52. Plan at Higher Level
  53. 53. Sprint forecast to stakeholders.
  54. 54. Make sure your entire team understands the product vision a few months out at all times.
  55. 55. Use a wiki to define technical architecture and relate it to production functionality.
  56. 56. Work Not Being Truly Ready
  57. 57. Testing it is taking forever though. Development on this story went great!
  58. 58. Developers did their part, why can’t we Ship It!
  59. 59. Ready Means Ready to Test
  60. 60. Don’t just ask if a story is ready for development.
  61. 61. Ask if we can quickly nail the testing or are we going to run into major blockers.
  62. 62. Ask yourselves: 1. Is There a Test Plan 2. Do We Have to Modify Data to Test 3. Are Physical Devices Available 4. Do We Need Another Team to Help
  63. 63. The QA members of your team will love you for this.
  64. 64. Tickets Replacing Communication
  65. 65. All hail the mighty sprint board and tickets are the source of truth!
  66. 66. I assigned that JIRA ticket to you, why would I need to talk to you about it?
  67. 67. Remote teams can be especially bad about this.
  68. 68. Talking > Tickets
  69. 69. Take the time to explain complex issues to teammates.
  70. 70. ON THE PHONE ORVIDEO CHAT
  71. 71. Assigning a bug without an explanation can feel like blaming someone
  72. 72. Ballooning Tickets
  73. 73. But let’s just add one more little thing… The work in this user story looks great.
  74. 74. Scope creep leading to revolving door tickets.
  75. 75. Be Strict About Acceptance Criteria
  76. 76. Let your team close out work to maintain momentum.
  77. 77. Tickets are cheap so make another one the right way.
  78. 78. Let’s talk to our Product Owner and address it in backlog grooming. That’s a really good idea!
  79. 79. How Did You Figure These Out?
  80. 80. A year’s worth of detailed project retro notes.
  81. 81. A fantastic team who was brutally honest in retrospective meetings while still always being respectful.
  82. 82. Specific examples are easier to fix rather than general griping. Take detailed notes during a sprint.
  83. 83. It’s easy to get the details wrong when you’re frustrated.
  84. 84. Everyone on your team MUST have the attitude that they still have a lot to learn about how to build great software.
  85. 85. Constant Introspection
  86. 86. November 20th, 2015 PHP World 2015 875 N St NW, Suite 205 / 202 350 4600 / hugeinc.com

×