agile is as agile does  martin jopson, greenhopper
how    greenhopper    uses   agileto build   greenhopper
an agile awakening
standups + waterfall != agilehttp://www.flickr.com/photos/robbieredball/4447663294/
agile
good contractvalue delivered soonerlevel of autonomynegotiable & fair
empowermentincreased buy-insense of ownership20% & hack days
© sherif g mansour
involvementpaper prototypingdesign wallstory mapping
design wall
story mappingactivities/tasksmvpproduct backlogroadmap/vision
sustainableconstant pacevisibilitytransparency
productteamiterate as you iterate
iterate²reviewretrospectiveactionsbaseline
iterate²variationdifferenceskanban for kanbanscrum for scrum
1 week iterations for ? weeks
x 1 weekprototypingfast experimentationdirection shiftspotentially shippable
week1
week2
week3
week3
week4
week4
week5
week5
week6
week6
week7
week7
week8
week8
week8
week9
week10
now
1 week = 4 days
1 week4 + ½+ ½   tasks           demo/retro/plan           20% aka 7%
1 weekadmin overheadeasily affectedestimate buffer
1 weekexciting pacerapid changeshort feedback loop
rapidfeedback
feedbackdogfoodersexternal customerskeep on track
feedbackissue collector pluginpublic backloggreenhopper labscustomer interviews
“I love the "only my issues" button. Youshould allow for as many of those as the               user wants”
“How rapidly my previous commentswere responded to. GREAT JOB GUYS!”
!kneejerkbetter picturefail/hack/painproblem patternssolutions
take-aways
empower your team20% or hack daysincrease engagement
try something newagile ?agile +not working yet?
feedback, early & oftenkeeps you on trackshorter loopsrespond & deliver
thank you
thank you
Agile is as Agile Does - Atlassian Summit 2012
Agile is as Agile Does - Atlassian Summit 2012
Agile is as Agile Does - Atlassian Summit 2012
Upcoming SlideShare
Loading in …5
×

Agile is as Agile Does - Atlassian Summit 2012

