Super charge productivity, scheduling interactions using ‘Team Time Warp’
Team Time Warp is an application which I’ve been working on for the past few months. It aims to find out if human interactions within a team of Software Engineers can be loosely ‘scheduled’ to minimize context switches between the actual interactions and the code related tasks that the engineers work on.
What does this fairly abstract paragraph mean? Well lets give an example. Lets say we have a Software Engineer who is ‘in the zone.’ The engineer feels as though everything falling into place, new code is flowing out, and unit tests are turning green one after the other. It’s taken a little while to get up to this velocity but there is no stopping him now!
Whilst the engineer is working he keeps a mental mapping of all the functions which require modification, variable names, tests, edge cases and so on. Imagine that whilst at full mental strength the engineer is suddenly interrupted by another member of the team who asks for help with an unrelated task. Because the engineer is a team player and a generally nice guy he decides to help his colleague out.
Mentally, to deal with this interaction, the engineer has to ‘context switch’ to the new task. The engineer puts all of that temporary information gathered whilst working on the current development task into ‘mental storage’ and switches over to the new task. He spends a couple of minutes and explains to the colleague his thoughts on the unrelated subject and once both are happy he gets back to the development task at hand. The engineer now has to “collect his thoughts” and restart.
This paper (http://interruptions.net/literature/Altmann-CogSci04.pdf) calls the time it takes for the engineer in the above example to get back up to full pace the ‘resumption lag.’
A chart comparing the time taken to resume a task after naturally taking a break (black) vs the time taken to recover from an unnatural context switch (white).
The result of the resumption lag is not just a loss in productivity but the engineer may forget something during the context switch, i.e the engineer may not bring every detail out of ‘mental storage’ and often specific details about the task can be overlooked, this can manifest itself in a bug within the codebase. We have all experienced this in one way or another! Whether it be when you are writing a detailed email, or writing formulae in a spreadsheet. Sometimes when proof reading an email and making a correction you remember back to the point at which the mistake was written and you can attribute it to a context switch.
During my time working in software I found time and time that these interruptions were happening, not just between developers, but with support, business analysts and project managers also.
What if there was a way to ‘loosely schedule’ these interactions so that they only occur when the mind is at rest? What ‘Time Warp’ tries to do is delay interactions until engineers have come to a natural stopping point, but how does it do this?
Ideally the Time Warp software needs to know when you are at full mental velocity, it can then ensure interactions are delayed until your next natural ‘break’ period. How can this be modelled by a computer program? Well firstly the system would need to know when an Engineer starts working on a task. For most Software Engineers they start their ‘work’ sessions by navigating through the code before making a change. Given this basic premise I needed some way to trigger Time Warp during this navigation process, so I wrote a plugin for the development environment we use (Visual Studio). Automatically a work period is triggered when the engineer actually starts working, without stealing focus or popping up an annoying dialog box.
Screenshots showing integration of Team Time Warp into the Visual Studio IDE.
Ok so that’s cool, but how does Time Warp know when you are coming to a natural resting point? For this I looked at various studies and popular time management techniques. Evidence shows that taking regular breaks from mental tasks improves productivity and creativity, and that skipping breaks can lead to stress and exhaustion, could this regular break methodology be the key tracking mental velocity? Time Warp relies on the breakdown of work into small regularly timed chunks of between 25 and 40 minutes. After a work period the user is encouraged to take a break. It is during these break periods when Time Warp ‘schedules’ interactions.
My mental pace throughout the morning with regular breaks – Where you see the red line (after the second peak) is where I have an interaction without a forced context switch.
Ok brilliant, so we know when we start and end periods of high mental velocity, how can a colleague grab my attention in one of these rest periods? The ‘team‘ aspect of Time Warp is in it’s dashboard. It displays the current work/ rest situation of all the engineers in the team. This information can then be used to schedule interactions with colleagues:You’ll get a notification when it’s safe to interrupt!
Local vs. global optimization.
Okay so that’s great, no interruptions. Engineers can get on with their work until such a point in time when they naturally require a break from code related tasks, but doesn’t this lead to an imbalance where some engineers become more productive, whilst others, junior developers for example, who may be more dependant on others now start to drop off in productivity? Interestingly I have found out opposite…
1) The wait time and encourages team members to ‘dig a little’ for the answers to their questions, lets say that an interaction is scheduled in 15 minutes, the ‘waiting’ team member can use that 15 minutes to gain more experience around the issue. This little bit of digging acts as a knowledge sharing catalyst for the conversation they are about to have, thus making the interaction more effective.
2) Time Warp doesn’t just have to be used by individuals, it can (and should) be used in conjunction with techniques such as pair programming and code review processes. It should be used to break up design meetings, peer reviews, estimation sessions and retrospectives into small chunks of time. How many times have you seen an estimation session starting out with great estimates for the items discussed first, and then progressively more poor estimates for items discussed later on..
Want to take part?
If you and your team are interested in taking part in the study please drop me a message stating the following:
1) who you are and what your team does
2) How you currently measure the progress of your software project
3) What development environment you are using