Making the Most of your Agile Process - DPC `14

Almost everyone in our industry has heard of agile development, scrum, and likely to some degree. Most teams I know follow some sort of scrum-like process: two week sprints, story points, estimation, etc. However, it is very easy to go through the motions of scrum & agile without really improving the process, and that was the struggle our different different development teams faced at DDM. However, over the last two years across our different teams we’ve discovered very key elements of scrum that are rarely talked about that make the biggest difference.

So in this talk we’ll assume you’ve heard of scrum, sprints, scrummasters, backlogs, and the general idea of scrum. In this talk, we’ll go through the key changes we made in our agile process across our different teams that really made the difference. We’ll show how we were able to change scrum from a set of meetings and to-do lists into an effective system that has double our teams’ output.

Transcript

1. Making The Most Of Your Agile Process Justin Carmony - Dutch PHP Conf`14 @JustinCarmony
2. • Director of Development
 @ Deseret Digital Media • Utah PHP Usergroup
 President • I Make (and Break)
 Web Stuff (~10 years) • @JustinCarmony
 justin@justincarmony.com Hi • Director of Development
 @ Deseret Digital Media • Utah PHP Usergroup
 President • I Make (and Break)
 Web Stuff (~10 years) • @JustinCarmony
 justin@justincarmony.com
3. This
 Presentation • Slides Posted Online • Feel free to ask on-topic question during presentation • Q&A Session At the End • Feel free to ask me any questions afterwards
4. • You’ve Heard of Agile • You’ve Know the Basic Structure of Scrum • You’ve tried to do Agile in some fashion with some team. Assumptions for this Presentation Planning! Estimation! 2 Week Sprint! Daily Standups! Review & Retrospectives
5. Let’s Take a Poll
6. I’m A Developer
7. Lets Get This Out of The Way
8. Agile Sucks!
9. Yes
10. Yes, It Can
11. Yes, It Can But It Doesn’t Have To!
12. Lets Talk About Why
13. ag·ile [aj-uhl, -ahyl] quick and well-coordinated in movement; lithe: an agile leap. active; lively: an agile person. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile. 1. 2. 3.
14. ag·ile [aj-uhl, -ahyl] quick and well-coordinated in movement; lithe: an agile leap. active; lively: an agile person. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile. 1. 2. 3. 4. A marketing word for any Development Tool, Training, or Processes recently released.
15. Terrible Word
18. Who uses Agile Processes?
19. We’re Agile!
20. What does Agile Mean?
22. Actually… Welll… Uhhh…. I guess… Hmm… Derp…
26. Story Time
28. Project Manager Work List Developers Tickets Guessing Hours Team Meeting
29. Project Manager Work List Developers Tickets Guessing Hours Team Meeting Product Owner + Scrum Master Backlog Scrum Team Stories Estimating Story Points Sprint Planning
33. It Was Frustrating
34. Why Agile?
35. Our Team is More Efficient! We Do Agile Because… We Make a Better Product! We Release On Schedule!
36. Our Team is More Efficient! We Do Agile Because… We Make a Better Product! We Release On Schedule!
37. Fundamentally Agile is About…
38. Better Decisions
39. Agile Is Not Just a Process
40. Agile is a Decision Making Framework
41. Quick Agile Test
42. Have You Changed How You Make Decisions?
43. • Have you changed how make decisions about: • What you work on “Today” • Features, Bugs, & Priorities • Releases & Deadlines • Planning for the Future Decision Making
44. Re-learning Agile
45. Reality In; Decisions Out R.I.D.O
46. Reality
47. Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Time Progress
48. Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Time Work Finished
49. Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Time Work Finished
50. Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Time Work Finished
52. Insanity!
53. Goal: Honest Assessment of Reality
54. What is Reality? Things we can Control Things we cannot Control The Past Deadlines Features Bugs Feature Scope Sick & Personal Leave Work Emergencies How Long Things Take ??? What To Code Etc, etc, etc What to Fix Actions for Right Now Re-evaluate Scope Etc, etc, etc Etc, etc, etc
55. Make Decisions that Manage Risk
56. Complexity Critical
57. Complexity Critical
58. Complexity Critical
59. Complexity Critical
60. Complexity Critical
61. Improving Parts of your Process
62. Team Roles
63. Project Manager Owns the Process Owns the Product Owns Development
64. Scrum Master Owns the Process Owns the Product Owns Development Product Owner Dev Lead
65. Share Common Goal Individual Responsibilities
66. Meetings
67. Keep Them Simple! Keep Them Short!
68. Review Retro Estimation Planning 2.5 Hours
69. Retrospectives
70. MOST IMPORTANT PART OF OUR PROCESS!
71. 1.What went well? 2.What do we want to Change? 3.How are we going to Change It? Retrospectives
72. Document It!
73. • Added 0 point option to Pivotal for stories that only need 0 • Way more consistent with morning standups • Gathered good feedback from stakeholders • Having a UI that we can demonstrate with helps communicate to stakeholders What Went Well
74. Disrupted several times by AdOps “Emergencies” that could have been avoided with early communication. What To Change & How Problem Solution Designate point person (product manager) for all requests to come through. Proactively coordinate with AdOps before Sprints start.
75. Pivotal & GitHub Notifications are being too noisy in the HipChat Room. What To Change & How Problem Solution Create new HipChat room for All Notifications and only post critical notifications in the main room.
76. With Remote Developers visit, we didn’t have enough on boarding work for new Junior Dev. What To Change & How Problem Solution Tag “easy” items regularly to have a clean backlog of on boarding tasks.
77. Several DN stories planned had CMS dependencies that weren’t finished What To Change & How Problem Solution Use “dependency” label in both DN & CMS backlogs Review CMS backlog before finalizing each sprint plan
78. • Added 0 point option to Pivotal for stories that only need 0 • Way more consistent with morning standups • Gathered good feedback from stakeholders • Having a UI that we can demonstrate with helps communicate to stakeholders How to Make the Change
79. Review Your Retrospective Items!
80. • Safe Communication Environment • Focus on the Future • Look for Small, Manageable Changes • Focus on You before Others - “What can I improve” Making Retrospectives Effective
81. Estimation
82. It’s Not Precise! It’s Not Accurate!
88. Releasing
89. Complexity Critical
90. Complexity Critical
92. • Don’t Over Analyze for perfect Precision! • Focus on Identifying Complexities. • Opportunity for Product Owners / Stake Holders & Devs to clear up Ambiguity. • You will get better over time. There will always be stories that will be greatly over or under estimated. Estimation
93. Planning
94. • Planning goes smoothly when: • You Product Backlog / Icebox is Well Defined • Broken into manageable stories & estimated • End of planning ensure: • Goals are set and stories are prioritized • Everyone knows what they will be doing next Planning
95. Stand Ups
96. • Focus on the spirit of the meeting, not the rules. • Make sure to identify three areas: • What happened Previous Day • What they will work on Today • Anything Blocking. • Opportunity for Decisions! Keep an eye on Goals! Making Stand Ups Effective
97. Final Thoughts
98. Everyone Has a Process
99. Be Strategic About It
100. Spirit Over the Rule
101. Always Look for Ways to Improve
102. Questions?
103. Thank You Twitter: @JustinCarmony Email: justin@justincarmony.com Web: justincarmony.com Please Leave Feedback: https://joind.in/10884