Agile Scrum Framework: 4 Ways to Create High-Quality Software, Part 1

Heard of the Scrum framework? It’s exceedingly popular for its unmatched success in solving complex software development problems. Scrum, however, only implies the need for high-quality solutions and doesn’t actually suggest how quality should be addressed. Here’s my take on it:

A Scrum implementation focused on continual quality and technical excellence is more likely to succeed than one that isn’t, and quality is everybody’s responsibility.

The motivation behind this blog series was the clear void around how to ensure software quality in the Scrum framework. So in it, I’ll discuss four ways to turn up the volume on quality in your Scrum implementation. For starters, I suggest you:

• • Use a cross-functional Scrum team
  • Commit to a “DoD”

In the next post, I’ll explain why you should:

• • Embrace developer feedback loops
  • Execute 3 key Scrum practices

This is just the tip of the quality iceberg but it gives us the chance to discuss some ideas, both cultural and technical, that will heighten the quality of your software. Let’s get started!

1. Use a Cross-Functional Scrum Team

A team constructed with a cross-disciplinary skill set can be given a complex problem to solve and deliver an increment without any external dependencies. In other words, the only hand-offs that happen occur directly within the team. This is critical to the quality of your software because it’s designed, developed, and tested without introducing risk or dependencies from outside influences. But before you can benefit from a cross-functional team, you need to understand how one works.

The only title that exists on a Scrum team is developer. Why? Because everybody on the team develops something and individuals on teams should be prepared to overlap their skills. I’m not suggesting, however, that everybody specialize in everything or be a generalist.

Instead, we call everyone a developer to re-enforce the concept of T-shaped individuals in the workplace. A T-shaped individual can be described as someone who has a depth of experience in one area (the vertical line) but also has a breadth of knowledge in other areas (the horizontal line). Unlike component teams that introduces external dependencies due to lack of breadth, a cross-functional Scrum team comprised of T-shaped individuals diminishes dependencies, which means you can better ensure quality software.

To demonstrate this concept, let’s imagine a team that needs to deliver data through web services to a front-end web user interface:

• • Developer #1
    • • Depth: Web Development
      • Breadth: Scrum
      • Breadth: Web Services
  • Developer #2
    • • Depth: Data
      • Breadth: Web Services
      • Breadth: Front-End Web Development
  • Developer #3
    • • Depth: Web Services
      • Breadth: Front-End Web Development
      • Breadth: Test Automation
  • Developer #4
    • • Depth: Quality Assurance
      • Breadth: Test Automation
      • Breadth: Front-End Web Development

You can see the skill overlap and variety in depth. It should also be noted that all individuals are involved in development from beginning to end. You no longer wait until the end of the development process, for example, to bring in developers with a depth of knowledge in quality assurance or expect individuals to be exclusively used during specific phases of a project. Therein lies the benefit of using a cross-functional Scrum team to ensure quality software development.

2. Commit to a “DoD”

How does a Development team using Scrum know when they’ve delivered a quality increment of software? By defining what “done” means, of course.

At the onset of a Scrum project, a team should decide how they’ll consider the increment production ready by creating a Definition of Done (DoD). Note that it’s the product owner’s decision when to actually release to production. One aspect of “done” is the expectation of quality. A team’s first DoD will be immature but it should still include distinct quality rules. An example of a brand new DoD might be:

• • Fulfills all acceptance criteria
  • Has been peer-reviewed
  • Is liked by the product owner
  • Has been thoroughly tested
  • Is checked in

As time passes, a Scrum team will frequently inspect and adapt this artifact. Changes to the DoD can be debated during Sprint Retrospectives so that, several Sprints into the project, a team’s DoD might have matured to:

• • Acceptance criteria has been automated
  • Code is checked in and has been peer-reviewed
  • Product owner approves of it
  • Automated Testing occurred at appropriate levels (unit, integration, performance, etc.)
  • Code’s checked in
  • It’s been deployed to the test environment
  • All testing passes

At the end of the day, the DoD is a quality contract for the development team. An artifact of the Scrum framework is an increment at the conclusion of a Sprint that’s inspected by the Scrum team with stakeholders. The DoD ensures consistency in what was produced and considered to be “done” in that increment. Not adhering to a DoD for any reason is trading short term gains for long term losses. Work that doesn’t meet the DoD shouldn’t be accepted by the Scrum team and it shouldn’t be part of a demo in a sprint review. You’ve set your bar for quality, so make sure you reach it.

Congratulations! You’ve made it through the first half of The Scrum Team: 4 Ways to Create High-Quality Software. We’ve discovered how using a cross-functional team and committing to a DoD can guide Scrum teams to successful software development. But we’re not done yet! In my next post, I’ll explore how developer feedback loops and Scrum-related practices enable a team to create an even sturdier foundation for a high-quality product build.

Do you practice Agile Scrum methodology and attribute certain practices to your success? I’d love to hear about your experiences!