AGILE IN ACTION

Thursday, 12 January 2006

Flow, ideal time and the E-factor

Posted by Simon Baker
Tags: agile

In their book Peopleware: Productive Projects and Teams , Tom DeMarco and Tim Lister describe flow as a highly productive state of concentration. It takes around 15 minutes of concentration to enter flow and during this time you’re not really doing work. Each time you’re interrupted your flow is broken and it’ll take another 15 minutes to re-enter it. A metaphor here would be having to shift down the gears to negotiate the obstacle or interruption, and then having to gradually change up again until you reach cruising speed and enter flow .

Clearly what matters is the amount of time spent in flow and not the amount of time you’re present. Flow-time is ideal time , which was introduced as a unit of estimation in Extreme Programming and was defined as the time where you can concentrate, working on a task without interruption, and be fully productive.

When recording effort, instead of logging elapsed time (which includes everyday overheads such as meetings, phone calls, responding to emails, task switching, etc), developers should log the ideal time spent working on a task. When tracking ideal time , developers become acutely aware of the time they spend in flow , the level of interruption they are subjected to and its effect on their productivity. Based on their empirical tracking data, they should expect a certain amount of ideal time each day and they should protect it.

The ratio of ideal time to elapsed time is known as the Environmental factor or E-factor :

E-factor = Ideal time / Elapsed time

Where ideal time and elapsed time are both measured in the same unit, either days or hours.

When the ideal time is a reasonably high proportion of the elapsed time, the environment can be considered conducive to developing software because it allows developers to get into the flow when they need to. Here’s a graph showing our E-factor over the last 8 sprints.


E-factor
Originally uploaded by sjb140470 .

Compared to previous development environments that I’ve worked in, I consider our E-factor to be blissfully high. The reason for this is simple: We are a contracted development team working at the client’s site to deliver a specific project. Given the importance of the project to the client, we’ve worked effectively with their Product Owner but otherwise they’ve trusted us and left us alone to get on with it.


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)