The 7 Values Your Agile Team Can Do Without
Two concepts most new Agile teams get wrong are working agreements and values. If teams adopt values at all, they are most likely to follow the Scrum or XP values. These are a total of seven values that are mentioned in both Scrum and Extreme Programming. Comparing them, you can see that there are two values which are common to both (respect and courage), and that overall, the two value-systems are rather similar in tone. Here they are, compared side-by-side:
The 7 ‘Out-of-the-Box’ Agile Values
| Scrum | eXtreme Programming |
|---|---|
| Respect | Respect |
| Courage | Courage |
| Focus | Simplicity |
| Commitment | Communication |
| Openness | Feedback |
New (and even some exceptionally experienced teams) often look at these, and believe that that they, as an Agile team, are being asked to adopt these values themselves. The team talks about respecting each other’s time, and need for occasional privacy, or wanting discussion and consensus on decisions. They talk about being courageous in agreeing to commit to stretch goals, or to agree to tackle that tricky bug in convoluted code.
This is wrong, wrong, wrong.
The Scrum and XP values listed above are not team values. They are methodology principles. They are the principles and values that underlie the practices of Scrum and XP respectively. For example, Kent Beck takes communication and feedback, and derives paired programming as a practice. For Scrum, Keith Sutherland and Ken Schwaber take commitment and openness, and derive Sprint Commitments. They take ‘focus’ and derive serial delivery. Beck takes simplicity, and derives story-point estimation. And so it goes on.
These seven principles give little or no guidance to teams on how they should develop practices and behaviors outside of those already encapsulated in these methodological frameworks.
Judge Me By What I Do
Just as the values of Scrum and XP inform the practices of each methodology, so should the team’s values inform the team’s working agreements. The problem with this of course is that teams often do not really know what their values are in the first place. Most teams could care less.
Team values, however can be observed, and they can be created. The secret to this are ‘working agreements’ – the codes of behavior that teams agree to follow. Just as Scrum and XP practices reflect the values that underlie them, so the team’s working agreements will reflect the team’s values – whether the team knows it or not. We need to observe the team’s working agreements in action, and over time, impute the team values from the team’s actual behavior.
For example, consider a working agreement such as “If at least three team members are present, they constitute a Quorum, and can make decisions on behalf of the whole team.” Such an agreement would enable the team move forward without having to try and get everyone in the same room to discuss every issue. Consider that a team that rigorously practices this working agreement demonstrates that it values something more than full participation or consensus. What this thing that it values actually is, will depend on what the actual effects of this policy turn out to be. Perhaps poorer decisions are sometimes made, but feelings of empowerment are increased. One might therefore impute that the team values empowerment over being right all the time. Moreover, if other working agreements of the team also result in empowerment, ’empowerment’ may be a team value . Then, having come to that conclusion, the team might attempt to deliberately craft other agreements to support or reinforce empowerment in other areas. The value is not an abstract, aspirational desire – it is proven and is founded in actual behaviors that the team demonstrably follows. Without this direct traceability, values are empty words pasted onto the team wall.
Prove It To Me
Values are tricky for teams. Working agreements are too. Not all agreements are as simple as deciding ‘core hours’ – the times when all team members, wherever they are located, should be ‘at work’. Take the example above – that three people constitute a Quorum for the team. How was that decided? Who came up with the number three? There is a simple way to quickly and painlessly create great working agreements. That way is to pose them as experiments. Experiments test hypotheses. Make clear what problem we are solving with the agreement. Post the agreement in the team room, and keep track of any evidence that supports the hypothesis (‘before the rest of the team arrived, three team members designed a new feature, which meant the whole team could start coding as soon as they arrived, saving three hours that otherwise would have been unproductive’). Also keep track of counter-evidence (‘because a database table was designed and implemented without involving the DBA, the database structure that we designed and built had to be scrapped’). Working agreements can then be objectively evaluated. This makes it easy to propose new working agreements, because they can be tried for a while, and dropped if they prove not useful.
Putting It To Work
In this article I have shown how working agreements (the rules that teams regulate themselves by) can be easily created and tested, and how those same working agreements demonstrate the team’s values. As the team uncovers its values, it becomes easier and easier to formulate effective working agreements founded upon those values.
