in
Forums
Hi all. I share management of a team of about 25 software engineers, and the topic of context switching has come up. I struggled with how to offer great ideas and a plan for my direct.
The background:
We work in software development on remote teams spread between the United States and Brazil, agile methodologies. Its a large solution, so its very common for engineers, especially developers, to be expected to discuss and execute work on different parts of the solution on an ongoing basis. For instance....meetings on one bit of upcoming work in the morning, analysis on an upcoming defect fix a bit later, executing/coding on your previously committed work in the afternoon. Repeat.
So the upside....this is the general approach for a reason. We want people to get exposure to how more senior team members solve problems across our large domain. We dont EXPECT them to be fast and efficient at these tasks in new areas, but we dont shy away from involving them for awareness and learning. Usually, this means things are a bit chaotic for the first year (or even two), then things become more second nature, and the stress from bouncing around disappears as knowledge of the whole solution is gained.
The ask:
So what sort of advice or change in process can I offer a direct who is experiencing an uncomfortable amount of stress due to this type of context switching on a remote team? I think there may be some field agnostic aspects to a good answer for him, but also any thoughts on managing context switching in software engineering would very welcome. Its a field thats consistently shown to have a higher context switch cost (i.e. it takes longer to get into a 'flow' state relative to other disciplines, like management :))
So what's the main pain?
Generic strategy regarding context-switching in software development: don't. ;-)
This might express in several different ways: one project at a time; one type of work during a day or week; stable team composition across sprints or months; one feature at a time, from conception through deployment; no meetings outside the team of 4-8 people during afternoons; one thing at a time (kanban's "work in progress limit"); reduce/eliminate delays between an action and its feedback; and so on.
Most of the software teams I've led or been on have been collocated, as best as size allows, but being remote didn't change most of the basics. Juniors pair with seniors to learn the system, and everyone pairs with everyone to get work done. Visible sprint backlogs time-box functional progress and let non-technical folks see when to expect the next increment. Estimates, if any, come from the technical team doing the work. Not everyone needs to know everything about the system, just enough to fit their portion into the whole (eg "device-driver writers don't need to know how to refine the compilers or implement the debuggers, but all contribute to the operating system that several thousand of us are working on").
If you're in Scrum, ask your Scrum-master to help out. If in Extreme Programming, this should come out in retrospectives or the daily rhythm of pairing. Otherwise, or if that's not enough, ping your local Agile coach, or engage one.
Some good points in there,
Some good points in there, thanks. We do struggle w/ 'one feature/thing at a time', though on the other points we seem to be setting the engineers up for success (reserved focus time during the week, reducing WIP, fast feedback cycles, etc.).
I'm not sure how we can get to 'one feature at a time'. Story and feature refinement occurs on a cadence and really could mean bouncing around to plan the future. On the work side, we do get bugs and one-off stories mixed into our sprints. The team does a decent job of factoring the lack of familiarity in a new area into the estimates for this work. Still, this engineer (and some others) mention struggles with this switching of context.
Still a bit lost as to what to tell him. Hmmm....