Does life exist outside the Scrum Guide?
To all of us who follow Scrum, it is obvious how important it is to understand the Scrum Guide, and implementing only parts of Scrum is not in itself Scrum.
However, the question remains: Can we implement practices outside the Scrum framework to make things better?
This article intends to answer that question. To begin with, let us look at few statements in the Scrum Guide.
“The Scrum framework is purposefully incomplete”
“Various processes, techniques and methods can be employed within the framework.” — The Scrum Guide 2020
Now that we have read the above statements, I hope you have got the high-level answer for the question stated in the first part of the article.
The next question is, what to do and how?
It is a difficult question to answer as possibilities are endless. Only the team can decide what to incorporate and what not to. However, here are few good practices that have helped our teams produce a quality outcome
- Empathy mapping: In one of my favorite books: “Trillion Dollar Coach”, Bill Campbell once told a product manager, “if you ever tell an engineer at Intuit which features you want, I’m going to throw you out on the street. You tell them what problem the consumer has. You give them context on who the consumer is. Then let them figure out the features. They will provide you with a far better solution than you’ll ever get by telling them what to build.”
The key is to help the team realize the customer’s goal.
- What problem are they solving?
- What would be the best solution for the customer’s problem?
- Generate ideas as a team and have a consensus. - Scrum Events and their benefits: One of the responsibilities of the Scrum Master is to help the team realize the value of the Scrum framework. Ask your team if they like attending the scrum events. If they do not, then the duty of the Scrum Master is not to cancel those events that the team does not see a benefit in, rather understand the concern and take necessary actions to make the event beneficial for the team.
- Eliminate non-value-adding activities: The team should continuously inspect, identify and try eliminating waste. The most crucial factor here is TIME, we cannot control, neither preserve nor reacquire it.
For example: Identifying antipatterns, unnecessary calls, areas where the team is spending more time. - PO acceptance: In my experience, despite the team having a good understanding of the acceptance criteria, there were few UI suggestions, functionality additions that used to hit directly in the Sprint Review meeting. Thus, we started the PO acceptance call. Here the developer and the PO would meet (Since the team was actively pair programming, everyone knew the outcome) and navigate through the developed workflow. Since PO had the better product knowledge and insights on the roadmap, we received early feedback and incorporated them in the increment. Over time, we observed that team was more confident in presenting the Sprint Review.
- Pair programming: We adapted this practice from XP(Extreme Programming) that played a vital role in producing quality outcomes. Many teams argue on this practice by pointing at its pitfalls, few common ones that I have come across:
a. Expensive: Two developers spending efforts on the same task rather than executing multiple tasks. If the team does not spend discussing before implementing, they will discuss during code review. I have seen developers arguing this is the best way just because they hate to change anything because they have to re-write code, test, and update the unit tests. If you have a team with no code review, where everyone is trusted to push whatever they want (maybe with the best static code analyzer rules). The challenge is to validate the solution implemented. With Pair Programming, developers together discuss and design the best solution.
b. Lengthy: The team spends more time on conversation, debate. In few instances, the team does not have a consensus and finally having to disconnect. We have to understand the side effects of promoting people to work in silos. There is a reason we set the Sprint Goal and call it a team.
c. Feels dependent: People do not like to work in an environment where they have no freedom. However, Pair Programming is not about getting to people’s nerves and questioning everything they do. Setting the right expectations and elaborating the purpose of every practice or process solves 80% of the issues. Pair Programming was called the “Dynamic Duo” till 1992. These details make the team understand the essence better. In my case, I heard very positive feedback from the team, and they admitted great learnings from each other and felt more confident. We can also timebox the calls, propose to start the conversation with social talks or hobbies to help collaborate better.
Long term benefits:
1. Learning from each other.
2. Respecting everyone’s views.
3. Give the feeling of collectively owning the product.
4. Making the team more confident in what they build.
On the other hand, the disadvantage of not having Pair Programming is that the developers are reluctant to own modules or fix any issues developed by others. I remember once hearing: “It was not my idea to implement it that way. Now I do not feel it is my responsibility to change it either”. - Trunk-based development:
“If it hurts, do it more frequently, and bring the pain forward.” — Jez Humble
For seamless integration, the team should avoid long-living feature branches and merge code changes frequently to the main branch. The problem with the long-living branches is that the integration is pushed towards the end with thousands of changes, making it very difficult for the team to identify the source of the problem. On the other hand, when integrations are done more often, it is much easier to find the issues because there are very few changes incorporated in every build. In addition to the above, the team should also have good version control guidelines and policies in place. - Team Dependency board:
This is very useful for multiple Scrum teams / one Scrum Team having dependencies on different teams are working on the same product / project.
Step 1: Teams independently draft a high-level Sprint plan only highlighting the Features/Epics, the target Sprint of completion, and the target Milestones/Versions.
Step 2: The teams fix a timeslot to connect together or virtually share a board (please refer to the image above) for asynchronous communication and update the dependencies on each team.
Step 3: Individual team internally discusses and checks the feasibility of delivering the dependencies as per the plan and communicates accordingly.
Step 4: In case of a risk, the team can negotiate with the Product Owners to check the feasibility of possible adjustments. If not the team will have to work with other teams and rework the plan.
In each Sprint, the team's commitment and focus are the Sprint Goal. However, the dependency board also enables us to focus on the forecasted release plan, the associated risks and continuous integration.
8. Technical Guidelines and methods: Scrum doesn’t prescribe any technical practices. Many teams lean towards ScrumXP (Scaled frameworks ) or come up with their plan. Here are few things to consider which will benefit the team instantly:
a. Coding guidelines for the team
b. Unit Testing
c. Code review process
9. Encourage open discussions and support new ideas:
We often observe people hesitating to share their opinion, which may be valuable. However, we cannot always blame the team for this behavior. We should first try to create a platform promoting people to step up, appreciate every opinion or idea presented(regardless of them being feasible or not). In my experience, this has helped a lot, and gradually the team became confident, eventually coming up with great ideas. The best satisfaction for any employee is when the ideas they propose get noticed, receive positive feedback, and become a potential feature that goes into the product.
10. Adapt to team dynamics: It is easy to dictate what is there in the Scrum Guide. However, when things get repetitive, they eventually lose the initial glitters of change. One such example is driving the Scrum Events. I have noticed many teams not even trying to make the Scrum events interactive. The common feedback I hear is: “The Scrum Events are not games to make them interesting. They have a purpose, and people should understand it. It is about all about following rules and learning discipline.” I partially agree, but I feel making the Scrum Events interactive is not a crime. For example, No one loves to watch the “Start-Stop-Continue” model retrospective for the 100th time. However, it is worth running some fun Retrospectives to see how the team feels. The only rule is to make sure we respect the timebox, understand the purpose and ensure the outcome of each event is helping the team.
11. Recognitions and celebrations:
What lies behind the success?
It is the team’s relentless efforts, hard work, and commitment. There will be situations where an individual or the team goes the extra mile to satisfy the project needs. Recognizing these efforts at the right time boosts their confidence, motivates them, and increases the team’s morale. This act may not often come at a price, but it proliferates the positivity in the team and helps them proceed in the right direction. The team starts learning from their experience, understands what worked, and continues to strive for excellence.
Endnote
In this article, I wished to emphasize that the Scrum framework is all about creating self-managed teams, helping them realize the importance of aspects outside the boundaries of any process. There is no one tailor-fit solution that works universally for all the teams. The only way to find answers is to be curious, experiment, collaborate and learn from each other’s experiences and failures.
My recent reads which I highly recommend:
1. Why I love the courage of others to give me feedback. An amazing article by Sander Dur.
2. Five Things Stakeholders Need To Know When Working With Scrum Teams! by Sjoerd Nijland
3. Managers, Leaders and Scrum — How To Make It Work by Willem-Jan Ageling
To my team, if you are reading this, please feel free to add a comment on what you loved personally while following these practices and how they helped. To all the readers, I hope this article helped. I look forward to everyone’s valuable suggestions and feedback.
