Agile is as Agile Does - Atlassian Summit 2012
•Descargar como KEY, PDF•
0 recomendaciones•912 vistas
Martin Jopson discusses how Greenhopper uses agile practices like standups, 1 week iterations with prototyping and experimentation, and feedback from dogfooders and customers to build their product. Some key aspects of their agile approach include empowering teams through autonomy, ownership and hack days, gathering feedback through public issue tracking and interviews, and responding rapidly to deliver value sooner through short iterations.
Recomendados
Recomendados
Más contenido relacionado
Similar a Agile is as Agile Does - Atlassian Summit 2012
Similar a Agile is as Agile Does - Atlassian Summit 2012 (20)
Más de Atlassian
Más de Atlassian (20)
Último
Último (20)
Agile is as Agile Does - Atlassian Summit 2012
- 1. agile is as agile does martin jopson, greenhopper
- 2. how greenhopper uses agile to build greenhopper
- 4. standups + waterfall != agile http://www.flickr.com/photos/robbieredball/4447663294/
- 5. agile
- 6. good contract value delivered sooner level of autonomy negotiable & fair
- 7. empowerment increased buy-in sense of ownership 20% & hack days
- 8. © sherif g mansour
- 10. design wall
- 16. product team iterate as you iterate
- 18. iterate² variation differences kanban for kanban scrum for scrum
- 19. 1 week iterations for ? weeks
- 20. x 1 week prototyping fast experimentation direction shifts potentially shippable
- 21. week 1
- 22. week 2
- 23. week 3
- 24. week 3
- 25. week 4
- 26. week 4
- 27. week 5
- 28. week 5
- 29. week 6
- 30. week 6
- 31. week 7
- 32. week 7
- 33. week 8
- 34. week 8
- 35. week 8
- 36. week 9
- 37. week 10
- 38. now
- 39. 1 week = 4 days
- 40. 1 week 4 + ½+ ½ tasks demo/retro/plan 20% aka 7%
- 41. 1 week admin overhead easily affected estimate buffer
- 42. 1 week exciting pace rapid change short feedback loop
- 43. rapid feedback
- 45. feedback issue collector plugin public backlog greenhopper labs customer interviews
- 46. “I love the "only my issues" button. You should allow for as many of those as the user wants”
- 47. “How rapidly my previous comments were responded to. GREAT JOB GUYS!”
- 49. take-aways
- 50. empower your team 20% or hack days increase engagement
- 51. try something new agile ? agile + not working yet?
- 52. feedback, early & often keeps you on track shorter loops respond & deliver
- 53. thank you
- 54. thank you
Notas del editor
- 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