SOLID Agile Development

Lifelong learning got us studying the hows-and-whys of agile and scrum again, the impetus being a lifetime struggle in executing agile scrum flawlessly; it’s hard to master! We heard an interesting idea recently, and it got us thinking about things differently, which was a software engineer explanation of agile and scrum. He described the concept as an abstract base class and scrum as an implementation. Pretty brilliant!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public abstract class AgileSoftwareDevelopmentBase()
{
	public abstract void DeliverSoftware();
}

public class ScrumSoftwareDevelopment : AgileSoftwareDevelopmentBase
{
	public override void DeliverSoftware()
	{
		while (HasProductBacklogItems() == true)
		{
			SprintPlanningMeeting();
			DevelopAndTestSoftware();
			SprintReviewMeeting();
			SprintRetrospective();
		}
	}
}

Being nerds, we immediately wondered if examining our scrum implementation would reveal SOLID code or a plate of spaghetti. This publication, and the subsequent ones, will evaluate some of the implementations we have seen against the ideas put forth in SOLID code development.

Single Responsibility Principle

A class should always be a single responsibility. Excellent! Well, that makes things easy! Sadly, though, the typical implementation looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class ScrumSoftwareDevelopment : AgileSoftwareDevelopmentBase
{
	public override void DeliverSoftware()
	{
		while (HasProductBacklogItems())
		{
			SprintPlanningMeeting();
			DevelopAndTestSoftware();

			DoRoutineSupportWork(GetSupportNeeds());
			TechnicalDebtMagnifier.ReworkNow(new Framework());
			TrainUserGroup(SalesSupportGroup, NewHirePresentation);
			DevelopAndTestSoftware();
			AddToSprintBacklogByDirection(Direction.SalesGottaHaveThisSprint);
			ManagementMeetingHelper.InsuranceBenefits(2pm);
			DevelopAndTestSoftware();
			OverrideCodeFreeze();
			DevelopAndTestSoftware(NoTestingReason, NoPeerReviewReason);

			dynamic sprintSurprise = SprintReviewMeeting();
			SprintSurpriseHandler.React(sprintSurprise);

			SprintRetrospective();
		}
	}
}

Does it look familiar? Absolutely and that’s because it’s not Single Responsibility. For Scrum to work, its implementation needs to achieve its goal to Deliver Software. Always ensure you are not overloading the responsibilities of your team if they are struggling to produce quality code on a predictable schedule.

  • Support: Your scrum team need to stop caring about existing production code. One of the responsibilities of agile scrum is to halt when the backlog has a bunch of unrelated work. The effective way to do support work with a scrum team is by adding it to your product backlog and grouping them for the sprint. The team’s sprint goal is how you tackle them. Equally, make sure you create a dedicated or separate support team and protect your delivery team and new development work items.

  • Technical Debt: Sometimes choices made by you or the team wind up as excuses during sprint retrospectives. Infrastructure changes, upgrades and reworks accepted purposely in the past must be included in sprint planning. Ensure your product owners groom the backlog with team leads regularly.

  • Outside Duties: Consider reassessing the involvement of your development team in ancillary duties. As a reminder, you should designate members of your delivery team as a DEVELOPER. Any other hat they might wear should be considered a drain to the collective.

  • Magic Work: Sometimes, your team will discover new work items in the daily stand up that might not be in the sprint backlog, but they appear magically. Someone in the organization might have assigned it to one of the developers; your duty is to discuss impromptu tasks with the person and ask them to approach you next time before dumping it on your delivery team. The Product Owner is the only point of contact for what gets in the product backlog, and the development team must approve additional work items. Communicate this company-wide and make sure it is non-negotiable!

  • Meetings: Unplanned meetings, death, civic duties are inevitables. That said; Scrum Masters should advocate for their teams by working with other parts of the organisation proactively to schedule meetings to ensure minimal impacts. Tackle the first thing in the morning, always. Leave the last thing for the end of the day (EOD), or on a day affected by the sprint planning.

  • Abandon Best Practices: Surprises can surface during sprint reviews. It is time to freeze the code! You will not test and review the code properly if you do not do it. Schedule a meeting, get everyone to hurdle up and wrap up the increment of value you want to provide your customers. The discussion should highlight why the team flew past a code freeze. Remember not to overload them further with additional sprint surprises.