AGILE IN ACTION

Friday, 13 January 2006

Task-switching is waste

Posted by Simon Baker
Tags: agile, lean

I’ve worked with a few companies where it was common practice for developers to work on more than one project concurrently. Guess what, parallel software development doesn’t deliver projects more quickly, even if they’re small projects. Task switching from one project to another incurs a cost in the form of a time penalty and impacts productivity. When there are a number of projects to complete using the same resources, they’ll be delivered more quickly and usually with better quality if they’re developed sequentially.

In Lean software development task-switching is waste. Every time a developer switches between tasks, about 15 minutes is required to enter the flow of the new task. When frequently interrupted, frustration kicks and more time is required to calm down and become settled once again. If a developer is working in a group or pair programming there’s a productivity boost due to binding and working on a common goal. This is lost when one of the developer’s switches tasks. In his book Slack , Tom DeMarco defines the penalty of task switching as:

Task-switching penalty = Mechanics of moving to a new task + Rework due to an inopportune abort + Time to enter flow + Time to defuse frustration + Loss of group binding effect

Task switching increases busyness but most of it is thrashing, non-productive and ineffective work.


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)
  7. 2006 (128)
    1. December (16)
    2. November (26)
    3. October (7)
    4. September (11)
    5. August (7)
    6. July (7)
    7. June (4)
    8. May (4)
    9. April (4)
    10. March (4)
    11. February (14)
    12. January (24)
      1. Look after your product backlog
      2. 1-week iterations
      3. Root cause analysis using 5 Whys
      4. Agile In Action is now available at Artima
      5. Planning with the Horizon of Predictability
      6. The knowledge worker and the new organisation
      7. Setting Norms to help internalise Agile values
      8. Agile is ... Agile isn't ...
      9. It doesn't have to be about business value
      10. Task-switching is waste
      11. Flow, ideal time and the E-factor
      12. A Scrum Master is like a music conductor
      13. Slack != Waste
      14. Go on. You know you want to. Say 'Hello'
      15. Spike
      16. Why agile principles are important
      17. Pareto Principle
      18. My interaction style
      19. An 'aeroplane in flight' metaphor for agile tracking
      20. A Scrum Master is like a skilled helmsman
      21. Fun and games
      22. Innovation games from enthiosys
      23. Thomas Edison on 'Lean'
      24. The speed of thinking
  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)