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.

Which days of the week to start and end your Sprint


There’s much confusion over which days of the week to start and end your Sprints. Many teams new to Scrum simply choose to start their Sprints on a Monday.  After all, it’s the start of the work week. And since most Sprint durations are some multiple of one week, the end of the Sprint naturally falls on a Friday. Here’s why starting on a Monday and ending on a Friday may be a bad idea.

Monday Fog

Not everyone is at their best on Monday morning. Shaking off the detritus of the weekend and getting back into the work groove can sometimes take a good part of the day. Plus, Mondays get more than their fair share of late arrivals to work and often fall victim to an extended 3-day weekend. A Sprint Planning meeting held first thing Monday morning may not capture your team at their best.

Friday Fatigue

The bookend to Monday Fog is Friday Fatigue. After a week of intense, focused team collaboration, despite a Sustainable Pace, many of your team members may have already mentally checked out for the weekend. Fridays are also prone to the same extended 3-day weekend problem as Mondays. Getting your whole team together Friday afternoon can be a bit of a challenge. The quality of feedback captured during a Sprint Review meeting held on Friday afternoon is likely to suffer as a result.

Stakeholder Inconvenience

Sprint Planning and Sprint Reviews always benefit from stakeholder input. For example, a Sprint Planning meeting is more effective when a feature’s business stakeholder is available to clarify their needs. And the purpose of the Sprint Review is to gather feedback from these same stakeholders (and others) about the “done” feature to determine what to do next. If any of these stakeholders are absent, there’s a significant lost opportunity for value creation.

Imagine the inconvenience to the stakeholders if the Sprint Review is on Friday afternoon and the Sprint Planning is the following Monday. It would be great if Scrum Teams always worked close to their stakeholders. However, more often than not, stakeholders do not work in the same place as the Scrum Team. This physical separation means that many stakeholders must travel some distance to where the meetings are to be held. If this distance requires a flight or overnight travel, putting a weekend between the two meetings is a big barrier to stakeholder participation.

Middle is Best


Scheduling the Sprint Planning and Sprint Review meetings in the middle of the week creates the opportunity to hold all of these meetings in one day. The Sprint Review and the Sprint Retrospective of the Sprint that is finishing are held in the morning and the Sprint Planning for the following Sprint is held in the afternoon. Yes, it is a busy day, but the focus is just two Sprints worth of work. The potential payoff of this 1-day investment is big. 

Collaboration and Value Creation

Collaboration is essential to value creation using Scrum. Starting and ending your Sprints mid-week is an easy way to boost collaboration by facilitating and enabling optimal stakeholder and Scrum Team participation in the Scrum meetings that begin and end the Sprint.