Organizations, especially organizations with a recognized brand, have various standards for software. This includes things like security, usability, code quality and readability, UI design, test automation and so forth. In our organization we have a lead for each of these areas. Each lead is a very experienced individual and is trusted by management. Each lead is responsible for the software to meet the standards in the lead's area of expertise.

The Scrum Guide says: "Development teams are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;"

My question is how can an organization trust teams to produce a product that meets the various standards mentioned above, if the leads (trusted by the organization) have no ability to enforce the quality in each of the areas?

2 Answers 2


The typical place where such quality standards are enforced is in the "Definition of Done" that the team uses. The "Definition of Done" is essentially a checklist that you go through to see if all the necessary work on the story has been completed and has been done to the quality standard that the team has agreed to maintain.

If the teams already have experience with applying those standards to their work, then it should not cause any burden to require that the software conforms to all those standards in a verifiable way at the end of a sprint.

If the team doesn't have experience with applying those standards, you might want to introduce them one or two at a time.

In essence, when using Scrum, the entire team becomes responsible for applying those standards. The current leads in those areas would get more a role of an advisor and reviewer, advising the teams on how to apply the standard and verifying that it was done properly.

  • We have experience in conforming to these standards, but the leads always review the work to make sure it indeed met those standards. But the Scrum Guide says that no one should tell the team how to do their work. So how to reconcile that? If the leads will continue to review the work, wouldn't it reduce the autonomy of the team, reduce motivation and such?
    – Eugene
    Jun 19, 2014 at 10:35
  • @Eugene: What is meant by that statement from the Scrum Guide is that it is the team's responsibility to decide who implements which part and who does the testing. It does not mean that the wider organization can't put quality requirements on the produced work. Some of those might even be driven by requirements from regulatory bodies and prevent sale of the product if they aren't met. I don't see why such constraints, or their verification, would lower morale. Jun 19, 2014 at 10:47

The lead is there to lead, not dictate or enforce. If he is trusted and respected by his fellow developers why wouldn't they listen to him? And if the lead can't trust his fellow developers, then there's a deeper problem.

These teams should have working agreements and an agreed upon definition of done. These are the things that help enforce quality and process within the team.

Picture a scrum / agile environment where someone could just walk in and say, "This is how I want it done! Do it this way!". Now, I'm not saying that this doesn't happen, but it shouldn't. This is why the guide states what it does.

The guide isn't taking away anything from the lead, and it is infact fostering a better environment based around teamwork. The lead's ability to "enforce" is based upon trust and respect of his teammates. Otherwise, what good is it?

Scrum is also not just a hard set of rules; YMMV.

  • And what if a team member doesn't want to add that security feature because the team member doesn't think its important? Usually this happens because some developers don't see the entire picture. In this case, shouldn't the security lead enforce the decision?
    – Eugene
    Jun 19, 2014 at 13:09
  • The lead should probably let the developer know what the larger picture is, first of all. Is proper security part of the definition of done? Then the team member is violating the principles the team has set before themselves. Also, that part of the Scrum guide isn't terribly related to implementation and technical quality. Review processes, with two way feedback, should be in place.
    – BrandonV
    Jun 19, 2014 at 13:12

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.