Perfectionists in scrum

Question

I am a scrum master for a team that includes an engineer who is a perfectionist. He has trouble letting issues become done, even after we've focused as a team on ensuring that acceptance criteria capture what we'd like the story to encompass. In the work itself, he constantly prefers a not-so-Agile method of constructing a monolithic feature and pushing it out once he thinks every obscure corner case has been addressed.

He's open to conversation, which I've tried to have about this. But he's a very logical person and is difficult to convince without gold plated reasoning. What are effective ways of dealing with this kind of person within the context of Scrum?

Answer 1

Does this pose any problems? If the work is getting done in time, the quality is good and the team experience no issues due to his working methods, maybe it's not really a problem?

Assuming it is problematic:

1. Retrospectives. Address the problems it's causing during the retrospective. Let the team discuss the issues and propose solutions. To me this is by far the first and best thing to do.
2. Split stories. As Daniel already pointed out, make stories smaller so there's less room for scope creep.
3. Team effort. Try to stimulate teamwork on stories. Working together on stories makes the team discuss what needs to be built, and focus more on the definition of done.
4. Pair programming. Expanding on teamwork: introduce pair programming so the engineer won't be stuck on his own 'island'. Let him learn from other engineers who apply a different focus when working. Maybe there's also someone who can learn from his attention to detail?
5. Scrum workshop. Maybe it's good to take a few steps back and have a day of scrum 'refreshment' course. Why are we practicing scrum again? Why do we want to get stuff done? What are the benefits to all this again?
6. Extreme programming: Try to get his interest in Extreme Programming to get the agile mindset going. XP has a somewhat more technical stance on agile development. It's more focused on actual development practices (test driven development, pair programming, etc.). As an engineer with attention to detail, perhaps he will like a more techy approach?

In any case: don't force or lay down the law. If there are problems, the team should discuss them during retro. They should also decide as a team how to address these issues.

Answer 2

Without getting to sit down and talk to this person directly, I can't be exactly sure, but it sounds like there are two things that may be happening here:

1) It's possible that the work is in fact much larger than the rest of the team realizes and that's why you're running into these problems. There are two actions that can help with this. First, ask him to bring up the concerns during backlog refinement and planning so the team can address it. Second, ask him to lead breaking the story down smaller to build pieces to a high level of quality but allow it to still fit in the sprint.

2) It might be a trust issue. Many people look to monolithic architectures and large upfront design efforts because they feel like if they don't do everything exactly "right" up front, they will be forced into making sub-par systems that they aren't happy with. In truth, the developer has much more control over this than they think, but if the trust problem is there, you still have to address it. Picking small cases where the PO can ask for a little faith that he'll keep the other stories in and then following through on that promise can help build trust.

It could be either of these things or both. That'll be really on you to determine.

Answer 3

In these situations I like to discuss with the developer the value they add by their work. The question is, will they add more value by addressing edge cases for a given feature or by developing the core elements of another high prioirty feature?

Of course this discussion cuts both ways. If the developer has sound logic for why the edge cases deliver value then I would conceed the point.

Answer 4

TLDR: small stories, promote good architecture and OO principles, extra attention to defining and scoping stories, good test and CI practices to promote confidence and minimise business impacts from mistakes.

It's a little to hard to drill down into how big a chunk of code this guy insists on delivering, if he really insists on committing big features in one go then he would only deliver anything every several sprints - obviously this is not agile.

But, "every obscure corner case has been addressed" could describe good defensive coding to avoid bugs. If this one guy takes longer than anyone else to deliver a story just because he is writing robust code, that suggests that the reason everyone else gets it done quicker is because they are not!

Still, aim for smaller stories to encourage smaller delivery chunks - in a typical web stack feature you could go as granular (or more!) as a story each for

• Database
• Domain
• Service
• Front end

Note that a poor or poorly enforced architecture and poor adherence to code quality and OO principles in a code base can make it harder to deliver in chunks as the far reaches of the codebase become excessively coupled - what's yours like? The worse the code is the harder you need to try to keep stories small, and the more investigation "spikes" you may need to correctly define and scope those stories.

Another possibility is a lack of confidence in committing code leading to hesitation and paranoia. Having good unit test coverage, automated testing, a decent CI setup, and a rapid and thorough regression cycle all help developers feel more confident to commit code as mistakes are less likely and less catastrophic.