1,339 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,339
On SlideShare
0
From Embeds
0
Number of Embeds
568
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Good afternoon everyone, I’m Martin Jopson. \nI’m a developer at Atlassian and I’d like to share some of the things I’ve learned.\n
  • Today we’re going to look at how GreenHopper uses agile to build GreenHopper\n
  • Before joining Atlassian the only agile I’d done was of the non-agile variety.\n
  • I worked at a large digital media company\nTeams were not involved in any planning meetings, \nAt a kick-off meeting involving all developers, a gantt chart ran the length of the room, the massive amount of work determined with fixed dates assigned to it.\n\nthey said we’d “do agile”... but we didn’t.\n
  • Joining Atlassian and GreenHopper and working on the team opened my eyes to some of the real benefits of agile. \nso I’d like to share some of the things I hold dear about agile\n
  • Agile is a really good contract - it's a good deal for people like me, for your developers. \nwhen done right the contract offers rewards for both sides. \nFor the stakeholders, value is delivered sooner. \nFor the developers, a level of autonomy, in Scrum for example, a discussion and agreement on the work to be completed in the next sprint. Negotiable and fair\n\n
  • this way of working increases buy-in and sense of ownership\n\nAtlassian takes this level of empowerment further with 20% and hack days\nThese can be proving grounds for features you believe in but that don't get high enough on backlog\n\n
  • \n
  • teams are empowered when there is increased involvement outside of their tasks\nwhen they are engaged in additional activities such as paper prototyping\n\n
  • The design wall is a space where design concepts and mockups are posted\nThe team meet frequently at the wall and discuss design ideas.\n
  • The greenhopper team has also engaged in story mapping, an activity to map out everything a user might need to do to be successful in their goal.\nThe team are locked away in a room together armed with index cards and pens\nThe map is made up of activities, for example - sprint planning, and then these activities are broken down into tasks, say, add issue to sprint.\nRemove items - minimum viable product -smallest amount of features needed to deliver a useful product\nWe now effectively had a basis for the product backlog BUT more than this - the team is now on the same page\nand understands more of the longer term vision, the roadmap, and the more granular detail starting to take shape.\nJust working sprint by sprint on stories can miss this. It’s valuable for everyone to know about the bigger picture.\n
  • Working in an agile way should protect us from burnout and big bang deadlines.\nthere’s high visibility and transparency throughout,\nusing an available chart... the team and stakeholders can see the progress being made\n\n
  • greenhopper’s burndown chart also shows Scope Change\nso if something extra is added after the start, everyone will be able to see\n
  • greenhopper team uses wallboards to show progress\nthese can be seen near the team and also viewed remotely\n
  • it’s a process of continual improvement and refinement\nfor the team and the product\n
  • Sprint didn't work out as you'd hoped? No worries, we have a review/retro to discuss what was good, bad and form actions to improve. We now have a base for what we could achieve, too little, too much. If we fail the Sprint we can understand why and commit better the next time.\n
  • having tried some variation in approach, it was interesting to feel the differences that the changes can make\nthe team used Kanban to build the Kanban boards, and Scrum when building the Scrum boards\n
  • For the rapid board we changed to iterations of 1 week for initial rapid prototyping\n\n\n
  • this helped fast experimentation and direction shifts\nat the end of each week the product was potentially shippable, albeit in greenhopper labs\n\n
  • I’ll now share how we iterated for the first 10 weeks of the rapid board\n\nweek 1 - the issues in a JIRA filter are simply presented on the page\n
  • By week 2 we now have columns for each transition\n
  • week 3 - we have drag and drop transitions\n
  • and also a detail view for a selected issue\n
  • week 4 - the transitions became configurable\n
  • drop-zones for multiple transitions\n
  • week 5 we can add and rename columns\n
  • week 5 - UI gets an overhaul\n
  • week 6 sees the introduction of a single hard-coded swimlane, for Blockers\n
  • we can also see an update to the detail view\n
  • week 7 sees the introduction of column constraints\n
  • and the first report which is a control chart\n
  • by week 8 the swimlane can now be edited, any valid JQL can be used\n
  • here we see the customised swimlane\n
  • week 8 also sees the standard deviation added to the control chart\n
  • week 9 adds another chart - the cumulative flow diagram\n
  • by week 10 we have multiple custom swimlanes\n
  • and here is the board just recently\n
  • 1 week = 4 days\n\n\n
  • 4 days Dev, .5 day demo/retro/planning, .5 day 20% or devspeed\n\n\n
  • Downsides\nSpecial events impact more heavily eg. Fedex. Or someone being sick.\nBuffer for estimates smaller\n\n
  • Upsides\nThe pace is fast and each week feels like something changed. Feedback loop very short.\n\n
  • So during the development of the rapid board we sought feedback\nRapid feedback is addictive.\n\n\n
  • Early feedback from dogfooders and external customers is invaluable. \nIt may not always be what you wanted to hear but ultimately it should keep you on track.\n\n\n
  • to collect feedback we use\nIssue collector (plugin), but could be a web form.\nPublic backlog\nGreenHopper Labs for opt-in early access\nUser interviews\n\n
  • Often we received feedback on a version telling us several times that they really wanted the thing we were already working on in the next version. Great - we're on track!\n\nhttps://jira.atlassian.com/browse/FEEDBACK-199\n
  • we even got feedback on how well we responded to feedback\n\nhttps://jira.atlassian.com/browse/FEEDBACK-1467\n
  • for me it's been valuable to consume the feedback from all of these sources, it helps build a better picture of what customers are trying to achieve, how they're trying to achieve it currently (either failing, hacking or going a long way round) and how we can help them and often several similar requests as we design a solution.\n
  • so I would like to propose 3 take aways\n
  • Takeaway 1. \nFirstly, empower your team\nTry 20% or a hack day. It offers team members a chance to shine, and to polish the product in the way they think is needed. \nThe rewards of 20% or hack day project getting shipped are the value to the customer plus \nthe increased engagement of the team, the increased buy-in, increased ownership, increased pride.\n
  • Takeaway 2. \nNext.\nIf you're not doing Agile, try it.\nIf you're not doing Agile fairly, change it. The benefits to the team will benefit everyone.\nIf you're not getting the results you want, try something new - that may be iteration length or a switch from scrum to kanban\n
  • Takeaway 3. \nFinally,\nFeedback from real users early and often keeps you on track.\nThe shorter your feedback loop the better you can respond to your customer needs and deliver value to them.\n
  • thank you\n
  • Agile is as Agile Does - Atlassian Summit 2012

    1. 1. agile is as agile does martin jopson, greenhopper
    2. 2. how greenhopper uses agileto build greenhopper
    3. 3. an agile awakening
    4. 4. standups + waterfall != agilehttp://www.flickr.com/photos/robbieredball/4447663294/
    5. 5. agile
    6. 6. good contractvalue delivered soonerlevel of autonomynegotiable & fair
    7. 7. empowermentincreased buy-insense of ownership20% & hack days
    8. 8. © sherif g mansour
    9. 9. involvementpaper prototypingdesign wallstory mapping
    10. 10. design wall
    11. 11. story mappingactivities/tasksmvpproduct backlogroadmap/vision
    12. 12. sustainableconstant pacevisibilitytransparency
    13. 13. productteamiterate as you iterate
    14. 14. iterate²reviewretrospectiveactionsbaseline
    15. 15. iterate²variationdifferenceskanban for kanbanscrum for scrum
    16. 16. 1 week iterations for ? weeks
    17. 17. x 1 weekprototypingfast experimentationdirection shiftspotentially shippable
    18. 18. week1
    19. 19. week2
    20. 20. week3
    21. 21. week3
    22. 22. week4
    23. 23. week4
    24. 24. week5
    25. 25. week5
    26. 26. week6
    27. 27. week6
    28. 28. week7
    29. 29. week7
    30. 30. week8
    31. 31. week8
    32. 32. week8
    33. 33. week9
    34. 34. week10
    35. 35. now
    36. 36. 1 week = 4 days
    37. 37. 1 week4 + ½+ ½ tasks demo/retro/plan 20% aka 7%
    38. 38. 1 weekadmin overheadeasily affectedestimate buffer
    39. 39. 1 weekexciting pacerapid changeshort feedback loop
    40. 40. rapidfeedback
    41. 41. feedbackdogfoodersexternal customerskeep on track
    42. 42. feedbackissue collector pluginpublic backloggreenhopper labscustomer interviews
    43. 43. “I love the "only my issues" button. Youshould allow for as many of those as the user wants”
    44. 44. “How rapidly my previous commentswere responded to. GREAT JOB GUYS!”
    45. 45. !kneejerkbetter picturefail/hack/painproblem patternssolutions
    46. 46. take-aways
    47. 47. empower your team20% or hack daysincrease engagement
    48. 48. try something newagile ?agile +not working yet?
    49. 49. feedback, early & oftenkeeps you on trackshorter loopsrespond & deliver
    50. 50. thank you
    51. 51. thank you

    ×