How to Apply Scrum Values in the Day by Day?
Throughout my journey as a Scrum Master, I have noticed more and more the need to remind and reinforce Scrum values. This is because we are often more concerned with peoples defined roles, artifacts, events, and rules described in the Scrum Guide rather than with the Scrum framework base.
For example, I’ve noticed that some Scrum Masters start to implement events right after they join their teams. They get the teams to participate in the Daily Scrum Meetings, set rules and roles, talk about Product Backlog and increments, but they don’t prioritize what’s more essential. What they should do is get to know the team/stakeholders, their maturity with agile and the setting they are in. Being an active listener and paying attention to the current situation can save relationships and going back to the basics of the Scrum framework can help us a lot in this regard.
So let’s understand a bit more about the essence of Scrum. The framework’s values first appeared in the 2016 version of the Scrum Guide. As authors Ken Schwaber and Jeff Sutherland say, “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” According to the 2016 Scrum Guide there are five Scrum values and they are recommended behaviors and what we call agile mindset. Here they are:
Courage: The Scrum Team has to have the courage to do the right thing and work on difficult problems.
Focus: Everyone focuses on Sprint work and Time Scrum goals.
Commitment: People are committed to achieving Scrum Team goals.
Respect: Team Scrum members respect each other to be capable, independent people.
Openness: The Scrum Team and its stakeholders agree to be open to all the work and challenges with the execution of these works.
Practical Examples of Scrum Values with a Focus on Scrum Events
“(Scrum) definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.”
2016, The Scrum Guide 2016, p.3
To make sure I cover all the bases of where these values should be practiced, I have decided to relate them to the four Scrum events. I will cover Sprint, Planning, Review, Daily Scrum, and Sprint Retrospective.
Let’s get to it:
COURAGE:
Imagine that Sprint has already started and the team is working on items 1 and 2. On the third day, the Product Owner succumbs to the pressure of the customer, who asked to stop everything and focus the work on items 3 and 4. In this context, Development Team needs the courage to advise the Product Owner of the impact of the interruption, at all times, with an exchange of priorities.
At Planning, consider that Sprint’s goal has already been set and you already know what Backlog items we need to reach it. Now it’s time to determine which Product Backlog items will enter the next Sprint, i.e. what the Sprint Backlog will be. To do this, the Development Team meets to play “planning poker”, an activity in which each member shares the estimate of how many story points each item has, based on the effort it demands. Here the developers also need the courage to estimate the effort correctly.
In a Review, imagine that the Development Team failed to achieve the Sprint Goal it set out to address because it underestimated the complexity of the items. It takes courage to admit that Sprint has failed. In the Daily, if the team does not have the courage to report its impediments, the efficiency of the team is compromised. Finally, it is in the Retrospective where courage is needed the most. Ideas on how to improve can be controversial, and the whole team must have the security and the courage to expose what did not work well including their own failings.
FOCUS:
Now let’s assume that during a Sprint, each developer chooses to work on their own Sprint Goal item, also called an iteration. The risk of not finishing is high because the someone’s iteration complexity might be too much for one person in one sprint. Especially when you consider out of control factors like developer absences etc. This is why we recommend pair-programming, in which two developers work together in the same activity. So we stop trying to start and start trying to finish, avoiding waste and generating value more quickly. Here, focus is very important to prioritize and develop one value add item at a time per Sprint. Ordinarily, it is said Planning can be divided into two parts. But I would say there are four: definition of the Sprint Goal; estimation of stories effort; selection of the stories that should be part of the Sprint Backlog, considering the priority set by the Product Owner, and finally the breaking of each story. Planning should not waste time estimating and defining stories with low priority, the Development Team needs focus on high priority stories. Based on the amount of story points it has managed to complete in the previous Sprint, the team discusses whether it wants to do the same or a larger amount in the next Sprint and sets out those story points. The priority order is established by the Product Owner, the team focuses on selecting the activities, from the most priority to the least, and adds up the effort that it believes it will accomplish. In Review, the Product Owner may want to discuss with Scrum Team the Sprint Backlog, as it is, and design a goal or delivery dates. At this point, it’s important that the entire Team is focused on collaborating, giving input on what to do soon, as this can generate valuable inputs for Planning, which comes next. In the Daily, focus is very important so as not to turn it into a status report meeting. Imagine the team is discussing its progress toward the Sprint Goal and is suddenly interrupted by the Product Owner who abruptly questions the delivery deadline. Not cool, right? If the team stays focused they can avoid this type of situation. Finally, let’s consider that during a Retrospective the customer starts talking about bugs that need to be fixed urgently. The Scrum Master may need to step in and help the team stay focused on the true purpose of the Retrospective meeting, which is to look at what worked well and what can be improved for the next Sprint in terms of people, tools and relationships. To help with this, a tip is to create an area called the “Parking Lot” on the wall so that issue of the bug will be discussed at another opportunity.
COMMITMENT:
From the beginning to the end of Sprint the Development Team must look after the quality, which should not decrease over Sprint. The Scrum Master can teach and encourage the Development Team to create their own “DoR” (Definition of Ready) and “DoD” (Definition of Done) to stimulate commitment to the quality of the increment to be delivered upon entry and exit of the Sprint. In Planning, once the Sprint goal has been set, Team Scrum also needs a commitment to choose items that help achieve the goal and increment delivery at the end of Sprint. During a Review meeting, the Development Team introduces its potentially releasable increment to the stakeholders for feedback for future improvements. Here, it is also important that stakeholders are committed to giving feedback on the increment of product delivered and displayed at that meeting. Only then did we achieve constant improvements.
For two days in a row it turns out that the Development Team extended the Daily, going over the 15-minute time-box. The Scrum Master should stay committed and reinforce to the Development Team that the Daily Scrum time-box needs to be respected. The Scrum Master should also help the team to understand why it is happening. This can be done during the Retrospective soon after discussing the positive points that have occurred in the recently completed Sprint. When it is time to define actions for what did not work well for processes, tools or relationships. Here, only with commitment, can the Scrum Team create a plan to implement improvements to the way the whole process works.
RESPECT:
The Sprint is in progress and, two days from the end, the Product Owner decides to include items that the customer has just put into their goals into the Sprint Backlog. In addition to going against the Sprint Goal set in Planning, this intervention will cause the Development Team to lose focus on the items they are already dedicated to. When the Product Owner places higher-effort items as higher priority after the sprint has started, the Sprint Goal can be impacted. Here, the Product Owner must be careful to absorb customer demands without committing to them until obtaining and respecting the opinion of the Development Team, as changes that undermine the Sprint Goal consequently impact the product evolution.
During Planning, let’s say “planning poker” is implemented, in which the Development Team estimates the effort of the items that are likely to be part of the next Sprint. During the activity, there is divergence of opinion among the developers, so they need to share the reasoning behind their choice and in doing so respect other team members points of view. Once the amount of story points planned for the next Sprint has been discussed, it is possible that the Product Owner, for example, suggests that developers commit to a certain number of story points instead of letting the Development Team decide. Here it is important to remember that the developer’s opinion about the amount of story points to be committed to for the next Sprint should be respected, since the Development Team is made of the people who really “work the dough”. That is, they aware of the real complexity of each item.
Imagine that one day before the Review a client decides to cancel it, because he believes that it will disrupt the work of the Development Team, which has a lot to do. It is the role of the Scrum Master in this situation to ensure that meeting participants understand their purpose, make them respect the overall process. It is important to explain that postponing the Review would be the same as extending the Sprint period as it would have a direct impact on Development Team’s performance metrics. Attendance at Dailies is also a matter of respect. If a person is always late, it is Scrum Master’s role to explain to them the value of the meeting in question and the importance of respecting other team members who understand the importance of daily attendance to these meeting at the agreed upon time.
The Retrospective is a great opportunity to apply the concept of respect, because it is when discussing the negative and positive points of Sprint that we have to respect the opinion of each of the team members and have empathy with each point covered. In addition, everyone needs to respect the purpose of the meeting, which is to inspect how the last Sprint was with regards to people, relationships, processes and tools.
OPENNESS:
Imagine that during a Sprint, the client requests urgent things that might directly impact their end customer, causing financial losses, and have nothing to do with the initial Goal set. In this context, anyone from the Scrum Team must be open to suggest to the Product Owner the cancellation of Sprint due to lack of understanding the purpose. During Planning, shortly after defining the Sprint Goal by the Scrum Team and consequently the selection of items to be performed at the next Sprint, it is time for the Development Team to decide how it will complete and, if necessary, break up those items in the way that is convenient for them. Openness within the team here is essential for the them to decide how to turn functionality into a “Done” product increment. During the Review, the Development Team demonstrates to stakeholders the work that was “Done”, and this time the stakeholders need to be open enough to ask the Development Team questions about the increment delivered.
In a Daily, the Development Team need to be open to lead the meeting in whatever way it finds most productive, without necessarily answering the three questions in the ScrumGuide regarding the Sprint Goal. The important thing is to know if there is something stopping you from reaching the sprint goal, draw a plan for the next 24 hours and align yourself on what has been done. For the Retrospective, openness is also necessary for the team to be honest about improvement points for the next sprint.
Conclusion
Although the five Scrum values have been in the Scrum Guide since 2016, they often go unnoticed by practitioners who, due to day-to-day dynamics, end up focusing more on roles, artifacts, events and rules, deprioritizing which is in fact related to the pillars of the transparency, inspection and adaptation framework. Based on my own experiences, I have tried including some practical examples of how to apply values to Scrum events to generate value. This is because applying the framework blindly, without analyzing the full complexity of scenarios can cause catastrophic effects to the relationship between stakeholders, team members as well as other pitfalls.
Therefore, it is always important for the five Scrum values to be remembered and even used as arguments to reinforce the security of the team.
By Vanessa Franchi
