Agile that works and the tools we love

It's not easy to do Scrum and agile development in an agency. Most customers aren't used to the process, and how can you manage expectations while finding good solutions in a process that both your technical team and the customer will appreciate? I'll show you how we handle this in Reload, going from early estimations, to wireframes, breakdown into user stories, estimation hereof and the day to day workings of Jira and Greenhopper, our weapons of choice.

Reload is a Copenhagen based Drupal specialized agency - find us at www.reload.dk.

Disclaimer: I'm not a designer, so I was heavily inspired by the design made by Brandon Mathis' great presentation about SASS: https://speakerdeck.com/imathis/sass-compass-the-future-of-stylesheets-now

Transcript

1. Agile that works the tools we love & Drupalha en, Oct. 27th 2012
2. Rasmus Luckow-Nielsen @rasmusluckow
3. PARTNER AT @RELOADDK
4. >How to qualify projects > > This talk is about: Why agile & scrum rocks > And why it’s so ‘e"ng di"cult The weapons of choice Balsamiq, Jira, Greenhopper, Bon!re > > And the customers
5. If you don’t live up to the customers’ expectations, then the project will be considered a failure no matter what. THE PREMISE
6. 95% of our projects is billed by the hour. We’ve learned this the hard way. THE PREMISE
7. ? Why do we want agile IS SCRUM REALLY THE ANSWER TO EVERYTHING?
8. We want to build better solutions for the customer, providin maximum (business)value for money, lower the risks, collaborate as a close-knit team and not end up with a Bi Hu e Fi ht in the end.
9. WHAT IS SCRUM? How many in here are unsure what Scrum really is? Raise your hands.
10. SCRUM PROCESS
11. WHY DO SCRUM? Scope and price aren’t fixed We are bad at estimates, so this makes the risk lower
12. WHY DO SCRUM? The customer are usually really bad at explainin what they want - but think we understand. We don’t. Scrum makes us talk.
13. WHY DO SCRUM? Developers do technical decisions. The customer makes the business decisions.
14. WHY DO SCRUM? Scrum help us mana e expectations. This is the most important discipline of project mana ement.
15. ? So what are the challenges THE THINGS I DO FOR LOVE
16. THE CHALLENGES The customer needs to trust you and the process - even the customers’ i norant all-mi hty superiors.
17. THE CHALLENGES You have to demand a lot of involvement from the customer - meanin a lot of time from their (busy) Product Owner (PO).
18. THE CHALLENGES The customers’ PO must be able to make a lot of decisions and fast.
19. THE CHALLENGES It’s rather difficult to do scrum the ri ht way when you are an external a ency and not part of the or anization you’re helpin .
20. THE CHALLENGES In our experience we have to act as assistin PO as well.
21. Identifying AND THE ONES TO WALK AWAY FROM the right projects
22. THE RIGHT PROJECTS often have a lot of external / undefined dependencies (thats how it started for us - by necessity). >
23. THE RIGHT PROJECTS have a meanin ful size - the development effort is at least 2-3 months with a couple of developers > SMALL IS BAD, AS SCRUM HAVE UPSTART OVERHEAD
24. THE RIGHT PROJECTS come from an or anization that’s suited for a ile processes - where they dare dele ate decision makin responsibility to the Product Owner. >
25. THE RIGHT PROJECTS have an or anization and team that appreciates the fact that we’ll fi ure out thin s as we o alon . >
26. STICK THEM WITH THE POINTY END And be ready to walk away
27. WHAT TO DO WHEN you can’t make customer really understand the process and why it works. Or if you think they don’t et it. > walk away YOU
28. WHAT TO DO WHEN you sense that the PO has no real power in the or anization. (The PO will make a lot of decisions - they need to stand up to them. If not...) > walk away YOU
29. WHAT TO DO WHEN the bud et is far too small compared to the expectations of the final result - and the customer won’t listen. > THEY WILL NEVER BE HAPPY. YOU WILL NEVER MATCH THEIR EXPECTATIONS. walk away WHY DON’T YOU
30. WHAT TO DO WHEN When the customer wants to do “everythin a ile”, but insists on fixed deadline, fixed scope and fixed price. > THEY DO NOT GET IT, DO THEY? walk away YOU
31. & Stop walking start WILLING TO PAY THE IRON PRICE? working!
32. (Quality) LETS ASSUME THEY GET IT Scope (functionality, features) Time (deadline) Resources (cost, bud et)
33. Agile and scrum without rules AND WINTER IS COMING is just chaos
34. Methodolo ies and the ri ht tools are essential.
35. Do it ri ht, and Scrum will help you mana e expectations.
36. HOW TO DO IT Scrum “by the book” cost a lot of resources and have lots of meetin activity; and customers hate to pay for meetin s. > IT IS KNOWN.
37. HOW TO DO IT Should we just do Kanban or full Scrum? We do somethin in between. > THIS WILL HELP Kanban and Scrum making the most of both
38. HOW TO DO IT So which rules must we abide - and which ones are less important? >
39. > User story estimation > > The Do’s Daily scrum > Sprint planning Velocity calculation >Sprint report THIS IS WHERE YOU MANAGE EXPECTATIONS. IN WRITING.
40. Define your “Definition of Done”: METHODOLOGY Code Complete Unit tests written and executed Inte ration tested Performance tested Documented (just enou h) Approved by Product Owner > > > > > >
41. Keep the sprint-plannin as short and focused as possible. Make sure the plannin is well prepared. METHODOLOGY
42. Be pra matic. Keep it li ht. Chan e what doesn’t work in your situation. METHODOLOGY
43. > The bottom line Delivering working, tested software every 4 weeks or less. Delivering what the business needs most. Continuously improving the process. > > THINGS ARE PRETTY GOOD IF YOU ARE
44. & The process THE RELOAD WAY the tools we use
45. THE BEGINNING The customer often come to us with rather va ue ideas: “We want to build a site to be the best XYZ site” or rebuild an existin site to better match new business demands.
46. THE BEGINNING So we start off with a period of analysis. This consists of a lot of workshops where we’re drillin down in order to identify the real pains, ideas and opportunities.
47. THE BEGINNING Often we end up with somethin quite different that what the customer had in mind to be in with. And found a common understandin i the process.
48. THE BEGINNING We end up with wireframes and user stories. The wireframes and user stories are our specification.
50. Tools we love
51. THE BEGINNING We map the user stories to the wireframes and visa versa. Get a “complete” backlo as soon as possible.
52. THE BEGINNING Desi n is the next step, but we don’t have time for that today. But we really would like feedback on reload.dk/drupalstyle uide
53. + Tools we love by
54. THE BACKLOG - PLANNING
55. THE BACKLOG - PLANNING
56. SPRINT IN PROGRESS
57. SPRINT IN PROGRESS THIS IS GREENHOPPER V6
58. SPRINT IN PROGRESS Gives us usable reports as well! AND IT HANDLES SCOPE CHANGE NICELY.
59. REPORTS
60. REPORTS
61. REPORTS Commitment Completed
62. REPORTS
63. Tools we love by MORE
64. BONFIRE - EXPLORATORY TESTING
65. BONFIRE - EXPLORATORY TESTING
66. STEEP LEARNING CURVE The Atlassian products have a really nasty learnin curve. But that’s because it’s so damned flexible. You’ll learn to love it. We did.
67. > To sum it up Manage expectations is a key factor for success Scrum is hard - the right tools make it easier to succeed It’s about continuous learning and improvement > >
68. Questions?
69. Rasmus Luckow-Nielsen @rasmusluckow Thanks! reload.dk/jobs @reloaddk We’re hiring :-)