In his keynote at the Agile Development Practices conference, Brian Marick described values missing from the Agile Manifesto. His view is that the Manifesto was essentially a marketing document, aimed at getting business to give agile a chance. Now that this goal has largely been achieved, an extended set of guiding values are needed to help teams deliver on the promises of the manifesto.
Values are what keep us on the straight and narrow path in the face of temptation. Teams that have strong internalized values will stick to good Agile practices — and get good Agile results — while teams without guiding values will drift into the ditch.
The ideas that Brian expressed in the keynote are the latest evolution of a theme that he shared at the 2007 XP Day Toronto, and later wrote about. At that time, he had a list of 4 new values that he thought were needed:
Skill
There is no substitute for skilled developers and testers. Skill comes from making time to learn and practice the craft of software development.
Discipline
It turns out that doing agile well takes quite a bit of discipline. In the moment it is always fast to not refactor the code, or to skip writing tests. In the moment it is easier and faster, but in the long run this will only slow you down. It takes discipline to act on this knowledge, every time.
Ease
Make the things that we do often easy. Brian describes how this is related to the concept of habitability. Just as a house is adapted by its inhabitants in order to make their lives easier and more comfortable, so can code, and our working environments be modified in ways that make them easier to 'live in'.
Joy
Now, I could say that a joyful employee is a productive employee, and that lack of joy on a project is like a canary keeling over in a coal mine: a sign that something big is wrong and you better pay attention. Maybe that’s true. I’d certainly like to believe it. But, fundamentally, I don’t care. I think joy is its own excuse. We deserve it. More to the point, those people around us deserve it.
At that time, Brian was concerned about what a lack of these four values would lead to.
I think Agile is suffering today because these fundamental values didn’t get written down and are too easily forgotten. As Agile moves into bigger companies and into less adventurous ones, those undocumented values are getting watered down. If that continues, I’m afraid Agile will be this decade’s fad that changes nothing. That would be sad.
James Shore recently expressed similar concerns about the agile movement being undermined by teams implementing agile poorly.
More recently, Brian has added a few more values to his list, including: courage, being reactive, fast feedback, and visibility that rises to the level of exhibitionism.
Courage
This is the courage to do what is best for the team, the project, even the business, despite the pressure to do otherwise. Brian shared an example that he credits to Ken Schwaber, of a scrum master who disassembled the team's cubicles, so that they could have the team space that they wanted. When confronted by the 'furniture police' she made it clear that she would quit if the cubicles were restored.
Being Reactive
Brian feels that despite the bad rap the word 'reactive' has, that it is entirely appropriate for an agile team, and its members to be reactive in certain ways. When coding, it is sometimes better to write some code and then react to how well or not that code is working out. When making decisions, waiting until the last responsible moment can be viewed as a reactive approach.
Fast Feedback
Taking a feature-by-feature approach to development, instead of an infrastructure-first approach, is one way to get fast feedback. Business is rarely able to give feedback on raw infrastructure (Hey, nice database design!), but business is easily able to give useful feedback on working features. Another instance of even faster feedback is seen in test-driven design.
Visibility
Making as much information as visible as possible has long been considered a best practice among agile practitioners. It is the motivation behind 'big visible charts' and 'information radiators'. Not only is this useful for keeping everyone informed, it can surface problems quickly and these will tend to get addressed naturally.
Just make bad habits visible enough. The pressure of constant visibility will make you lay those habits aside, and — over time — what you do instead will themselves become habits, but this time good ones. And, over time, this collection of changes can grow great team members and great teams, exactly in the way that the product grows smoothly from something barely functional to something to be really proud of.
The text of Brian's keynote can be found here.
How does your team apply, or not apply, these values? Is Brian's list complete or are there other guiding values that agile teams should consider? Leave a comment and share your thoughts.