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.
Community comments
Less is More
by Gregory Mostizky,
Less is Less
by Paul Beckford,
Re: Less is Less
by Wojciech Seliga,
Re: Less is Less
by joshua milane,
Presenting the ideas to the world will lead to the beginning of change...
by Sachin Mehra,
Less is More
by Gregory Mostizky,
Your message is awaiting moderation. Thank you for participating in the discussion.
While I do agree that all of these values are good ones to have, I do not think any of them should be included in the manifesto.
For me, the manifesto was the red pill. And I think it was so effective because it is so short.. 4 simple concepts that open your eyes.
Of course there is a lot of learning that are needed in order to apply these ideas, but for what it is intended, the original manifesto is extremely effective.
Gregory
Less is Less
by Paul Beckford,
Your message is awaiting moderation. Thank you for participating in the discussion.
As a marketing flier then I agree that short and snappy is best. Once you actually try to apply these values though you need a lot more then that.
The XP community got it right in the beginning. Software development is multi-faceted. The c2 wiki served as a crucible where all manner of issues that affect the success of software projects could be discussed and explored. It was community based for the simple reason that good ideas can come from anywhere, and it enabled the community to flesh out the basic XP methodology filling in the gaps and addressing specific issues. I still find myself diving into the c2 Wiki even today.
In a climate where people believe that they are actually qualified to apply Agile after merely listening to someone else talk about it for two days, I do believe that more guidance is needed less Agile becomes just another over marketed fad.
I applaud Brians efforts. When I was introduced to Agile the community was still small and the practices where spread by example face-to-face. I had an experienced coach who had done it all before and could guide us through the Sha-Ha-Ri (knowledge, understanding and skill) learning curve.
Now Agile has gone global and there are many people trying to practice it who have only read it out of a book.
My two cents is that we need something like the c2 wiki today to share ideas and keep Agile community based. We also need to re-emphasis the idea of a coach.
In the words of Ivar Jacobson. Processes don't produce software, people do. This is the main idea that Agile brought to the party. We need to get back to developing people and coaching by example is where it starts.
Paul.
Presenting the ideas to the world will lead to the beginning of change...
by Sachin Mehra,
Your message is awaiting moderation. Thank you for participating in the discussion.
Brian's idea is right in its own perspective, however its not assuming the responsibility to include the good things which will be required when Agile II (assuming Brian's ideas bring the much awaited improvement) practices are established (lets say 10 yrs from now). When Agile manifesto was published, the best (of that time) was taken into accounts and rest was left for our Grey cells to decide.
We should keep this thread going and come up with draft of what we believe will help the whole Agile community. Presenting the ideas to the world is the beginning of change...and we know that the community if Agile :)
Re: Less is Less
by Wojciech Seliga,
Your message is awaiting moderation. Thank you for participating in the discussion.
I would support Gregory's "Less is More" opinion.
It's very easy to make agile practices bloated and end up with another CMMI or RUP-like gigantic set of good practices, requirements, guidelines, artifacts, etc., which at the end does not bring any real value (but are a great way of making money for various consultants and certification organizations).
Agile development is about common sense. When you really understand Agile Manifesto you don't need additional tons of commandments. Your eyes are open, you can start your journey in this world, ideally with some experienced mentor.
I am already observing (and wrote about it more than year ago) dissolution of real agile values and many companies just using it as a new buzzword they can make money on. So maybe, "agile" will be considered as another failed experiment in 10 years. If it happens (hope not), true and aware practitioners will anyway know that it's not because of the failure of the paradigm itself, but rather because of bad adoption in many places and many parasites feeding on this trend.
As far as new "Skill" value is concerned, I think that "People over tools & processes" completely covers it.
My $0.02
Wojciech Seliga
Re: Less is Less
by joshua milane,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with the above; when you have a simple set of tenets, do you really need to have it all spelled out for you? This is a slippery slope to PMI, and the fact is, development teams are so different that it would seem to be that a core set of principles is more valuable as a guideline or foundation than something more complex. Less painful = more likely to work. Unless you are talking hernia surgery, I mean.
Josh Milane
www.mittecchnical.com