Working as a consultant I have supported many teams and organisations on their agile transformation journey. Accompanying these teams, I have learned that the agile core values are really at the heart of a successful transformation. Creating and maintaining awareness for them while continuously spending some effort to level up your adherence to them is an investment that not only helps you achieve your goals but creates a working culture that sparks truly high performing teams.
For a moment, let's look at your agile team or wider organisation as a human body. Your body. When keeping an eye on your physical health, I assume you do not only consider just one vital parameter like your blood pressure, heart rate, weight, body fat, blood sugar, or similar. While temporarily probably focusing on getting one specific parameter back into the non-critical zone, generally I guess you apply a more holistic approach.
And the same applies to your agile team, which is a body of humans rather than a human body. Still it follows the same principle: Your performance is best if you keep your body healthy.
And just as your body works best if you keep an eye on your vital signs also your agile transformation works best if you regularly consider the agile values and your team's adherence to it.
The Scrum values
Each of these values is worth a whole article describing in detail how you can assess your and your team's level of adherence and what to do to improve it.
Today, though, I will start giving an overview. While the values themselves are considered self-explanatory enough I will give some examples of what symptoms each misbalanced value can have.
Respect
While respect is an essential value in human interactions driving effective collaboration and resp. results it also reflects in the way the team is leveraging the resources provided to them. E.g. a product owner not respecting the organisation might be spending money on features of his preference rather than on those with the highest business value.
A lack of respect can directly impact the next value, openness
Openness
Openness is meant in a bi-directional way here. On the hand side, the openness to welcome other opinions that might be conflicting with the own point of view. On the other hand, it also means the openness to express yourself towards the team, show your concerns, sorrows or passion about something. A lack of openness can limit the team's ability to spark and evolve new ideas or resolve hidden conflicts which compromise the team's performance.
Courage
A lack of courage can result in product owners giving in to pressure from outside pushing them to prioritise backlog items of lower value or in developers compromising on the quality by accepting too much scope.
It can also prevent some team members from speaking up while they'd actually have something important to say, thus compromising the true potential of the cross-functional team.
Commitment
A lack of commitment to the true mission of their resp. roles can result in product owners not acting in the full interest of value-maximisation, in developers jeopardising the sprint goal or compromising on the code quality or in a Scrum master not going all in to develop a truly high performing team.
Focus
A lack of focus can result in time-boxes not kept, events taking longer than necessary, sprint goals not met, product backlog items not prioritised accordingly to maximise business value, experiments helping figure out the right product strategy not done consistently or not done at all. A lack of focus is a key driver of waste in all its manifestations.
By just collecting a few potential symptoms of misbalanced agile values it already becomes pretty obvious how toxic this can be for the potential of agile teams and how important, actually mission critical, it is to keep an eye on these values and the team's adherence to them.
The values from the Agile Manifesto
While the list of values above is derived from the Scrum guide, let me assure you that the values from the agile manifesto can equally serve as vital signs for your successful agile transformation. They might even be more outcome related and tangible than the comparatively abstract values of Scrum.
Individuals and interactions over processes and tools
This first value in the Agile Manifesto emphasises the importance of a truly interactive and collaborative working culture that is dedicated to outcomes rather than to the adherence to specific processes and tools. In a team that limits its potential by obeying to predefined processes and tools the potential to effectively sense and respond to change is significantly limited and the risk that customer need are not met is way higher.
Working software over comprehensive documentation
Depending on the definition of done which is widely driven by the local development organisation, even today much of the valuable development capacity is used to create comprehensive documentation even on features that have not yet proven in resp. experiments that they are worth to be sustained. While the value of documentation is unquestioned when it comes to maintainability in the early phases of a features lifecycle extensive documentation may turn out to be waisted efforts if the feature is finally discarded or significantly adapted as a response to unambiguous lessons from experiments.
Customer collaboration over contract negotiation
This value emphasises the interactive and iterative way of working in agile. During the waterfall era, there were the clearly separated and subsequent phases of requirements definition or scope negotiations followed by a long and well-capsuled build phase that eventually resulted in some outputs to be inspected by the customers during the the user acceptance tests. In contrary to this not very communicative process, in agile the customer is engaged and collaborates throughout the whole development process making a team living up to this value significantly more effective in meeting the needs of the customers.
Responding to change over following a plan
Similarly like the previous value, this one nails the key message of agile, from my point of view. In waterfall software development any change was considered as an expense that should rather be avoided. This ignored the fact that a change, in response to a new learning, actually increases the value of the product to be created, probably even sustains the usefulness of the product at all as compared to persevering the execution of a plan build on assumptions that have been disproved in the meantime.
Appreciating change of details or even direction as a result from a structured learning process that leverages empirical experimentation and that responds accordingly is, from my experience, above all the most critical vital sign of a successful and sustainable transformation towards a truly agile way of working.
Nevertheless, to make your agile transformation successful not just in terms of better products and happier customers but also sustainable due to highly committed employees truly enjoying the way of agile working, it is important to focus on a healthy balance of all these vital signs as illustrated above.