Onward and upward!


I always enjoy the comraderie of my fellow coaches at the Coaches Clinics and getting to meet the people who come to chat for a 15 minute coaching session. This year's Coaches Clinic at Big Apple Scrum Day in New York City continued the tradition. While every clinic is different based on who shows up, there are two clear constants. One is the coaches' earnest desire to help people with the next leg of their Scrum journey. The second is the energy of the attendees in seeking a way forward.

Everyone's Scrum journey is unique and that is what makes coaching such an interesting vocation. Certainly there are patterns — well worn paths that many have trodden in the search for improvement — but these paths crisscross, double back, circle around, and blend in innumerable ways.

For me, this year's coaching topics ranged from estimation (what a can of worms that one can be!), how to get started with agile, how to improve team focus and accountability when the team is distributed, and variations on how to be a better coach or trainer for the team and the organization. 

I often start the coaching conversation with the question, "What is the difference you want to make?" or a similar variation on the question, "Why?" The intent of this question is to turn the conversation inward to what the attendee really wants to accomplish. This focus is key to the journey. 

On the day following the conference, I went to the John Pierpont Morgan Library and Museum and found the following quote:

No problem can be solved until it is reduced to some simple form. The changing of a vague difficulty into a specific, concrete form is a very essential element in thinking.
— John Pierpont Morgan

The discovery of this quote is another reason I love to come to Big Apple Scrum Day in New York City. It's the people, the history, the learning, the ever changing, but still same enduring quality of what makes us resilient, adaptable, and successful. As J.P. Morgan's bookplates adorning his many thousands of books say, "Onward and upward".

Making Better Choices — Modeling over Muddling


When faced with an important and complex decision, effective decision makers use models. Why? Models cut through complexity by identifying key drivers that influence outcomes. Good models provide insights that lead to better decisions, and better decisions lead to better outcomes.

What are models?

To begin, models are not reality. This part is important. Models are never right. We use models because reality is too complex. Models are simpler versions of reality. A modeled version of reality is not reality itself, so it can not be "right." The best we can hope for is that the model be useful in making better decisions.

Model both upside and downside

To be useful in evaluating a choice, a model must give insight into value upside and risk downside. Sometimes people call a model the "value proposition." Calling something a value proposition is inherently optimistic. Not to be overly pessimistic, but to be helpful, the model must also address risk.

Model to reflect changing reality

A model is typically a snapshot of reality, a moment frozen in time. A snapshot of reality can quickly grow stale. The expressions that "change happens" or that "change is the only constant" remind us that a model must be updated if it is to stay relevant.

Model for conversation

The fact that models are not reality can also make them changing them less contentious. If someone challenges that they don't believe your model, you can respond that you don't believe the model either since it is not "real." This openness creates an opportunity to improve the model. I always like to follow up an agreement that the model is not real with an earnest request of the challenger for help with the model. Perhaps the challenger has better data or insights on other drivers. Often we get a better model as a result of this exchange. And a better model produces better decisions.

Model to maximize value

"The Scrum Guide" tells us “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” Clearly the value of the product is influenced by the Product Owner's decisions. What is the value of a better decision? Consider the decisions on the order of items in the Product Backlog.  Modeling the value of each discrete item in the Product Backlog provides a transparent basis for ranking. Plus, models provide a means for the Product Owner to explain the order of the items based on current understanding of their modeled values. The conversations around the value models and the resulting improved decisioning helps ensure that the Scrum Team is always working on the most valuable work.

Product Owners Getting the Attention They Deserve

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
— “The Scrum Guide”, Ken Schwaber and Jeff Sutherland, November 2017

After a slow start, interest in the Product Owner role in Scrum is gaining momentum. It’s about time given the significant impact this role contributes to value creation! Of course Development Teams and Scrum Masters are important as well. After all, the product doesn’t get built by itself and impediments do not magically take care of themselves. But at the end of the day, without effective product ownership, Scrum Teams will rapidly crank out potentially shippable increments of stuff nobody wants — and building stuff that nobody wants is a surefire way to kill your business!

Sometimes we can’t see the tree for the forest


This time of year many of us are making resolutions. Try something new. Get some improvement.  Of course, the biggest challenge is often how to stick with the something new long enough to see the improvement. 

Take your team for instance. Over the past year, how many new things did they try? How many stuck? Did any make a positive difference?

If you're struggling with these questions, here's an idea. Simplify the picture. Sometimes we can’t see the tree for the forest. So rather than attempt to understand the impact of multiple new things, try focusing on just one thing for the next month or so.

Have your team pick one agile practice. It can be one that they are already doing or something that's new. Have everyone pay attention to what difference that one practice makes. What is the team learning through its use? Does it provide new insight to their process?... their product? ... the organization?... themselves?

Above all, don't give up too soon. Give the practice a chance... perhaps 2 to 3 Sprints. What changes are happening Sprint over Sprint? The team might be surprised the difference even one agile practice can make. By focusing on the change, the team is more likely to see the benefit of that one practice and will be more likely to continue the practice. If you find this approach effective, continue by adding another practice and try that for a few Sprints. After a bit of understanding the trees, the forest will emerge.