In my experience it has never been a good idea to “surprise” the stakeholders (e.g., customers, users, internal management) of the product we are building. I can’t recall the last time I’ve heard a stakeholder say, “Wow, I am really surprised by what you are showing me…” and have that mean something positive. It typically does not mean, “I am delighted with the results!” Usually it means the exact opposite.
Here are just a couple of examples of what surprise actually meant to the executive management team at one company I recently worked with:
- I have no idea what’s going on or if we’re making progress and I am often flabbergasted by what people are working on.
- I only get to give feedback before you want to ship and am taken aback by what has been built.
And that organization is by no means alone. I could tell you countless stories of teams at other companies that delivered products to the customers or users that were completely underwhelming, or failed in any reasonable way to meet basic expectations. These deliveries led, as you might imagine, to feelings of surprise, disappointment, and frustration among the stakeholders.
So, what’s going wrong?
Agile Is Based on Fast Feedback
One of the key principles of agile development is fast feedback, which helps us determine if we are running down the wrong path. As a rule, if you are running down the wrong path then the first thing you need to do is realize that you are on the wrong path and stop running. And then, if you can, pivot to a better path.
To enable these adjustments, teams should solicit and get a constant stream of actionable feedback from its stakeholder community. At a minimum, this should happen during a sprint review meeting, which is one of the most important feedback loops in the Scrum framework. And, because sprints are short, feedback should come quickly, allowing for frequent course corrections to keep the product development moving in the right direction.
If, instead, we were to defer this feedback until much later and to assume that everything is going according to some baseline plan, we likely would get what many are accustomed to (like I said earlier)—surprise, disappointment, and frustration.
So, one frequent cause of stakeholder surprise is when teams fail to solicit frequent and get, fast feedback from stakeholders.
Agile Requires Transparency
A second frequent cause of stakeholder surprise is when teams fail to share information transparently with stakeholders.
At the heart of Scrum are the principles of inspection, adaptation, and transparency. To be in a position to inspect and adapt, we rely on transparency: all of the information that is important to producing the right product must be available to the people involved in creating the product. Transparency makes inspection possible—and inspection is needed for adaptation. Transparency also allows everyone concerned, including the stakeholders, to observe and understand what is happening. It leads to more communication and reduces or eliminates surprises!
Principle of Least Astonishment
I can summarize the main point of this posting using the principle of least astonishment. Basically, this principle states that we should act and develop work products in a way that is least likely to startle (surprise) those around you. If we are developing a product and people say things like “I didn't know you were working on that!” or “I would never have guessed that the product or feature would work that way!” then we have probably failed the principle of least of astonishment.
We can avoid the consequences of stakeholder surprise if we are transparent with the details of what is happening and solicit early and frequent feedback.