Download as KEY, PPTX
Uploaded byAtlassian
Scrum Shock Therapy: Going Back to Basics - Atlassian Summit 2012
The document discusses using "Scrum shock therapy" to transition a team from Kanban to Scrum by imposing strict rules like one-week sprints and fully estimating all work upfront. This caused pain for the team initially. Key learnings included the importance of good retrospectives and that physical card walls can improve communication but are hindrances to remote work. Barriers to agile adoption include a lack of automation and buy-in from the whole team. In the end, strict rules may only work for very dysfunctional teams and discipline is better achieved through other means.
More Related Content
Similar to Scrum Shock Therapy: Going Back to Basics - Atlassian Summit 2012
Scrum Shock Therapy: Going Back to Basics - Atlassian Summit 2012
- 2. Scrum Shock Therapy GoingBack to Basics James Hatherly GreenHopper Developer, Atlassian
- 3.
- 4. The perceived problem:ScrumBut
- 5. Fun with ScrumShock Therapy
- 6. Fun with ScrumShock Therapy • Went from Kanban to Scrum at the same time
- 7. Fun with ScrumShock Therapy • Went from Kanban to Scrum at the same time • Imposed some painful rules:
- 8. Fun with ScrumShock Therapy • Went from Kanban to Scrum at the same time • Imposed some painful rules: • One week sprints
- 9. Fun with ScrumShock Therapy • Went from Kanban to Scrum at the same time • Imposed some painful rules: • One week sprints • Everything fully estimated ahead of time
- 10. Fun with ScrumShock Therapy • Went from Kanban to Scrum at the same time • Imposed some painful rules: • One week sprints • Everything fully estimated ahead of time • Physical card wall
- 11. Fun with ScrumShock Therapy • Went from Kanban to Scrum at the same time • Imposed some painful rules: • One week sprints • Everything fully estimated ahead of time • Physical card wall • 4 hour sprint demo, retro, planning meeting (kill me now!)
- 12.
- 13.
- 14. Physical cardwall actedas a communication hub • Collaboration and discussion became synchronised • Better communication on issues and subtasks
- 15.
- 16.
- 17.
- 18. Cardwalls are painful •Serious hindrance to working from home/working remotely • No JIRA! • No persistence • No search • No linking • No notifications
- 19. Cardwalls are painful •Tooling • Linking commits back to stories • Editor integration (IDE connectors, JIRA mode in Emacs) • Reporting & charting
- 20. Barriers to agileadoption
- 21. Barriers to agileadoption
- 22. Alex is notalone • All devs automate tasks which they don’t want to do • Things which can’t be automated must have obvious reasons for getting in a developer’s way • Scrum needs whole-team buy in to work
- 23. The decline ofagile?
- 24. The decline ofagile?
- 25. Final thoughts • Tobe fair - we were not the intended target of scrum shock therapy. Meant for teams new to scrum. • However, it seems like it would only work with the most non-agile and dysfunctional teams. • The hard rules attempt to impose discipline, but can’t we just be more disciplined?
- 26. References • Scrum ShockTherapy - http://rapidscrum.com/ shock.php • How GitHub uses GitHub to use GitHub - http:// zachholman.com/talk/how-github-uses-github-to-build- github • XKCD, The General Problem - http://xkcd.com/974/ • Programming, Motherfucker - http://programming- motherfucker.com/
Editor's Notes
- #2 \n
- #3 Hey all, I’m James Hatherly, a developer on the GreenHopper team at Atlassian.\n\nLate last year, our team’s scrum master suggested that we go through ‘Scrum Shock Therapy’. Which...\n
- #4 surprisingly (and thankfully) does not involve electrodes. It’s - quite simply - a guide for bootstrapping high performing scrum teams. It’s based on a paper of the same name by Jeff Sutherland and Scott Downey, which details the use of this process by some teams at MySpace and JayWay and claims some pretty impressive results. \nThe process imposes a number of non-negotiable rules, in particular the banning of tools such as GreenHopper. The motivation for these non-negotiable rules (or rather, having rules which are non-negotiable) is the idea that many teams that adopt scrum are very liberal in how they implement it, leading to what is referred to as...\n
- #5 ScrumBut, like: “scrum, but we don’t estimate or track velocity” or “scrum, but we only do standups”. In the authors’ opinions, many “scrum” teams don’t end up actually doing scrum at all.\nBeing an adventurous group, we agreed to try shock therapy out. We recognised that we hadn’t always been diligent in some of our practices and thought that - maybe - we’d see the same sort of performance gains cited in the article. \nFailing that, we thought that it would be valuable as an educational exercise - stepping back from our day-to-day practices to see how some first-timers might be getting introduced to scrum. Perhaps we would gain some insight which we could feed back into the development of GreenHopper.\n
- #6 Before this experiment we’d been dogfooding the new kanban features we were then implementing for GreenHopper, we were loving it and were delivering great results - we were quite satisfied with and proud of our productivity. Switching back to scrum felt like an immediate drop in productivity. On top of that, the rules imposed on us as part of scrum shock therapy were pretty restrictive. \n* One week sprints made it hard to get architectural work (and big features which couldn’t be broken down) done.\n* Estimation got pretty painful as we were working on a whole new feature set. Lots of new stories -> lots of time lost to pre-planning estimation meetings. I recall one week we had a lot of new stories to estimate, and so had 4 hours worth of meetings in addition to our regular demo, retro, planning block.\n* For a team used to using a tool like GreenHopper, switching to a physical card wall was agony. \n* Finally, as far as I’m concerned, meetings should be as short as they can be - anything that can be taken offline, should be. For me, a weekly, four hour long meeting is an assault to my productivity and sanity.\n
- #7 Before this experiment we’d been dogfooding the new kanban features we were then implementing for GreenHopper, we were loving it and were delivering great results - we were quite satisfied with and proud of our productivity. Switching back to scrum felt like an immediate drop in productivity. On top of that, the rules imposed on us as part of scrum shock therapy were pretty restrictive. \n* One week sprints made it hard to get architectural work (and big features which couldn’t be broken down) done.\n* Estimation got pretty painful as we were working on a whole new feature set. Lots of new stories -> lots of time lost to pre-planning estimation meetings. I recall one week we had a lot of new stories to estimate, and so had 4 hours worth of meetings in addition to our regular demo, retro, planning block.\n* For a team used to using a tool like GreenHopper, switching to a physical card wall was agony. \n* Finally, as far as I’m concerned, meetings should be as short as they can be - anything that can be taken offline, should be. For me, a weekly, four hour long meeting is an assault to my productivity and sanity.\n
- #8 Before this experiment we’d been dogfooding the new kanban features we were then implementing for GreenHopper, we were loving it and were delivering great results - we were quite satisfied with and proud of our productivity. Switching back to scrum felt like an immediate drop in productivity. On top of that, the rules imposed on us as part of scrum shock therapy were pretty restrictive. \n* One week sprints made it hard to get architectural work (and big features which couldn’t be broken down) done.\n* Estimation got pretty painful as we were working on a whole new feature set. Lots of new stories -> lots of time lost to pre-planning estimation meetings. I recall one week we had a lot of new stories to estimate, and so had 4 hours worth of meetings in addition to our regular demo, retro, planning block.\n* For a team used to using a tool like GreenHopper, switching to a physical card wall was agony. \n* Finally, as far as I’m concerned, meetings should be as short as they can be - anything that can be taken offline, should be. For me, a weekly, four hour long meeting is an assault to my productivity and sanity.\n
- #9 Before this experiment we’d been dogfooding the new kanban features we were then implementing for GreenHopper, we were loving it and were delivering great results - we were quite satisfied with and proud of our productivity. Switching back to scrum felt like an immediate drop in productivity. On top of that, the rules imposed on us as part of scrum shock therapy were pretty restrictive. \n* One week sprints made it hard to get architectural work (and big features which couldn’t be broken down) done.\n* Estimation got pretty painful as we were working on a whole new feature set. Lots of new stories -> lots of time lost to pre-planning estimation meetings. I recall one week we had a lot of new stories to estimate, and so had 4 hours worth of meetings in addition to our regular demo, retro, planning block.\n* For a team used to using a tool like GreenHopper, switching to a physical card wall was agony. \n* Finally, as far as I’m concerned, meetings should be as short as they can be - anything that can be taken offline, should be. For me, a weekly, four hour long meeting is an assault to my productivity and sanity.\n
- #10 Before this experiment we’d been dogfooding the new kanban features we were then implementing for GreenHopper, we were loving it and were delivering great results - we were quite satisfied with and proud of our productivity. Switching back to scrum felt like an immediate drop in productivity. On top of that, the rules imposed on us as part of scrum shock therapy were pretty restrictive. \n* One week sprints made it hard to get architectural work (and big features which couldn’t be broken down) done.\n* Estimation got pretty painful as we were working on a whole new feature set. Lots of new stories -> lots of time lost to pre-planning estimation meetings. I recall one week we had a lot of new stories to estimate, and so had 4 hours worth of meetings in addition to our regular demo, retro, planning block.\n* For a team used to using a tool like GreenHopper, switching to a physical card wall was agony. \n* Finally, as far as I’m concerned, meetings should be as short as they can be - anything that can be taken offline, should be. For me, a weekly, four hour long meeting is an assault to my productivity and sanity.\n
- #11 Before this experiment we’d been dogfooding the new kanban features we were then implementing for GreenHopper, we were loving it and were delivering great results - we were quite satisfied with and proud of our productivity. Switching back to scrum felt like an immediate drop in productivity. On top of that, the rules imposed on us as part of scrum shock therapy were pretty restrictive. \n* One week sprints made it hard to get architectural work (and big features which couldn’t be broken down) done.\n* Estimation got pretty painful as we were working on a whole new feature set. Lots of new stories -> lots of time lost to pre-planning estimation meetings. I recall one week we had a lot of new stories to estimate, and so had 4 hours worth of meetings in addition to our regular demo, retro, planning block.\n* For a team used to using a tool like GreenHopper, switching to a physical card wall was agony. \n* Finally, as far as I’m concerned, meetings should be as short as they can be - anything that can be taken offline, should be. For me, a weekly, four hour long meeting is an assault to my productivity and sanity.\n
- #12 \n
- #13 One good thing we found out - retrospectives deserve to be given as much time as they need. Once we started shock therapy, we realised that we had been trimming our retrospectives, and hadn’t been giving ourselves as much time as we actually needed to get value out of our retrospectives. Having a four hour block of time meant that we didn’t feel the need to rush our retrospectives to get onto planning our next sprint. \n
- #14 The other key differences in how we operated were some changes to the way we communicated, and specifically how having a physical card wall changed this. When we were not using a card wall, I’d guess that >80% of discussion happened as comments on an issue in GH (the remainder being over IM or in-person). When we switched, there was no alternative - so everything was verbal, usually centred around the wall itself.\n\nNow normally, I’m a fervent advocate of the ‘everything asynchronous, all the time’ mentality (as best outlined by Zach Holman in his how github... talk. You might be familiar with it. If not, it’s simply the idea that very few things require an immediate response, and so shouldn’t be done over a synchronous communication platform. Let the other person respond in their own time). \nHowever, I found that while the efficiency of these discussions may have decreased by making them synchronous - the quality and the immediacy of decision making improved. In my periphery, I would see one of my colleagues walk up to the wall, and I’d remember - hey, I need to ask them about X. So rather than sending them an IM, or mentioning them in a comment on the issue for X, I’d get up and talk to them then and there. Having this central place for discussions was cool, this was actually a change that I found positive!\n
- #15 But that’s about it, because physical card walls are woeful. They are just a rubbish way to plan, manage and execute sprints. We tried - with absolute sincerity - to test it out, and it comprehensively failed for us.\n\nWhy?\nWell, within Atlassian, working remotely (either in another office or from home) is a fact of life. As an example of how much of an issue using a physical card wall was - this image was not taken for posterity’s sake. Note how’s it’s comped together from multiple photos. They were actually taken because one of my team mates had to unexpectedly work from home one day (these things happen) and needed to see the state of the current sprint so that he could get something new to work on. Taking a photo of the card wall was the only option. \n
- #16 But that’s about it, because physical card walls are woeful. They are just a rubbish way to plan, manage and execute sprints. We tried - with absolute sincerity - to test it out, and it comprehensively failed for us.\n\nWhy?\nWell, within Atlassian, working remotely (either in another office or from home) is a fact of life. As an example of how much of an issue using a physical card wall was - this image was not taken for posterity’s sake. Note how’s it’s comped together from multiple photos. They were actually taken because one of my team mates had to unexpectedly work from home one day (these things happen) and needed to see the state of the current sprint so that he could get something new to work on. Taking a photo of the card wall was the only option. \n
- #17 But that’s about it, because physical card walls are woeful. They are just a rubbish way to plan, manage and execute sprints. We tried - with absolute sincerity - to test it out, and it comprehensively failed for us.\n\nWhy?\nWell, within Atlassian, working remotely (either in another office or from home) is a fact of life. As an example of how much of an issue using a physical card wall was - this image was not taken for posterity’s sake. Note how’s it’s comped together from multiple photos. They were actually taken because one of my team mates had to unexpectedly work from home one day (these things happen) and needed to see the state of the current sprint so that he could get something new to work on. Taking a photo of the card wall was the only option. \n
- #18 But that’s about it, because physical card walls are woeful. They are just a rubbish way to plan, manage and execute sprints. We tried - with absolute sincerity - to test it out, and it comprehensively failed for us.\n\nWhy?\nWell, within Atlassian, working remotely (either in another office or from home) is a fact of life. As an example of how much of an issue using a physical card wall was - this image was not taken for posterity’s sake. Note how’s it’s comped together from multiple photos. They were actually taken because one of my team mates had to unexpectedly work from home one day (these things happen) and needed to see the state of the current sprint so that he could get something new to work on. Taking a photo of the card wall was the only option. \n
- #19 So working anywhere other than where your card wall is, is a problem. \nAlso, you lose all of JIRA’s features - persistence, search, linking, notifications. I’m just going to assume that you’re all familiar enough with JIRA that I don’t need to go into detail here.\n
- #20 Additionally, there are integration points with other products and other tools which are lost when we only have a physical card wall. Some of these were eventually recreated by - I kid you not - creating stories in GH for each card on the wall, and then having our scrum master manually synchronise between the two. This meant that we had &#x201C;issue keys&#x201D; to commit against (giving us source <-> issue linking), clever pre-filling of these keys in commit messages, and (most importantly for me) we got GH reporting back (until then, the restrictions of scrum shock therapy had our scrum master was generating burndown charts every day).\n\n
- #21 This card wall issue really got to me. The more I thought about it, the more I thought it actually represented something about scrum that just didn&#x2019;t sit right with me. To explain, I&#x2019;m going to talk about my colleague and dear friend Alex.\nAlex is a great developer, and in particular an incredibly effective and efficient developer. He is also the embodiment of this cartoon. (pause) The third time he needs to do something that he&#x2019;s already done before, he will automate. If he guesses ahead of time that he&#x2019;ll need to do it more than once or twice, he&#x2019;ll automate upfront. We&#x2019;re not even talking big things. I&#x2019;ve known him to automate away things which take 5 seconds of his time a few times a day. To him, those seconds are worth saving. Not just for the seconds lost, but also because such tasks take him out of his editor - out of his frame of reference - and break his flow, and when he comes back to his editor, he loses more time still getting back to where he was mentally.\nSo why am I telling you this? Because before we started scrum shock therapy, Alex had automated away so many of the parts of scrum (and development in general) which needlessly cost him his time.\nWhen we switched, his dev-speed (and the team&#x2019;s in general) dropped.\n
- #22 I believe that all developers are like Alex, however not all go to the same extent as him. A large part of the practice of software development is task automation - it&#x2019;s unsurprising that developers frequently automate that which can be automated.\n\nTo such people, agile can actually be seen to &#x201C;get in the way of real work&#x201D;. They see non-automatable practices such as manual card movements or report generation or needing to write an issue key on a post-it so that you can put it into commit messages, and they just think that things are wrong.\n\nFor scrum to work, the whole team must get invested in the process. Everyone needs to estimate sincerely, and genuinely commit to the contents of a sprint. If the developers feel like their time is being wasted, then they&#x2019;re not going to stand for it.\n\nCuriously, Alex actually is a proponent of scrum - he sees the value of estimation, shared commitment, velocity tracking, retrospectives and other principles. Notably, he sees this value as a sound return on investment for the little costs they have for him. However when we switched to shock therapy, the rules that were imposed on us brought added significant cost without obvious increase in value. \n
- #23 So how many of you recognise this image? It&#x2019;s from a campaign launched by Zed Shaw which rails against the very concept of software development methodologies. The campaign&#x2019;s call to action? &#x201C;We must destroy these methodologies that get in the way of...Programming, Motherfucker.&#x201D; \n\nIn my opinion, a large part of the rage in this campaign is misdirected, and (my apologies for the cliche) throws the baby out with the bathwater. Unfortunately, this is irrelevant, the campaign is popular. The damage is done when large numbers of developers start viewing scrum as a hindrance, not a benefit.\n\nBy my reckoning - the popularity of Programming, Motherfucker can be seen as a side effect of people experiencing scrum as we did in our shock therapy experiment - a series of rules which put up roadblocks between you and getting shit done. To avoid this perception, we need to justify what methodologies we do impose, and ensure that we have whole-team buy-in on them. And perhaps, instead of booking a mandatory four hour meeting, make it open ended and simply explain that you shouldn&#x2019;t rush - take as much time as is needed. Devs aren&#x2019;t children and shouldn&#x2019;t be treated as such.\n
- #24 Returning to scrum shock therapy, I just want to reinforce that I&#x2019;m not questioning their results - this talk covers my experiences based on a sample size of one, and one which is far from the intended target of shock therapy. I fully imagine that doing scrum shock therapy on a team full of people who have never even heard the word &#x2018;agile&#x2019; would have completely different results \n\nThe next time some rule is suggested which attempts to change certain behaviours, ask yourself if maybe you could get the desired behaviour by just discussing it with the team and explaining what should change and why. Be direct.\n
- #25 \n