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?

  • 3
    Is this person afraid he will be blamed or "held accountable" for bugs or rework? That can certainly be a contributing factor.
    – Todd A. Jacobs
    Commented Sep 1, 2015 at 0:55
  • It's hard to tell who's "in the right" here. Doing Monolithic features doesn't sound very iterative. However, continuing on to new features without fixing bugs sounds pretty bad as well.
    – Nathan
    Commented Sep 1, 2015 at 10:51
  • @CodeGnome I do think that's part of it. His team does infrastructure work for the rest of the development teams, so it can be difficult to protect the team from harsher criticism.
    – Aaron F
    Commented Sep 1, 2015 at 15:00

4 Answers 4


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.

  • 1
    We talk about the importance of completing work in a sprint in retros and even just throughout normal day-to-day conversations. What ends up happening is that since he doesn't "get it," he will sometimes just keep a story hostage and there's not much anyone can say that will make him give it up until he thinks it's done. I think this is a nice, broad set of solutions for me to try out with the team. Thanks!
    – Aaron F
    Commented Sep 1, 2015 at 19:20
  • 1
    Aah, right, that does sound like something that needs fixing. If it prevents work getting done, action is needed. Good luck!
    – upstream
    Commented Sep 2, 2015 at 8:02

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.


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.

  • 1
    I would recommend a similar approach to this, and you could use test cases, acceptance criteria or even sub-features to help frame the conversation. For example, if you look at Feature 1, Test Case G, is addressing that going to be more or less valuable than Feature 2 Test Case A, B, C etc. Commented Sep 1, 2015 at 15:24

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.

  • I'm just nitpicking, but it always bugs me to see "TLDR" summaries at the bottom of a long post. Doesn't it make more sense at the top? If it's too long to read - I'll never see your summary, since i have to read through the whole thing before I get to it. I do like the points you make about having the right systems in place to instill confidence to commit code.
    – CBRF23
    Commented Sep 3, 2015 at 5:30
  • fair comment... Commented Sep 3, 2015 at 8:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.