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.
4. Magic Work: Does your team discover other work in the daily stand up? Stuff that was not in the sprint backlog yesterday, but magically appears? Usually completed and reported by the developer that was duped/forced to do it for someone? You've gotta kill this stuff. The product owner is the single wringable neck for what gets in the product backlog, and the development team must approve any addition to the sprint backlog. Period.
5. Meetings: Death, taxes, meetings. Inevitable...but at least meetings can be scheduled. Scrum masters should advocate for their teams by proactively working with other parts of the company to schedule meetings at times that minimize impact. Shoot for first thing in the morning, last thing at end of business or on a day already affected by sprint planning.
6. Abandon Best Practices: Tired of surprises in your sprint review? Freeze the code. Just stop writing. If you don’t, you won’t properly test and review the code. Set a time, get your team together and wrap up the increment of value you are providing your customer. Activities 1 thru 5 above are why teams fly past a code freeze. Don’t overload them further with sprint surprises.
Next time: Open/Closed Principle.
Happy coding!
Elegant Software Solutions