Agile that works and the tools we love

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.
49. None

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 :-)