Kick me. Kicking ScrumBut. Rowan Bunning. Certified Scrum Trainer Software WithStyle

Transcription

1 Kick me Kicking ScrumBut Rowan Bunning Certified Scrum Trainer Software WithStyle

2 There are pitfalls on the journey How can we help each other to avoid them?

3 ScrumBut ScrumButs are reasons why you can t take full advantage of Scrum to solve the problems and realise the benefits. Format: (ScrumBut) (Reason)(Workaround) Example: We use Scrum, but Daily Scrum meetings are too much overhead so we only have them once a week. Source: Ken Schwaber. What ScrumButs have you seen?

4 Some ScrumButs to avoid... Goalless, soulless Scrum Cherry-picking practices and premature process optimisation Shooting the Scrum messenger Planning paralysis Mis-aligned stories Command and control-style micro-management Individual heroics Smoke and mirror demos Lack of risk management The vicious cycle of overcommitment Stalled improvement

5 Avoid: Goalless Scrum We use Scrum but... only because [insert latest fad]. Is your Scrum implementation goalless? Why are you using Scrum? What are your pain points? What can the business expect to get out of this?

6 Try: Targeting process improvement goals Consider using Scrum to govern the introduction of Scrum

7 Avoid: Soulless Scrum Is your Scrum implementation soulless? Are you just practicing Scrum by rote? Do you have a shared vision of the future? Does your team regularly discuss Scrum values and principles? Try: Discussing Scrum values, principles and what these mean for you

8 Avoid: Cherry-picking practices We use Scrum but... only the practices that are most appealing

9 Agile methods as systems No single practice works well by itself, each needs the other practices to keep them in balance. If you follow 80% of the process you get 20% of the benefits. - Kent Beck Avoid: Premature process optimisation Source: Kent Beck.

10 Try: applying before inspecting and adapting [Apply] Scrum as proposed... for at least 3 Sprints. - Christian Schmidkonz, SAP. Doing Scrum is as meaningless (and impossible) as creating an instance of an abstract class. - Tobias Mayer

11 Shooting the Scrum messenger We use Scrum but we don t like it because it makes life more difficult. Scrum Is Scrum surfacing existing issues? Are people speaking out early? Bad news doesn t get any better with age!

12 Scrum is a mirror. - Alistair Cockburn Try: Looking into the Scrum mirror

13 Avoid: Planning Paralysis We use Scrum but we're still not confident about our plan after two days of Sprint planning! Try: Doing your homework on the backlog Grooming the Product Backlog Regular estimation sessions Getting Stories to a state of Ready 5-10% of effort preparing future work

14 Avoid: Mis-aligned Stories e.g. Building screens rather than workflows

15 Try: Sashimi slicing by value Try: Slicing by business value Being user task-centric Going end-to-end through technology stack

16 Avoid: Command and controlstyle micro-management We use Scrum but a manager keeps telling team members which tasks to do when! Q: Does Scrum involve micro-management? A: Yes! Q: Who is doing the micro-management? Thanks to: Mike Cohn Is your team empowered?

17 Try: Allowing the team to self-manage within a time-box Do: Let go! Emphasise goals Offer to help Facilitate learning Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity. - General George S. Patton, Jr.

18 Individual Heroics Individual heroics We use Scrum but individuals hoard work and boast about it!

19 Try: Team-centric reviews and incentives Try: Emphasising team achievement Dampening individual heroics Teamwork-biased incentives

20 Smoke and mirror demos Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes....when someone inspecting a process believes that something is done; it must be equivalent to their definition of done. - Ken Schwaber, The Scrum Guide We use Scrum but... what you see isn t quite done.

21 What you can t see... Try: Not demoing features that aren t truly done

22 Avoid: Lack of risk management Requirements Analysis Design Code Integrate & System Test First build and deliver Potential Impact of Risks being tackled Highest risk activities such as integration, system testing, load testing are tackled late Time First build and deliver Iterations All activities are tackled early Potential Impact of Risks being tackled Integrate & System Test Code Integrate & System Test Code Integrate & System Test Code Integrate & System Test Code Integrate & System Test Code Design Design Design Design Design Analysis Analysis Analysis Analysis Analysis Time Source: Craig Larman, Agile & Iterative Development, 2004.

23 Scrum risk reduction strategies Risk of... Scrum Strategy Not pleasing the customer Customer sees product constantly. Customer on-site. Not completing all functionality Develop in priority order. Poor estimating and planning Not resolving issues properly Not being able to complete the development cycle Taking too much work and changing expectations Small estimates tracked daily. Review and adjustment every iteration. Active daily management. Bi-directional reporting. Delivery of working software every iteration. Team forced to confront issues early. Clear goal and scope each iteration. No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, Is it sufficient to rely solely on these built-in strategies?

24 Try: Creating a safe-fail environment Time-boxing Areas of risk/ uncertainty early in release cycles Prioritisation bias towards areas of risk Spikes to reduce uncertainty Last Responsible Moment planning Learn quickly

25 Try: Collaborative risk management Risks Strategy Mitigating set aside time and money to pay for the risk should it materialise e.g. plan for training on new tools Containing Evading bet on the risk not materialising e.g. accepting not having a dedicated team Avoiding take steps before the risk materialises to reduce the containment costs e.g. move feature to an earlier sprint don t do part of the project that entails the risk e.g. avoid platform upgrade Thanks to: Slinger, M., Broderick, S., The Software Project Manager s Bridge to Agility, Addison Wesley, 2008.

26 Avoid: The vicious cycle of overcommitment We use Scrum but we don't have time for bug fixing or process improvement because we have too many new features to

27 Try: Snapping out of overcommitment! Raise visibility, get buy-in, create a sense of urgency, action!

28 Stalled improvement We use Scrum but we've still got the same issues that we had a few sprints ago! Are you suffering from the three meeting syndrome? Avoid: Superficial 15min retrospectives only

29 Try: Deep reflection & correction Keep Problem Try Puzzles 1. Set the stage 2. Gather data 3. Generate insights 4. Decide what to do 5. Close the retrospective Reference: Derby E., Larsen D., Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, 2006.

30

31 In Summary... let s not dilute Scrum Agile development is like teenage sex. Everyone says they're doing it, but only 10% are. And those who are -- ARE DOING IT WRONG. - The Hacker Chick Blog

32 Remember... If you re not having fun, you re not doing it right! - Joseph Pelrine, CST and Social Complexity Scientist

33 Your moment of Scrum Zen Work towards: High performance teams Harmony with your environment and its challenges Your fitness peak

34 Try... Targetting process improvement goals + discussing Scrum values, principles and what these mean Applying before inspecting and adapting Looking into the Scrum mirror Doing your homework on the backlog Sashimi slicing by business value Allowing the team to self-manage within a time-box Team-centric reviews and incentives Not demoing features that aren t truly done Collaborative risk management Snapping out of overcommitment! Deep reflection and correction

35 I m Thank you keep in touch Rowan Bunning Rowan.Bunning@softwarewithstyle.com