AGILE IN ACTION

Wednesday, 7 March 2007

Adapting Scrum without compromising it

Posted by Simon Baker

Via InfoQ , Jason Yip

Tobias Mayer recently described some successful adaptations he’s made to Scrum .

Jason Yip summarised:

  • Don’t separate the technical and non-technical members of the team.
  • Shorten iterations (1 month is too long) and focus on end-to-end cycle time.
  • Use smaller tasks instead of task estimation.
  • Make tracking visible in the workspace.
  • Quality engineering practices are not optional.
  • Process leaders should make themselves unnecessary.
I totally agree that 1 month is too long for an iteration. When I first started doing Scrum, we used 30-day sprints and I quickly saw student syndrome set in. We tried 2-week iterations and had some improvement but I still saw people take their foot off the gas in the first week and then struggle to make it up in the second week.

You can’t beat 1-week iterations . They force everything to be smaller. Complexity is broken down by smaller user stories and they can be estimated with less inaccuracy. A great visual indicator of progress is a steady rise in running tested features as stories hit the done column every day. Planning games are shorter because you do less in a week. And by the time you start you need to be thinking about finishing because iteration reviews come fast, so communication is more intense. You get to inspect and adapt every 7 days, and celebrate success 4 times in a month as opposed to once. And this builds momentum .

I don’t like planning with tasks because, when user stories are small (typically 1 to 2 days of effort), tasks belong to the developer-pair. They form a ‘private’ to-do list that reflects how the developers will get the story done. Planning and tracking these tasks is micro-management.

These adaptations do not compromise agility . They amplify it.

I’m not sure that the Scrum Master role isn’t always necessary, though. I agree that the coaching/process-leader role can become redundant when a team achieves the ability to self-organise. But the facilitator role that the Scrum Master also fulfils remains important even within a self-organising team .

Creative Commons Licence

Recent Posts

  1. System failure is inevitable so design for a fast recovery
  2. Delight comes as a surprise in unexpected places
  3. Help create business agility. Bake quality in
  4. Governance - Friend or Foe?
  5. 70% Forum
  6. Measuring purpose. Measuring customer delight
  7. Stop pushing features and start delighting users
  8. Lost without a goal
  9. Emotion creates the common language
  10. Five sneaky ways to kill an initiative

Archives

  1. 2012 (16)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
    1. December (11)
    2. November (7)
    3. October (17)
    4. September (8)
    5. August (7)
    6. July (13)
    7. June (15)
    8. May (24)
    9. April (14)
    10. March (19)
      1. Agile Alliance on Certification
      2. Saying 'No' doesn't have to be mean nor painful
      3. If everything is equally important, then nothing is important
      4. It's a stragedy
      5. Ready-to-go agile team
      6. Calling in well
      7. United Intent: Teams not groups
      8. Developing business awareness and acumen
      9. Multitasking is a way to avoid prioritisation
      10. Pull the wool over your eyes
      11. The scene about agility in A Few Good Men
      12. Don't skip the Prime Directive
      13. Adapting Scrum without compromising it
      14. Regular successes build momentum
      15. Agility and adaptation
      16. Go with the flow and find happiness
      17. Anti the anti team
      18. We're not limited by our abilities, but by our vision
      19. Offshoring is wasteful
    11. February (7)
    12. January (10)
  7. 2006 (128)
  8. 2005 (63)
  9. 2004 (2)

Tags

agile (43) big visible chart (15) conference (40) culture (18) extreme programming (21) leadership (18) lean (47) people (26) planning (17) retrospective (18) scrum (41) story (19) team (30) testing (19) xpday (19)