Managers get a bad rap when conversation turns to context switching. Johanna Rothman indicates they may have forgotten what development is like. Tom DeMarco in Why Does Software Cost So Much (If We Did Only One Thing to Improve …) states “I’ve come to believe that fragmentation is due mostly to managerial sloppiness.” (pg 90).
How do the environment and corporate culture impact managerial decisions? In what context does development context switching make sense? Here are three situations that make sense to me. (And I’m on the developer’s side of this discussion!)
1. Specialized skills. This would be those people that management is lucky to have one of, and their existence has to be spread across several projects to justify their existence. DBAs, architects, object specialists. Would agile coaches be included?
2. A project is completed, the programmers moved on to the next project and:
– a defect is located that needs to be corrected.
– the client requests a series of improvements.
Who better than the original developer(s)?
3. A developer hits a wait state based and can’t move forward until something from someone else arrives. Why not let them get started on something while they’re waiting?
I may be idealistic, but I don’t believe managers purposefully create situations to lower productivity.
When the manager kicks off context switching, the actions make sense at that level. But systems are multidimensional, and his/her decisions impact other people. Congruent action contains three parts: self, other, context.
For context switching to be congruent, the manager needs to consider how the context switching affects the developer. This best way to find this answer is to ask. Anything short of “How it affect you (and your productivity) if I ask you to …?” involves mind reading, or how the manager THINKS the developer will respond. When the manager has this information, they can make an informed decision.