A colleague asked me recently for some ideas on how to measure a team’s agile health. Like anything in agile (or in life, really), there are multiple ways to accomplish the objective.

One easy thing to measure is each team member’s satisfaction or happiness. This can be as simple as having each Scrum Master do a quick fist of 5 vote on happiness, with 0 or 1 being miserable, and 5 being very happy. The thing you have to be careful with this metric is that it doesn’t indicate an issue with a team. A low score could be due to an issue with leadership. Perhaps leadership has done something that the team is unhappy with. Perhaps leadership has set a team up to fail by placing people whose personalities just don’t go together. Or, perhaps the team is unhappy with themselves on how THEY are performing.

Mark Griffiths “PMI-ACP Exam Prep, 2nd Edition” suggests an interesting success metric for a team’s agile health - it boils down to 3 simple questions:

* Did the team deliver on what the customer wanted?
* Did the team leadership stay intact?
* Would the team operate in the same process again?

Unfortunately, this is a lagging metric and doesn’t allow you to pinpoint where a problem exists -it simply tells you if a problem exists. But, it’s simplicity does make it an attractive option.

A third approach is to present to the team the 4 values of the Agile Manifesto and ask each member to rate the team or organization on each of the 4 values. This will help you pinpoint where a team is unhappy, but if team members have different opinions of what the 4 values mean (and they will), you will get varying scores and opinions. But, this is pretty simple to do and you can track it over time.

A fourth tool for assessing agile health of an organization is this model called “Agile Fluency”. There are coaches who can come in and “assess” your organization, or you might be able to do it yourself. It’s an interesting model, but I haven’t used it myself. I’ve found more benefit in using it as a model for growing teams and generating ideas around how I can coach them to reach the next level.

The final tool and one that I’ve used for a while now is called Agility Health Radar. It’s not cheap… in money or time. It costs about $1,000 to become certified to facilitate the assessment and an on-going licensing fee to the tool. But this tool provides a clear visual on how the team feels like they are doing and provides them insight on how to improve.

The Agility Health Radar starts with a facilitated survey by a Certified Agility Health Facilitator. This survey lasts about an hour, and with the latest update, provides clear guidelines on how a team scores themselves in various areas such as “Generalizing Specialists”, “Predictable Velocity”, “Creativity”, and “Technical Excellence”. Once the team completes the survey, they then review the results as a team, discuss what they can improve, and raise concerns on impediments to their growth to their leadership team. These “Organizational Growth Items” are then discussed with the leadership team to be discussed and possibly resolved.

There are a number of ways in which an agilist can measure a team’s agile health. The approach you take will depend on your budget and time that you can invest into the approach. I recommend starting with asking the team how they feel they are doing on the 4 agile values. You can expand this to the agile principles, Scrum values, Lean-Agile values, or whatever else the team or organization values. Just like anything in agile, start small, experiment, and iterate.

How does someone get better at a skill? A new skill might require initial education, training, reading, watching, and thought to get to the point that the skill can be utilized. But regardless of a new skill or old, the only way to improve the skill is through dedicated time for practice. I can read all that I can find on improving my golf game, such as good swing techniques, or how to play various shots, but unless I practice, swinging the golf club or playing various shots, my golf game won’t improve.

But you might think you’ve reached the pinnacle of a skill and have no room for improvement. You’re like a professional at that skill, and professionals don’t spend time on practice.

Or do they?

Do professional athletes practice? They’re skilled at their profession, enough to put it on display each game. Do they practice? Of course they do! There’s always a move they could do better, be faster at, or understand the situation better.

Writing and designing software is a skill, a skill that we often take for granted. Once we’ve mastered a framework, library, development methodology, or tool, do we take time out to get better?

What we need is a method to practice these skills in an environment that allows us to refine and improve them. A series of software problems to solve, design, and code allowing software developers and testers a chance to improve in whatever framework, library, methodology, or tool they choose.

Put this all together, and you get the concept of a Code Kata - software problems that teams repeat to improve their skills.

Take some time out of your busy work week and try a code kata for an hour or two. And I challenge you to see if it improves your coding and designing muscles.

There are a number of resources on Code Katas. A few of these I’ve found include:

[http://codekata.com](http://codekata.com)
[https://www.codewars.com](https://www.codewars.com)
[https://github.com/gamontal/awesome-katas](https://github.com/gamontal/awesome-katas)
[https://github.com/pivotal/code-katas](https://github.com/pivotal/code-katas)
[http://www.codekatas.org](http://www.codekatas.org)
[http://codingdojo.org/KataCatalogue/](http://codingdojo.org/KataCatalogue/)

Good luck and happy coding!

When tackling a new project, feature, or application, it’s often useful to define a ‘minimum viable product’ or a ‘minimum viable feature’. The pure essence of this idea is to identify the minimum amount of requirements that produces a valuable and usable product. This ensures we focus on just a few features and deliver them quickly. Ultimately, we want maximize the value we provide, which means we may not implement all of the features we have planned. To truly maximize the value teams deliver requires a critical eye on requested features and a product team that is not afraid to say “no”.

While we strive for that level of rigor in our product backlogs, do we enforce the same level of rigor in our agile practices? As we add more teams to an organization and add more coordination points, we may be tempted to reach for some scaling agile practices, such as Communities of Practice or Scrum of Scrums. We may even reach a point where a scaling framework like the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS).

But we should hold ourselves to the same level of rigor with our organizational changes as we do with our product backlogs. That means we should aim for minimum viable scaling; the least amount of scaling we need to achieve value from it. That means we need to say “no” to some scaled agile practices and aim to implement the most valuable ones first. Our aim in our scaling efforts should be the same as with a product backlog: focus on what gives us our ‘biggest bang for the buck’ first.

Have you heard this one?

A man goes to his doctor and says “Doc, it hurts when I lift my arm over my head.”

Too which the doctor replies, “Then don’t do that.”

As coaches, we are asked to diagnose a team’s ailments. And while most of times the solution is the application of various agile practices, sometimes the solution is much simpler. Take for instance:

QA Engineers making heroic but stressful efforts at the end of a sprint to close out stories.
The Product Owner prepping stories the night before a Release Planning meeting.
The Dev team continually committing to more and more work that they stress over, pushing them beyond a ‘Sustainable Pace’.

All of these share one thing in common: stress.

In agile, if we’re stressed, then we are doing it wrong.

When stress on the team manifests itself, something in the Agile process or the team itself is wrong.

In the above examples, there are ways the team can work better that does not involve last minute heroic efforts by the QA Engineer, the Product Owner. The QA Engineers need to speak up to the team and work to resolve the problem that results in a number of stories being closed at the end of the sprint. The Product Owner could ask the team for help with prepping stories, as story writing and prep is something the team can do and owns. In the case of the Dev team working beyond a ‘Sustainable Pace’, they need to be coached on what this means and what an acceptable level of work to commit to looks like for them.

Emotions, including stress, are signs of how a team is functioning. Negative emotions, including stress, are signs that something is not working right, either with Agile or with the team.

What emotions is your team exhibiting and what are they telling you?

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.