Agile that works and the tools we love

Transcript

1. Agile that works
   the tools
   we love
   &
   Drupalha en, Oct. 27th 2012
   

   View Slide

2. Rasmus
   Luckow-Nielsen
   @rasmusluckow
   

   View Slide

3. PARTNER AT
   @RELOADDK
   

   View Slide

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
   

   View Slide

5. If you don’t live up to the
   customers’ expectations, then the
   project will be considered a
   failure no matter what.
   THE PREMISE
   

   View Slide

6. 95% of our projects is billed by
   the hour.
   We’ve learned this the hard way.
   THE PREMISE
   

   View Slide

7. ?
   Why do we
   want agile
   IS SCRUM REALLY THE
   ANSWER TO EVERYTHING?
   

   View Slide

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.
   

   View Slide

9. WHAT IS SCRUM?
   How many in here are unsure
   what Scrum really is?
   Raise your hands.
   

   View Slide

10. SCRUM PROCESS
    

    View Slide

11. WHY DO SCRUM?
    Scope and price aren’t fixed
    We are bad at estimates, so
    this makes the risk lower
    

    View Slide

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.
    

    View Slide

13. WHY DO SCRUM?
    Developers do technical
    decisions.
    The customer makes the
    business decisions.
    

    View Slide

14. WHY DO SCRUM?
    Scrum help us mana e
    expectations. This is the most
    important discipline of project
    mana ement.
    

    View Slide

15. ?
    So what are
    the challenges
    THE THINGS I DO FOR LOVE
    

    View Slide

16. THE CHALLENGES
    The customer needs to trust
    you and the process
    - even the customers’ i norant
    all-mi hty superiors.
    

    View Slide

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

    View Slide

18. THE CHALLENGES
    The customers’ PO must be
    able to make a lot of
    decisions and fast.
    

    View Slide

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 .
    

    View Slide

20. THE CHALLENGES
    In our experience we have to
    act as assistin PO as well.
    

    View Slide

21. Identifying
    AND THE ONES TO WALK AWAY FROM
    the right projects
    

    View Slide

22. THE RIGHT PROJECTS
    often have a lot of external /
    undefined dependencies
    (thats how it started for us -
    by necessity).
    >
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

26. STICK THEM WITH THE POINTY END
    And be ready to
    walk away
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

31. &
    Stop walking
    start
    WILLING TO PAY THE
    IRON PRICE?
    working!
    

    View Slide

32. (Quality)
    LETS ASSUME THEY GET IT
    Scope
    (functionality, features)
    Time
    (deadline)
    Resources
    (cost, bud et)
    

    View Slide

33. Agile and scrum
    without rules
    AND WINTER IS COMING
    is just chaos
    

    View Slide

34. Methodolo ies
    and the ri ht tools
    are essential.
    

    View Slide

35. Do it ri ht, and Scrum will help
    you mana e expectations.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

38. HOW TO DO IT
    So which rules must we
    abide - and which ones
    are less important?
    >
    

    View Slide

39. >
    User story estimation
    >
    >
    The Do’s
    Daily scrum
    >
    Sprint planning
    Velocity calculation
    >Sprint report
    THIS IS WHERE YOU MANAGE EXPECTATIONS.
    IN WRITING.
    

    View Slide

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

    View Slide

41. Keep the sprint-plannin as short
    and focused as possible.
    Make sure the plannin is well
    prepared.
    METHODOLOGY
    

    View Slide

42. Be pra matic. Keep it li ht.
    Chan e what doesn’t work in
    your situation.
    METHODOLOGY
    

    View Slide

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
    

    View Slide

44. &
    The process
    THE RELOAD WAY
    the tools we use
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

48. THE BEGINNING
    We end up with wireframes
    and user stories.
    The wireframes and user
    stories are our specification.
    

    View Slide

49. View Slide

50. Tools we love
    

    View Slide

51. THE BEGINNING
    We map the user stories to
    the wireframes and visa versa.
    Get a “complete” backlo as
    soon as possible.
    

    View Slide

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
    

    View Slide

53. +
    Tools we love
    by
    

    View Slide

54. THE BACKLOG - PLANNING
    

    View Slide

55. THE BACKLOG - PLANNING
    

    View Slide

56. SPRINT IN PROGRESS
    

    View Slide

57. SPRINT IN PROGRESS
    THIS IS GREENHOPPER V6
    

    View Slide

58. SPRINT IN PROGRESS
    Gives us usable reports as
    well!
    AND IT HANDLES SCOPE CHANGE NICELY.
    

    View Slide

59. REPORTS
    

    View Slide

60. REPORTS
    

    View Slide

61. REPORTS
    Commitment
    Completed
    

    View Slide

62. REPORTS
    

    View Slide

63. Tools we love
    by
    MORE
    

    View Slide

64. BONFIRE - EXPLORATORY TESTING
    

    View Slide

65. BONFIRE - EXPLORATORY TESTING
    

    View Slide

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.
    

    View Slide

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

    View Slide

68. Questions?
    

    View Slide

69. Rasmus
    Luckow-Nielsen
    @rasmusluckow
    Thanks!
    reload.dk/jobs
    @reloaddk
    We’re hiring :-)
    

    View Slide