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.


The Cone of Uncertainty

I first encountered the phrase “cone of uncertainty” in the mid 1980’s while reading Barry Boehm’s book, Software Engineering Economics  (1981). Using a traditional software project context, the “cone of uncertainty” model showed that the amount of uncertainty in a software project is greatest at the beginning, ultimately converging to zero (0) at project end. In his book, Boehm reveals the magnitude of the uncertainty through research showing that estimates provided at project start are generally off by a factor of four (4). That’s right, a factor of four… and you thought your estimates were bad!


This “cone of uncertainty” made sense in a traditional project context. That is, if you’re assuming that the scope of what is needed can be determined and fixed upfront. But, we have learned that software isn’t actually like that. Let me explain.

How many times have you built exactly what the customer asked for only to hear on delivery that despite the product being what was asked for, it doesn’t meet the customer’s need? The cone of uncertainty described above is premised on the customer being right in their initial ask. Once you deliver what they asked for, you’re done. But what if they’re not right? Pause for a moment and think… in the case of a new product, has the customer ever known exactly what was needed before it was built? Is it even reasonable to expect them to know?

What I’m suggesting is that it is not estimation and our inability to accurately estimate that is the issue. In fact, our focus on estimates and estimation have distracted us from what is more important — that is, building the right thing.

The Cone of Possibilities

If we’ve never built this exact product before, we have no hard data proving that it is the right fit for the customer need. Before something is built, the idea of the thing to be built is simply a value hypothesis. We won’t know if it’s right until the product is built and in use by the customer. The sooner we build something and start generating feedback, the sooner we will have data on whether or not what we are building is right, and, if it’s not, how to change it so that it is more likely to be right.

Building software is analogous to building a new product. Building a new product is a journey from the known to the unknown. Instead of a cone starting wide and narrowing towards a point, building a new product is more like a cone starting at a point and widening out to a myriad of possibilities. A more appropriate model to describe the product evolution is a hurricane forecast cone. In the picture below, “X” marks the spot where the hurricane is now. That spot, plus where the hurricane has been in the past is what is known. Where it is going is uncertain. We can model a likely path based on current information, but our ability to accurately predict beyond the immediate future is limited. And the farther we try to predict the more uncertainty we encounter. Beyond a certain point, it’s not even worth predicting.

For a new product, we always have a current state of the product — what it is currently — even if that state is that it doesn’t yet exist! That current state is what is known. We won’t know what the next iteration of the product will be until it is actually built. Any number of unexpected things might happen in the interim.  For example, the customer changes their mind, the infrastructure on which a new feature depends turns out not to support the feature, a key team member departs, a new law or regulation limits or blocks the deployment of the feature, and so on.

Hurricane forecast models are updated frequently based on new data to improve our ability to react and prepare for the effects of the hurricane. The potential value in saving lives and property and minimizing damage to infrastructure warrants the investment in keeping the model current and useful.

Optimizing for Maximizing Customer Value

A product backlog represents a product’s potential future state. Like a hurricane forecast model, the product backlog represents possibilities. The actual track of the product is known only after the fact. The product owner’s decisions in product backlog content and order influence future product direction. With maximizing customer value as the primary optimization goal, the things that might influence the product owner’s decisions in reordering the product backlog and changing its content can be as complex as the factors influencing a hurricane’s direction. 

Just like the hurricane forecast model,  the product forecast model, the product backlog, must be updated frequently. Interestingly, the myriad possibilities of the future backlog also means that there is no upper bound to customer value creation. The main part of the product owner’s job is to manage the backlog for this purpose. Unlike in a project, the goal is not to be done, but rather to maximize value to the customer. If we are to focus on building the right thing, the more appropriate model then is an open-ended cone, rather than a closed one.

Have you considered your future product potential, what influences its direction, how to effectively forecast, model, and communicate its possibilities?

Did you know?
In 1973, Barry Boehm shocked the computer industry by predicting that software would outrun hardware costs.

Scrum Masters and Product Owners Together


The Scrum Team consists of a Product Owner, a Scrum Master, and the Development Team. It’s pretty obvious what the Development Team is doing. They’re mostly heads down analyzing, designing, building, testing, documenting and all the other related activities needed to make the product work. Simply, get the right people, communicate what you want, and get out of their way. It’s amazing what results you can get when you give a Development Team everything it needs to succeed! Exactly what the Product Owner and the Scrum Master are doing day after day while the Development Team is building stuff is often less clear.

The Scrum Guide™ tells us, “The Product Owner is responsible for maximizing the value of the product and the work of the Development Team…the sole person responsible for managing the Product Backlog.” That’s a great summary, but what exactly does that mean in action?

In addition, The Scrum Guide™ has a bulleted list of the Scrum Master’s service to the Product Owner”

The Scrum Master serves the Product Owner in several ways, including: 
* Finding techniques for effective Product Backlog management;
* Helping the Scrum Team understand the need for clear and concise Product Backlog items;
* Understanding product planning in an empirical environment;
* Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
* Understanding and practicing agility; and,
* Facilitating Scrum events as requested or needed.

This is a great list, but again, what does it mean in action? There is no simple answer for this question. Every situation is unique and requires a situationally appropriate response. The Product Owner and the Scrum Master need to figure it out for themselves. Luckily, they’re not in it alone. They are in it together — partners in solving this ever evolving problem.

Understanding this partnership, how it works as a multiplier, and avoiding the pitfalls of stepping outside the bounds of each role are critical to both Product Ownership and Scrum Mastery. We have found that this partnership gets off on the best footing when the Product Owner and the Scrum Master share the same experience in learning about Scrum. When a Scrum Team’s Product Owner and Scrum Master attend one of our classes together, they tend to have better traction and attain greater success in their use of Scrum to achieve their goals. This correlation is so significant that we’ve decided to introduce a new ticket type to enable them to attend the same class together at a special PARTNER price. No special code is required. Just choose ticket type “Scrum Master/Product Owner Partnership” when registering. 

Our current classes are listed here.

Organizational Change... Not!

organizational change not.jpg

What do you do if you happen to find yourself in a organization that is simply paying lip service to agile? First, don't despair. Organizations don't change overnight and it is highly unlikely that you as one person are going to change the organization. Don't feel bad about it. That's just the way it is. Second, don't lose faith. There are some things that you can do within your control to effect positive change:

  • Know your team's purpose. What value does your team create for your customer? What difference does this value creation make to your organizations bottom line? Don't know your team's purpose? Ask.
  • Be transparent. Let others know your team's goal and communicate what you're doing to help the team achieve the goal.
  • Ask for help when you need it. Your team is better when it works together.
  • Get real. If things aren't going according to your plan, fix your plan to deal with your current reality. The plan was built on what was, not what is. Whatever reality is, deal with it.
  • Be the change. We all have preferences, biases, and models of how we see the world. If any of these is not helping,  be willing to change yourself!

Who knows, with enough individuals making a positive difference, we might just get the organization to change as well.