Wayne Gretzky. The “Great One”. Growing up in the midwest, I only had a passing knowledge of Canada’s favorite sport, Ice Hockey. But growing up, I knew of Wayne Gretzky. He led his teams to 4 Stanley Cup Titles. He was selected as Most Valuable Player 9 times. To be that good, no one could argue that Wayne Gretzky was knowledgeable about how to play Ice Hockey. I’m sure that is part of the reason why he tried his hand in coaching the Phoenix Coyotes.

But as a Coach, Gretzky had no where near the success he had as a player. After 4 years as a head coach, he had failed to take his team to the playoffs and had an overall record of 143 wins, 161 losses, and 24 ties.

Michael Jordan. In Basketball, he was a legend. During the 90s, he led the Chicago Bulls to 6 NBA Championships. He was selected as an NBA All-Start 14 times. He holds the record for the highest career scoring average at 30.12 points per game. After retiring, he became an owner in the Charlotte Bobcats (later renamed the Hornets) and took over basketball operations.

But, the Hornets never achieved great success. But they do hold a special record of their own. During the 2011-2012 season, the team won only 7 games out of 66, a .106 winning percentage, the worst winning percentage in NBA history.

So what happened? Why did Wayne Gretzky and Michael Jordan fail? Did they not know enough about their respective sports?

What these coaches forgot or neglected was the coaching part of a Hockey Coach or Basketball Coach. They were clearly experts in their sport (and in the case of Michael Jordan, perhaps far more than you know), but where they have failed is on the Coaching aspect of their job.

As Agile Coaches (or Scrum Masters who are asked to ‘Coach’ our teams), we have to remember what the coaching aspect truly means. Our Agile expertise is useless if we cannot influence, show, and persuade individuals and teams on the agile values and practices.

When we meet with other Agilists, we often talk about utilizing the latest Agile Practices, techniques, or remind ourselves of the values and principles. But, as you consider your own growth as a Scrum Master or Agile Coach, don’t forget to strengthen your skills as a Coach.

If you don’t, you might end up with a team with a worse winning percentage then .106.

Revisiting High School physics, the Second Law of Thermodynamics introduces the concept Entropy. Simply put, Entropy is the amount of disorder in a system. In any given system, Entropy can only increase over time, meaning disorder increases over time.

While the concept applies to Thermodynamics, you can see it at work every day. If you don’t dust your house on a regular basis, the amount of dust (disorder) increases. Roads age over time and form potholes that require patching and eventually, require the road to be re-pathed.

Development teams are not immune to the Trap of Entropy. If they are not actively trying to make themselves better, a team will move to disorder. This is one of the many reasons why periodic Retrospectives are so important; they help the team establish order and ensure the team is improving. Because if a team is not improving, the team is declining.

Fifteen years ago, at a ski resort in Colorado, a number of technologists came together to discuss the state of software development. Included in this meeting was Kent Beck, Martin Fowler, and Ron Jeffries, both proponents of eXtreme Programming. Also present were Ken Schwaber and Jeff Sutherland, both key early proponents of Scrum. Also present was Robert C. Martin, better known as Uncle Bob Martin, and several other technologists.

The Values and Principles they published after that meeting are still discussed today and seem as important now as they must have then. All of them seem to be universal truths of software development; all of them except one. For the longest time, I’ve struggled with the importance of the third value, “Customer Collaboration over Contract Negotiation”. As it is with all of the Values, this statement means that while there is value in the first item, in Agile, we value the second item more. Thus, this value states that Agile software development values Collaborating with customers over negotiating with them over a contract.

For consulting companies and contractors, this value is VERY important, as it sets the tone for interactions one should have with clients. But, how does this value apply to a company that directly hires and pays the software developers that design, write, and maintain their systems?

I would argue that this value should read “Collaboration over Negotiation” and simply do away with the nouns in the statement. In this new format, it means that while we may need to negotiate from time to time, we value and prefer to collaborate. For Agile Teams, this means that when they are working with stakeholders and end-users, they strive to collaborate with them on requirements, design, scope, and schedule. Instead of the business dictating a set date, we strive to have a conversation, a collaboration, where both sides strive to talk openly and come up with a plan that is realistic and attainable.

Within an Agile team, this means that the User Stories we use as our chunks of work are truly a promise to have a conversation and don’t boil down to a negotiation over what set requirements actually accomplish the story. We don’t always cry ‘scope-creep’ when the Product Owner asks for a small change; we strive to collaborate at how to create the best product we can in the constraints the Agile Team is working with.

Between team members, this means when we interact with our team mates, we strive to collaborate with them instead of taking a more adversarial, negotiation-esque attitude in our dealings with them. If we have a disagreement on the design of a feature or a disagreement during a code review, we strive to collaborate together instead of taking a competitive approach.

The power of the Agile Manifesto partly comes from the fact that it is still relevant to discuss in a fast moving industry 15 years after it was published. They apply to software development broadly, but in their broad scope, sometimes need to be scaled down to understand how they apply in the real world.

On Friday, July 28th, I presented on Experiments With Agile At Scale at Cincinnati’s Day of Agile. It was a great conference and awesome to see so many agilists from Cincinnati in one place.