5 Scrum values (and how they work in practice)
Last time I elaborated on how Scrum secures bioinformatic businesses. Today I will describe the 5 Scrum values defined in the official Scrum Guide and show how they work in practice.
These values are commitment, respect, courage, openness, and focus.
A value that is expressed in the activity of all team members in creating the product. The Product Owner on the client's side has access to the daily meetings of the development team. Developers participate in strategic planning; they don't hide in the basement to do the coding and then return the product based on top-down guidelines after two weeks.
Commitment is the equal participation of all team members in achieving the goal of a valuable product. Each individual is responsible for achieving this goal.
How does commitment work in practice?
For over a year, we've been working on a technically complex, highly innovative blockchain project for a client from Switzerland. The project is moving forward at a great pace because each side is equally engaged in it from the beginning. During daily product meetings, the client acts as a Product Owner. We are up to date with the client's current business challenges, such as funding rounds, new customers, etc.
hanks to the mutual commitment, both parties feel support and a team spirit, which significantly speeds up the work and increases the product’s quality.
A courageous product team does not sweep problems under the rug. When mismatches and misunderstandings arise (and it's naive to assume they never do), it's the responsibility of the project members to express their doubts. Not to pour out frustration, but to rectify the situation that prevents the efficient delivery of the product.
Courage in a Scrum project means that any team member will not be silent when a problem or a doubt arises. When we see that something is not working as it should, we aren't scared to share our doubts and discuss them internally and with the client.
Whenever we have any doubts about the scope or anything related to the product, we boldly ask.
How does courage work in practice?
There was a continuous misunderstanding between the client's Product Owner and our team in a cheminformatics project for a large US company. The project continued and the work was moving forward, but the developers felt they were creating a much less valuable product than they could by failing to get in at the process level.
The team wasn't afraid to express their opinion out loud. Thanks to a courageous reaction, we repaired the deteriorating relations and continued the project on a new basis, with a hefty dose of freshness and greater initiative on both sides.
In Scrum projects, views are often exchanged, and different opinions clash at the client-contractor level and between the developers themselves. In such an environment, freedom of thought is essential, but it means war without respect.
I understand respect in the project as respect for differences of opinions and attitudes. We have different work styles and ideas for a process or product, and we don't always have to agree. Due to respect, the difference in opinion is a pretext for discussion and finding a compromise. Our criticism is pointed not at each other as humans but at our actions.
We don't close ourselves to what we believe is right.
How does respect work in practice?
The most significant reflection of this value is the Retrospective meeting, which takes place after every product sprint. The meeting aims to provide feedback, where we look critically at the work of the entire team.
Without mutual respect, such a meeting can quickly turn into a fight. However, since respect is the basis of Scrum, nobody takes an aggressive or defensive attitude, whether someone is giving or receiving feedback.
I also noticed that cultivating respect allows people to be themselves and consciously treat themselves and others on the team. Respect is a form of professional maturity that increases the individual's efficiency, quality, and pace of work and, consequently, the entire product team.
"Nothing is constant but change"; therefore, all project members must be open to changes and be able to adapt to them. People, as a species, don't like changes, so it's crucial to instill openness to these changes in the team and not to treat them personally. To be flexible when changes occur.
These can be changes at the product level (new outlines, sometimes contrary to the original one) or the team level (new product owners, new developers). Often these two go hand in hand.
How does openness work in practice?
In a cheminformatic project for an American company, we had the project's scope set out for over a year. Then, after a few months, a new business manager came, and with him, utterly new process rules and scope of programming work.
Rebellion in the team is natural in such situations; programmers felt that their work so far was a waste of time. Nevertheless, we knew such cases could happen, and we quickly began to adapt to the changes. As it turned out, the new manager brought new perspectives and energy, which positively impacted product development in general.
It's worth noting that openness applies not only to the development team but also to the business side of the project. In this case, the new manager showed great openness to programmers. He involved the entire project team in discussing the new scope and direction, which contributed to a successful fresh start.
Eyes on the prize. Each scrum sprint has a specific goal, and all team members are focused on achieving it. Scrum without focusing on the sprint goal would be delivering everything as it goes, out of context. Focus means joint efforts to achieve the established goals.
We focus on delivering value both to the client and to the end-user.
How does focus work in practice?
A large cheminformatics project for a US client. We worked on one functionality in many teams: marketers through UX and UI, testers, and developers. Unfortunately, in the project's first phase, each team worked in isolation and pursued its own goals, omitting the most important one: providing the client with a valuable product.
As a Scrum team, we initiated a series of meetings aimed at cooperation and communication of all groups. As a result, we found the focus and finally managed to successfully deliver the feature.
Fancy for more Scrum insights?
As Project Manager of seven Scrum projects, I can confidently say that the above values are not empty talk. We work with them and on them in every project, thanks to which the client can be sure that we will squeeze the most out of the development process.
If you are interested in what the Scrum process looks like in our practice, check how we work, or for more detailed information, contact us.