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.

1. November 20th, 2015
PHPWorld 2015
875 N St NW, Suite 205/ 202 350 4600/ hugeinc.com

2. What Goes Wrong
With Agile
Huge
November 20th, 2015

3. And How We
Can Fix It

4. 1. Intro 2.Agile Dysfunction 3.The Problems
4.The Fixes 5. Improve Your Team
Agenda

5. Before We Dive
In

6. Who are you:
Matt Toigo or just @toigo since
too many guys born in the 80s
are named Matt

7. I’ve worked at agencies, startups,
and large product companies.
You have opinions, like everybody else, but are they valid?

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. Agile + Scrum

10. Every consultant and their dog are
now shouting about them.

11. More Buzzwords?
I’m sick of hearing about them.
Why Are They Popular?
The past was far worse.

12. We’ve all been on a waterfailure
project and promised ourselves…
never again.
Alright, Let’s Give Agile a Shot

13. The rest of this presentation assumes
a basic familiarity with Agile +
Scrum.

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. Two Kinds of
Agile Teams

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. What more do you want?

18. We’ll build that feature in our next 2
month sprint.

19. I’m not going to talk about fixing
these issues.

20. Solid Agile Team
Teams are autonomous, technical
investment in Agile, supportive
organization, and focused on
constant improvement.

21. It’s all going to be rainbows and
sunshine and everything will be
easy and perfect!

22. NOPE

23. What Goes
Wrong

24. Ticket Quality

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. Downstream effects:
1. Bad Estimates
2. UnstableVelocity
3. Slower Work
4. Missed Requirements
5. Terrible for Testers
6. Stakeholders Don’t SeeValue

27. Write With
Specificity

28. Take the time to write great user
stories that anyone can quickly
understand.

29. Also add the details that developers
need.

30. Give everyone on your team the
chance to punch holes in them.

31. Hidden
Complexity

32. Now we think it’s more like a week…
We said this was going to take a day.

33. There is only one cause for this.

34. Work was started before a problem
was fully understood.

35. Prepare with
Spikes

36. Pause before you dive into coding
to make sure you have every detail
you need.
Let’s just start the work!

37. Clarify:
1. Product / UX / Design
2. Technical Architecture
3. Sequencing
4. How Will We Test
5. Organizational Limitations

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. Never Removing
Work

40. Then realized we were totally
unprepared.
We committed to finishing this feature this sprint

41. It was in our sprint commitment
though so we HAVE TO FINISH IT.

42. We’ll be making uneducated
choices and possibly do shoddy
work.
Let’s just get it done!

43. Remove the Work

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. Remove the problem work so you
can focus on work that is ready.

46. You probably aren’t being good
enough about policing Definition of
Ready.
Discuss what went wrong in a retro.

47. Task Level
Planning Only

48. The best way to have a productive
heads down team.
Punch lists of clearly defined work

49. You can miss the big items though.

50. No where for someone to
understand how a system works or
review it.
Details are spread out in different tickets.

51. Problems:
1. Features Don’t Fit Together
2. Inconsistent Coding Patterns
3. Architecture is Short Sighted
4. Team Output is Unknown

52. Plan at Higher
Level

53. Sprint forecast to stakeholders.

54. Make sure your entire team
understands the product vision a
few months out at all times.

55. Use a wiki to define technical
architecture and relate it to
production functionality.

56. Work Not Being
Truly Ready

57. Testing it is taking forever though.
Development on this story went great!

58. Developers did their part, why can’t
we Ship It!

59. Ready Means
Ready to Test

60. Don’t just ask if a story is ready for
development.

61. Ask if we can quickly nail the testing
or are we going to run into major
blockers.

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. The QA members of your team will
love you for this.

64. Tickets
Replacing
Communication

65. All hail the mighty sprint board and
tickets are the source of truth!

66. I assigned that JIRA ticket to you,
why would I need to talk to you
about it?

67. Remote teams can be especially
bad about this.

68. Talking > Tickets

69. Take the time to explain complex
issues to teammates.

70. ON THE PHONE ORVIDEO CHAT

71. Assigning a bug without an
explanation can feel like blaming
someone

73. Ballooning
Tickets

74. But let’s just add one more little
thing…
The work in this user story looks great.

75. Scope creep leading to revolving
door tickets.

76. Be Strict About
Acceptance
Criteria

77. Let your team close out work to
maintain momentum.

78. Tickets are cheap so make another
one the right way.

79. Let’s talk to our Product Owner and
address it in backlog grooming.
That’s a really good idea!

80. How Did You
Figure These
Out?

81. A year’s worth of detailed project
retro notes.

82. A fantastic team who was brutally
honest in retrospective meetings
while still always being respectful.

83. Specific examples are easier to fix
rather than general griping.
Take detailed notes during a sprint.

84. It’s easy to get the details wrong
when you’re frustrated.

85. Everyone on your team MUST have the
attitude that they still have a lot to
learn about how to build great
software.

86. Constant
Introspection

87. November 20th, 2015
PHP World 2015
875 N St NW, Suite 205 / 202 350 4600 / hugeinc.com