You’ve got to have SOME standards

Well-defined, agreed upon standards are key to successful development using scrum. When you convert from waterfall to an iterative process, standards replace a lot of the requirements that you historically included in your specifications. They also govern team processes and at a more micro-level than the scrum broad rules do.

At Streamline Health, when we form a scrum team, their first sprint is a “Sprint 0” during which they form their standards. As a group they determine what their definition of done should be, including what specific standards each item they produce must adhere to.

It’s not a wide open field. We have some best practices and some required processes in place that apply to all of our scrum teams, and some even apply to our dev ops teams. For example, manual testing must use our testing tools and maintain traceability between defects and requirements. Teams must show test metrics during the sprint demo. Our management tool, Microsoft Team Foundation Server, is configured with standard queries for all teams and products so that anyone can understand what’s in the backlogs for all of our products. Teams do not have the leeway to change these.

More technical standards do vary from team to team and product to product depending on the age of the code, the predominant language, and even whether it’s web based or thick client, SaaS or premise installed. Unit test code coverage, test automation, coding standards for architecture and design, code commenting, source code structure, and database structure can all vary among our teams.

Quality of Service standards, what you may think of as non-functional requirements, are a mix of enterprise-wide and product-specific (e.g., branding is enterprise wide, but other GUI requirements are specific to the product).

In a recent lunch and learn, members of all of our scrum teams came together to discuss the state of their teams’ standards:

  • When did they last review them?
  • Do new members have to read them before getting to work?
  • Does everyone know where to find them?

The result of this frank, honest discussion was an agreement for teams to review their standards early and often, use the sprint retrospective cadence as an organic milestone to refine standards and reinstate a neglected process of “retrospective of retrospectives” wherein the scrum masters come together to share global improvement opportunities – including scheduling review of standards in the next HIP sprint.

— Luis Lira, Manager of Business Analysis