Smart Scrum: How to Execute Sustainable Scrum for your Project, A case Deep Dive!

We have heard many organizations follow scrum but when one actually does a deep dive they will notice that scrum is superficially applied with lack of effective implementation of scrum principles.

I will present some well known cases cases along with their rationales to illustrate the effective application of scrum principles. These instances are not limited to my project experience, but are prevalent across various organizations, customers, as well as colleagues I have interacted with in the past.

Utilising Scrum without harnessing its true intent is detrimental to any organization in the end.

Scenario 1 : Following the completion of each Sprint, a Team conducts a Sprint Retrospective on a monthly basis. During these meetings, the team identifies Process Improvements (PI) and gaps (G), but fails to revisit or implement them in future sprints.

After the upcoming sprint concludes, they hold a Sprint Retrospective meeting where they acknowledge that the PI's & G's identified in the previous sprint were not carried out. This pattern continues, leading to a buildup of unaddressed PI's & G's, ultimately resulting in the realization that the project was not executed effectively.

Reasons : It is quite straightforward to guess that the PI's & G's identified as part of the sprint should have been added to the sprint backlog to actively implement in the upcoming sprints, but the actual reason why they were not included in the sprint backlog are:

1. Absence of a Scrum Master, Most organizations do not invest in a scrum master because:

   1. They believe they can manage Scrum roles internally without the need for a dedicated Scrum Master, relying on existing staff to fulfil the role informally.

   2. Hiring a Scrum Master may be considered costly for some organizations, particularly smaller companies or startups.

   3. Certain organizations may prefer not to adhere to a "full scrum" methodology, instead choose a more adaptable approach. "Full scrum" refers to fully embracing the principles and practices of scrum.

2. Teams prioritize feature development and bug fixes over process improvements.

3. Since Sprint retrospective happens "once" in the entire sprint, Teams fail to review and follow up on the progress of action items in subsequent sprints, leading to them being forgotten.

Improvements :

1. Use Sprint Retrospective meetings to capture actionable plans with clear steps, timelines, and responsibilities. PI's & G's cannot be vague, poorly attended retrospectives reduce the possibility of consistently addressing improvements.

2. Assign clear ownership and accountability for action items. If the team does not have a dedicated scrum master and is going to leverage members from existing staff then members of the team must take turns every sprint to bring back these PI's & G's into the product backlog and ensure execution of these action items.

3. Include metrics to assess the value of each improvement - Will this implementation contribute value to your project? Organize action items based on their importance, categorizing them as Critical, High, Medium, or Low, for effective prioritization and execution.

4. It is important to regularly review the PI's & G's that were included in previous sprints, as some of them may have become outdated due to changes in product goal.

   
   

Scenario 2 : In a team's Sprint Review meeting, a deck is presented to demonstrate the work done in the sprint. Some slides also address features that are "In Progress" for future sprints. Following the Sprint Review meeting, stakeholders find themselves puzzled about the implementation.

Reasons:

1. Scrum framework was not followed- Scrum mentions that only workable increments should be presented as part of sprint review and any items that are work in progress should "not" be part of the event.

2. Misaligned Sprint Goal - The outcome of the sprint must align with the sprint goal.

3. The lack of clarity in responsibilities meant there was no designated leader guiding the team on what information to include and exclude in their presentations.

Improvements :

1. During the sprint review, it is important to showcase a "workable increment".For instance, presenting a functional product such as a website with sprint-developed features for stakeholders to interact with is more beneficial than sharing a slide deck filled with information.

2. The Sprint Goal needs to be easily understood and focused. It should be shared at the start and throughout the sprint, serving as a continual reference point for the team's objectives during the sprint.

3. If scrum approach is being followed their should be a dedicated scrum master who can coach the team on the rules- do's and don'ts.

4. The Sprint Review should be an interactive session rather than just a presentation, encouraging discussion and communication between the Scrum Team and stakeholders. A passionate team leading the conversation significantly contributes to highlighting the accomplishments.

Scenario 3: In Product Backlog Refinement, the Scrum team struggles to assign story points to user stories. While senior team members can justify the chosen story points, junior members are frequently left puzzled. The user stories often lack detailed descriptions and acceptance criteria.

Reasons:

1. Limited accountability and/or absence of Product Owner

   1. Some product owners might have limited decision making authority owing to traditional hierarchal structures, overlapping roles, stakeholder influence etc.

   2. Some teams may not have a product owner because they might not have a customer facing product, for example - Teams might be working on internal tools, infrastructure improvements, or process optimizations that don't result in an external product but are crucial for the organization.

2. Backlog items are unclear and inefficiently prioritized, leading to misaligned efforts.

Improvements:

1. Include a foundational understanding of the User Stories shared among the team for proper context.

2. Backlog Refinement sessions should be held regularly and must be time boxed, to keep the backlog manageable. Large User stories or features should be decomposed into smaller manageable pieces to define clear descriptions and user acceptance criteria.

3. Story pointing should be open-minded, without blaming developers who assign high or low story points.

Conclusion

No organization or team is perfect, however, by identifying common problems and areas of concern can help to improve efficiency and deliver value more effectively.