Our Thoughts

  • Elegant Software Solutions

SOLID Scrum: Single Responsibility Principle

Updated: May 29, 2020

Lifelong learning has me studying the hows-and-whys of agile and scrum again, the impetus being lifelong struggles in doing agile scrum; it’s hard to master! I recently heard an interesting idea that got me thinking about things differently, which was a developer’s explanation of agile and scrum. He described agile as an abstract base class and scrum as an implementation.

Being a nerd, I immediately wondered if examining our scrum implementation would reveal SOLID code or a plate of spaghetti. This post, and the next few, will evaluate some of the implementations I have seen against the ideas put forth in SOLID code development.

Single Responsibility Principle

A class should have only a single responsibility. Excellent! This should be easy! Sadly, though, the typical implementation looks like this:

Look familiar? It's certainly not a single responsibility. In order for Scrum to work, its implementation needs to do one thing: Deliver Software.

If you are struggling to produce quality code on a predictable schedule, check to see if you are overloading the responsibilities of your teams.

1. Support: Does your scrum team regularly care for existing production code? Stop! All the benefits of agile scrum come to a halt when the backlog has a bunch of unrelated work. The only effective way to do support work with a scrum team is to add it to the product backlog and group it together for a sprint. That way the team tackles it as a single sprint goal. Other than that, create a support team and protect your new development.

2. Technical Debt: Do choices you made long ago wind up as excuses in your sprint retrospectives? Effective planning for a sprint must include infrastructure changes and upgrades and any rework you purposely accepted in the past. Product owners need to regularly groom the backlog with team leaders.

3. Outside Duties: Do members of your development team have ancillary duties? As a reminder, all development team members have one title: Developer. Any other hat they wear is a drain on the team.