As we all know, software development is difficult. One reason teams consider adopting agile is to manage risk and improve predictability during development. Evaluating the effort it takes to get things done is part of predictability. Agile estimation is a process that teams refine over time. However, even with a feedback loop, estimation can be challenging.
Consider this exchange about an engineer who was told that he was not fixing problems quickly enough. It is possible that some situations like this arise because of malicious or inept managers who are trying to motivate by emotional hijacking, but this also illustrates some of the challenges in estimating. Two of the factors in estimating effort are the skill of the people working on a problem and the difficulty of the problem. Neither is easy to figure out.
Some problems may be more difficult than they appear, and some solutions may appear to be more effective than they really are. Sometimes people appreciate throughput more than thoroughness. A classic issue organizations face when adopting agile software development is accounting for the cost of developer-testing practices, such as unit testing and test-driven development. While “more testing” often sounds good (even though it isn’t always), some organizations seem reluctant to either incur the costs or appreciate the benefits.
It's difficult to evaluate the skill of problem solving. What you measure can also affect how effective people seem, and the perception may not align with your real needs.
If you measure the rate at which issues are closed in a tracking system, you can favor simplistic solutions that lead to issues being re-opened. If variations of a problem are treated as multiple problems rather than the same one, “fixing” one quickly and waiting for the edge-case to appear as a new issue can be rewarded. Depending on the metric, your results will look different. But the state of your system will probably look similar, regardless.
The relationship of skill to a problem's difficulty is also a challenge to evaluate. A recent study showed that higher grades were more common in less challenging situations. Even though you might prefer the person who performed well in a tough situation, there appears to be a bias toward the ability to solve easier problems.
Sometimes, having the apparent ability is just a matter of timing. We all have off-days; my colleague Naomi Karten offers some suggestions for getting out of slumps at work.
With these questions in mind, it’s worth thinking about what your assumptions are when you feel like a person (or a team) isn’t meeting expectations. Is the issue you are facing related to skill, an external constraint, a misunderstanding of the complexity of the problem, or do your team members have differing expectations about what “done” means?
With the right context, you can focus on solving problems. Without it, the best you can do is try to establish blame.
How does your team deal with a team member who is not meeting expectations?
Steve Berczuk is a Principal Engineer and ScrumMaster at Fitbit in Boston, MA. He is the author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, and has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT.