What are the scrum values and why do they matter?
In addition to the Agile values and principles as defined in the Agile Manifesto, scrum embraces five (5) values and actively recommends that teams and individuals live those values.
The five (5) scrum values are:
Let’s work through each of those values and why they are important to success in a scrum environment.
Why is courage so important inside of a scrum product development team that is solving complex problems?
Because we are going to be asking the team to do things that they have never done before, in ways they have never worked before, and often with people they have never worked with before.
We are asking teams to step up to the plate, to try new things, to develop working hypotheses and run experiments, etc. and so we want them to have the courage to give it a go.
That is really important in a complex space because nobody has every solved the problem before, there simply isn’t a frame of reference to work from and so it’s all brand new, scary, and requires a great deal of courage to pursue.
Pre-existing solutions may help, or they may hinder progress. You simply don’t know until you’ve rolled up your sleeves and got cracking on the problem at hand.
As a team, as an individual, as a product owner, you simply need the courage to pursue the potential opportunity with no guarantee of success.
The team need to stretch way outside of their comfort zones. If they aren’t growing and making mistakes, they aren’t really learning or improving. The team need to have the courage to create new opportunities and step outside of their comfort zone.
We need courage in complexity because we don’t know if what we are attempting will work nor do we have any guarantees that the customer and product stakeholders will be delighted with what we have created.
As the team move forward, a great deal of options will present themselves and the team need to have the courage to have the tough conversations that interrogate the data or idea, and to make decisions that empower the team to move forward in the best way they see fit.
Without commitment, you won’t get focus.
We are looking for teams to commit to getting things done. We are looking for teams to commit to the product vision, goals, and objectives. We are looking for teams to commit to the sprint goal and we are looking at them to commit to continuous improvement and technical excellence.
We aren’t necessarily looking to the team to commit to items on a backlog, we are looking for them to commit to the sprint goals and product vision.
A product owner will articulate the mission and purpose of the product and look to the team to commit to that mission and purpose. The reason why the product ought to exist and why it matters to customers and product stakeholders.
We look to the team to commit to each sprint and sprint goal.
A small series of commitments over a short period of time. The team are committing to getting things done within that time frame and they are committed to discovering or creating the best answers to the most compelling problems.
We are looking for the team to commit to each other. Commitment to work as a team and collaborate frequently and effectively. We want them committed to continuous improvement and to have the reviews and retrospectives necessary for the team to learn and grow.
This value focuses on being open and transparent with what you are working on, how it’s going and being open and honest during the sprint reviews and sprint retrospectives.
Individuals and teams will openly discuss what the sprint goals were, what they set out to achieve, and what actually happened. Teams will be open about any mistakes that were made or open to learning how they could improve in the next sprint based on this sprint’s performance.
The team will be open about the trials and tribulations they faced during the sprint with the objective of making clear which impediments blocked progress and to highlight where improvements are necessary for the team to improve in future sprints.
It’s not whining and it’s not complaining. It’s simply being honest and open about what happened, why it happened, and what is needed to overcome that obstacle or prevent that same thing from happening in future sprints.
The value also pertains to being open to feedback.
Product stakeholders and product owners will provide feedback on what is working, what isn’t working and where they feel the team could improve.
The team need to be open to that feedback and be willing to have the hard conversations that facilitate growth and evolution. They need to be willing to discuss where they can improve and how they can improve.
Even product owners need to be open to hearing that they are steering the product in the wrong direction, according to product stakeholders and customers, and be open to making the necessary course correction to ensure that the team are back on track by the next sprint.
Openness is key for scrum teams throughout the entire product development process. The Agile Manifesto speaks to being open to changes, even late in development, to help improve the product. Teams need to embrace that and be open to opportunities to improve and evolve.
You want the team to be open to inspection, adaptation, and negotiation.
Nothing is cast in stone. We need flexibility and the ability to adapt based on the shifting sands of where we work and the markets we serve. We can only do that if we are open to the feedback and data and use these elements as a compass to ensure that we are travelling in the right direction and creating as much value for customers and product stakeholders as possible.
Focus is vital to getting things done in a timely fashion.
Way back when I started working in agile environments, a question was posed as to whether we would rather have 4 things 100% done or 5 things 80% done. Both equate to 400%. Which of those is preferable to the team, the product stakeholders, and the customer?
Traditional project management would prefer 5 things to be 80% complete whilst the Agile world insisted on having 4 things 100% complete.
It was a landmark shift in how people thought about product development and project management because it focused on getting things done and shipped to customers.
Rather than demonstrating that you were busy and had a number of things in the pipeline, the focus shifted to which problems you actively solved and which products, features, and services had actively been created and shipped to customers for feedback and performance reviews.
It’s only valuable once it is complete and in the hands of the customer.
Focus becomes incredibly important to the team’s success. A team decides to focus on a single product and a single sprint goal to achieve within the sprint.
The team focus on the most important item, in relation to its importance to the sprint goal and product, and ensure that they have a working solution developed within the sprint. And once that is done, the team will move onto the next item, and so forth.
What we are trying to achieve with focus is to cut down on context switching and empower the team to get 100% of the job done within the sprint.
If I drop my car off at the garage with the intention of having the brakes done, I wouldn’t be satisfied if they returned the car to me and told me that the job was 80% done. If the brakes don’t work, it’s a pointless exercise attempting to drive the car. I need the job to be 100% completed for me to derive any value from having taken the car into that garage in the first place.
A strong focus for scrum teams is the same. It really matters to customers that they receive a product, feature or service that is 100% complete and ready for use. It really matters that it works and is ready for it’s intended application for it to be valuable.
Context switching is a killer for organisations. Although the practice is endemic, it doesn’t lead to work being completed it simply leads to people being busy.
A lack of focus means that products and services take a lot longer to reach customers and it takes a lot longer for teams to respond to meaningful and valuable feedback from those customers and stakeholders.
Focus is simply choosing one thing, moving through it from start to finish, and completing the job according to the definition of done before moving onto the next item.
Respect underpins everything else.
Without respect within your team and organisation, how can you operate? We are working in a volatile, uncertain, and ambiguous world. We need to respect people’s decisions. We need to respect our customer and product stakeholders needs.
We don’t need to like those decisions or requests, but we do need to respect them.
We also need to accept that sometimes, product owners and product stakeholders are operating with less information and knowledge than we have. We need to respect that they are doing their best and that they are just as committed to delighting customers as we are.
Our place is to help them better understand the challenges we face and to have the kinds of conversations that help them make better decisions.
Conflict is ok. It needs to be respectful disagreement, but we need to have conversations where we can disrespectfully disagree and provide an alternative perspective, recommendation, or idea to be considered.
In my experience, everyone is trying their best. They are trying to do the best job they are capable of based on the limited information and resources at their disposal. We need to respect each other and work to establish a culture where respect is first and foremost in every element of our work.
We need to work as a team and rely on one another. Respect, as the foundation for those working relationships, means that we can rely on one another and respect that each of us is doing the best we can to help the team achieve its common goals and objectives.
So, scrum has 5 values. Courage, Commitment, Openness, Focus and Respect.
Employ these values in your every day working career and you will soon see the benefits of these values in action.
If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.
If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course page.
If you have several years’ experience as a scrum master and want to both validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master course page.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to coaching course page.
For more information on John McFadyen, visit https://www.johnmcfadyen.com