Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo descriptionKnow our brand.
Stephen R. Covey, in his book “The 7 Habits of Highly Effective People”, said that people who focus their lives around solid principles are more likely to achieve personal and interpersonal growth and, simply, be happier.
However, if the principles are the territory, the values represent the map with which to move through that territory. The principles are external and objective, they are the natural laws that determine the consequences of our actions, while the values are internal and subjective, serving as a guide for our behavior.
If we extrapolate this idea to the team concept it seems very interesting to ask what are the values that can convert an average team into a team that can interpret reality with a good map, which allows them to make the best possible decision at all times and act in consequence. So, would you like to know what values create highly effective teams?
The Scrum Guide describes the values by which all Scrum teams should be guided:
Literally it says: "When the values of commitment, courage, focus, openness and respect are incarnated and lived by the Scrum Team, the Scrum pillars of transparency, inspection and adaptation come to life and build trust for all."
Frequently, when in the trainings and talks we describe the Scrum framework, we dont go in depth on its value system, probably because we have to say many things in a short time.
However, if we take into account that Scrum is a lightweight framework, where many decisions are left to the team, it is essential to have a system of values that unifies the behavior of the team in order to facilitate transparency, inspection processes and adaptation, and contribute to creating the necessary trust both in the team itself and in its ecosystem (stakeholders, management, community, etc.).
I quote a very illustrative example, which I am sure that anyone who has done a Daily Meeting will understand.
There are teams in which members of the Dev Team are limited to answering, in a more or less spontaneous way, the three questions that guide the event, i.e: what did you finish yesterday? What do you plan to do today? and what blocks you?
However, how many teams use this meeting to share information, really collaborate and reschedule their work for that day to make sure that everyone is focused and aligned to move towards the Sprint Goal?
Or, how many teams use the Daily to identify a newly discovered risk that may jeopardize the Sprint Goal and highlight the need for immediate replanning?
Lets remember that, in addition to being wrong in terms of the value system, a daily is wrong by way of “format”. I believe that the difference between one and another behavior lies in the understanding and assimilation of the value system on which Scrum relies. The values can not be taken lightly by any member of the Scrum Team, from the Product Owner to the last member of the Dev Team to join the team. The values give direction and meaning to our work, our behavior and our actions.
As Roy E. Disney says: “When your values are clear to you, making decisions become easier”.
This value has been misinterpreted for a long time. Many understood it as an unwritten strict contract by the team by which they had to complete, without exception or excuse, the Sprint Goal and the agreed scope.
Or worse, the Product Owner took as a compromise the requirement to the Dev Team to do everything necessary to complete all the planned work, even knowing that the DoD did not comply (Definition Of Done) and thus the consequent generation of technical debt.
However, commitment means that each member of the Scrum team (ie, everyone, including Scrum Master and Product Owner) will make the maximum possible effort and will be completely transparent about the progress of the Sprint.
In the world of software development, anyone who has minimal experience and has faced a real-world project will know that a closed and inviolable commitment in scope is simply impossible and only leads to frustration.
The nuance is very important: in the Sprint Planning the team makes a prediction of the work it can carry out, not a contract with a signed seal. Commitment means dedication and refers to actions and effort, not the final result.
For example, we can relate this value to one of the universal principles, Justice. If the Product Owner or a member of the Dev Team does not devote enough time, energy and willingness to contribute to the achievement of the team's objectives, as the rest of the members do, would this circumstance be fair compared to the rest of the team members? Are they committed?
The members of a Scrum team are committed to the team's objectives and, as Gunther Verheyen says, with quality, with learning, with being better professionals, with transparency, with self-organization improving all the time, being proactive, with the delivery of increments, with inspection and adaptation, with the continuous improvement of DoD, with contributing the maximum possible value to the product they develop, with Scrum itself as a framework, and even with the Agile manifiesto and the principles it fosters.
"Begin with the end in mind", proclaims Stephen R. Covey as the second most important habit in his book "The 7 Habits of Highly Effective People".
We all know that the number one enemy of productivity is multitasking, dispersion and lack of specificity in the objectives that are intended to be achieved. Scrum proclaims that all team members should focus on the planned work in each Sprint that ultimately allows Sprint Goals to be met.
The team should focus on what is most important now, without worrying too much about the future, which can be very uncertain and changing. The team should not devote time to tasks that may not be necessary in the future, that would be throwing time and money away. YAGNI (You Ain’t Gonna Need It) or KISS (Keep It Simple Stupid) can help remind us we must maintain our focus.
I have spoken with some Product Owners concerned with the dedication of certain team members to certain tasks that were not included in the Sprint (nor had they arisen in the daily replanning), simply because they had decided that something might be a good idea or could be needed in the future.
Although it is difficult to draw a line between, for example, what reduces technical debt or increases quality, and what is a loss of focus, it is almost always necessary to say three times NO to a job or task that is not directly related to reaching the Sprint Goal.
As a general rule, it is always best to do as few work as possible that allows me to meet the objective.
Focus is to focus on meeting the Sprint Goal and, by extension, on the Product Backlog items that are part of the Sprint. If the Sprint Goal is well defined and the Product Backlog items were well prioritized, then the team will be working to deliver the maximum possible value at each moment. That is focus.
In fact, the English word "openness" can be translated as frankness, sincerity or open and receptive attitude.
Scrum defends transparency as a basic pillar of the empiricism on which it is based. Without transparency it is impossible to carry out Inspection and Adaptation. Therefore, the Dev Team must be transparent with the work it does, with its progress, and with the knowledge it acquires (documentation).
The Product Owner must facilitate access to relevant information to stakeholders (Product Backlog, Total Cost of Ownership, etc.). All team members should facilitate transparency in communications and the sharing of information that facilitates collaboration inside and outside the team.
Not only the above, the team must be accessible and available to interact with stakeholders (especially in this case, the Product Owner, for obvious reasons) or with other members of the community (architecture, security teams, etc.).
Even team members must be open to learning new skills or acquiring new knowledge that makes them cross-functional teams. Team members must have an open and proactive attitude to improve their professional skills and abilities, which in addition to contributing to the benefit of the team, translates into personal growth.
I must admit that the first time I read "respect" in the Scrum Guide, I thought it consisted of being well mannered with the team members (of course!). But later I discovered that respect, as understood by Scrum and the Agile world, is a fascinating concept.
The members of a Scrum team respect the knowledge, skills and professional experience not only of the rest of the members of the team, but also of those people with whom they relate, be they from their own organization or from another.
The members of a Scrum team respect each other sharing information, fostering a collaborative spirit, learning and making decisions together. The members of a Scrum team respect each other, understanding their Scrum roles and the responsibility of each one within the team.
The members of a Scrum team respect the sponsors not developing "features" that nobody will use later. The members of a Scrum team respect the sponsors not spending money on things that do not add value to the product. The members of a Scrum team respect the sponsors not dedicating the effort to tasks that do not add any value to the product.
The members of a Scrum team respect the users by listening to them, showing interest in their problems and giving them a solution.
The members of a Scrum team respect the community by not remaining as an island or an isolated unit within the organization, but actively participating to transfer knowledge and experience.
The team must have courage to do the right thing. For example, consider change as something necessary to adapt to a changing world, even though sometimes it forces us to undo pathways.
You have to have courage to be able to develop the product without looking to the future more than necessary, focusing on what we know is important now, rather than on what may (or may not) be important in the future.
The team must have courage to solve the obstacles that may arise along the way, anticipating the risks, bringing the problems to light and thinking of a solution. You have to have courage to recognize the mistakes made, be transparent and learn from them.
The team must have the courage to improve the application of Scrum, identify weaknesses in its execution and defend why it is beneficial to improve its practice.
This value is not part of the Scrum Guide, but I consider it so fundamental for work within a team (and for life in general) that I would like to explain it in a different sense to what most people usually think it refers to. .
Most people think that proactivity means "doing more things," or going a little further, "taking the initiative."
However, in a broader sense, proactivity means, as Stephen R. Covey explains in the book quoted above, "being responsible for our decisions".
That is, our behavior depends on our decisions, not on the conditions. If we see the term "responsibility", from the Latin responsum, we will see means "the ability to respond". We see it in the following figure:
Reactive people guide their behavior by their feelings, by circumstances or by specific conditions, while proactive people guide their decisions by their values, carefully selected and internalized.
For me this discovery changed, to a certain extent, my way of acting in life. Therefore, I recommend anyone interested in going deeper into the topic to read chapter one of the aforementioned book by Covey.
Therefore, I consider that proactivity is the value that closes the circle of values that a highly effective Scrum team must have, because it allows filtering all the decisions, behaviors and actions of the team through the Scrum value system.
If we can get the members of a Scrum team to understand the importance of proactivity, understood as the ability to choose the response to a stimulus by filtering it with Scrum values, all the decisions that are made will be coherent and aligned with the framework, and this is fundamental for the success of the project execution.
In general, when we explain Scrum to the members of a team or other interested parties, we do not go in depth with the value system on which it is based.
The values of commitment, focus, openness, courage and respect help guide the behavior and decision making of a team. Being a lightweight framework, there are many decisions that the team must take in a self-organized manner and so that these are aligned with the Scrum framework must be filtered by its value system.
Although Scrum does not include it, the value of proactivity makes it possible to become aware of how to respond to the stimuli received by a team and decide, freely and consciously, how to respond, how to behave and how to act.
To create a highly effective Scrum team (or not even Scrum), it is vital that team members understand and internalize this value system.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.
Technology, people and positive impact.