Agile Doesn't Have to Stink

Transcript

1. Agile Doesn't Have to Stink Justin Carmony - OpenWest 2015 @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 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 Developers? Product Owners? Project Managers? Scrum Master? Management?
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. Decisions
56. Make Decisions that Manage Risk
57. Complexity Critical
58. Complexity Critical
59. Complexity Critical
60. Complexity Critical
61. Complexity Critical
62. Improving Parts of your Process
63. Team Roles
64. Project Manager Owns the Process Owns the Product Owns Development
65. Project Manager Owns the Process Owns the Product Owns Development Hard to assess reality for all 3 things
66. Scrum Master Owns the Process Owns the Product Owns Development Product Owner Dev Lead
67. Scrum Master Product Owner Dev Lead Reality Decisions
68. Share Common Goal Individual Responsibilities
69. Meetings
70. Meetings Suck!
71. Keep Them Simple! Keep Them Short!
72. Review Retro Estimation Planning 2.5 Hours
73. Retrospectives
74. MOST IMPORTANT PART OF OUR PROCESS!
75. 1.What went well? 2.What do we want to Change? 3.How are we going to Change It? Retrospectives Reality In Decisions Out
76. Document It!
77. • Added 0 point option to Pivotal for for simple tasks that were falling in the cracks before. • More consistent with standups. Starting & ending on time. • Gathered good feedback from stakeholders • Having a UI that we can demonstrate with helps communicate to stakeholders What Went Well
78. 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.
79. 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.
80. 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.
81. 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
82. Review Your Retrospective Items!
83. • Safe Communication Environment • Focus on the Future • Look for Small, Manageable Changes • Focus on You before Others - “What can I improve” Making Retrospectives Effective
84. Estimation
85. It’s Not Precise! It’s Not Accurate!
91. Releasing
92. Complexity Critical
93. Complexity Critical
95. • Don’t Over Analyze for perfect Precision! • Focus on Identifying Complexities. • Opportunity for Product Owners & Devs to clear up Ambiguity and define a more clear scope. • You will get better over time. There will always be stories that will be greatly over or under estimated. Estimation Reality In Decisions Out
97. Planning
98. • 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
99. Stand Ups
100. • 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 Reality In Decisions Out Reality In
101. Final Thoughts
102. Everyone Has a Process
103. Be Strategic About It
104. Spirit Over the Rule
105. Always Look for Ways to Improve
106. Questions?
107. Thank You Twitter: @JustinCarmony Email: justin@justincarmony.com Web: justincarmony.com Please Leave Feedback: https://joind.in/10884