That Isn’t What I Expected

Adverse surprises during a team driven project are about as welcome as whooping cough at a glassblowers convention. Minimizing the opportunity for surprises comes down to how well expectations are defined at the very beginning and how well they are managed during the course of the project. Unidentified expectations are like landmines in the project path. When they explode, it’s bad and the course of the project WILL change. Product owners can’t elucidate all the expectations a stakeholder may have, but with experience they can define the major ones. With practice and attention, experienced product owners can tease out all but the minor expectations that are often dependant on discovery within the project’s sprints.

Key to this skill is knowing the questions to ask at the beginning. In my experience, stakeholders rarely deliberately hold back their expectations. They just don’t know what they don’t know and it is the product owner’s responsibility to establish clarity around expectations. Intuitively obvious expectations rarely play out as such.

A few questions for stakeholders that I’ve found helpful:

  • What business problems do you intend to solve with this project?
  • What do you need to see to know the project is progressing?
  • What will you see when the project is done?
  • What is your availability commitment for the duration of the project?
  • How often to you expect to meet to review progress?
  • How long do YOU think it will take to complete the project?
  • To what extent are your functional groups integrated?
  • Describe your process from design to development to implementation?
  • Are there other stakeholders we need to know about and include?
  • What factors have helped and hurt success with past projects?

This is by no means an exhaustive list of questions. And they may even seem obvious. The answers, however, are almost never obvious.

I also find it effective to challenge stakeholders with scenarios.

  • What happens if we discover this project will take two months longer than expected?
  • What happens if we discover a desired solution is technically unfeasible?
  • How will you support us if we encounter significant delays from client deliverables?

Product owners need to keep pursuing clarity around expectations until they are satisfied they have a good understanding of how the people side of the project will unfold. This will go a long way to helping the development team handle the technical side of the project.

While stakeholders answer these questions, product owners need to pay attention not just the words stakeholders use, but how they answer as well. They need to be scanning for underlying assumptions that drive the answers. These often reflect relevant cultural drivers which can signal significant expectations seemingly unrelated to the project at hand.

For example, perhaps the product owner has established the expectation of a three business day turnaround for feedback from the stakeholder when asked to review periodic project deliverables. “We can complete our reviews within three business days and work to get them to you as fast as possible,” says the stakeholder somewhat hesitantly as he looks off into the distance. Where the pain begins is when the inattentive product owner discovers that, while the feedback may be ready, the client organization has a thick layer of compliance and the feedback is hung up in legal for an additional one to two weeks…every time. If the stakeholder’s responses reflect something less than 100% commitment, keep asking questions designed to surface underlying assumptions.

As each sprint concludes, and eventually the project as well, the savvy product owner knows their work with expectations isn’t complete. Retrospectives for each sprint, each release, and the project conclusion should make note of the expectations that were missed and consider questions that could have been asked that would have helped surface the surprise expectations sooner.

This is also an excellent time to consider if any of the existing expectations have changed or if it appears there may be new expectations emerging. Internal forces, such as changes in team composition, and external forces, such as shifting market demands, can significantly impact the set of expectations a product owner is tasked with managing.

If  you expected to read these kinds of things about surfacing stakeholder expectations, then you’re probably an experienced product owner.

 

Image by S K from Pixabay

Best Practices or Common Practices

I’m using the phrase “best practices” less and less when working to establish good agile practices. In fact, I’ve stopped using it at all. The primary reason is that it implies there is a set of practices that apply to all circumstances. And in the case of “industry best practices,” they are externally established criteria – they are the best practices and all others have been fully vetted and found wanting. I have found that to be untrue. I’ve also found that people have a hard time letting go of things that are classified as “best.” When your practices are the “best,” there’s little incentive to change even when the evidence strongly suggests there are better alternatives. Moreover, peer pressure works against the introduction of innovative practices. Deviating from a “best” practice risks harsh judgment, retribution, and the dreaded “unprofessional” label.

If an organization is exploring a new area of business or bringing in-house a set of expertise that was previously outsourced, adopting “best” practices may be the smart way to go until some measure of stability has been established. But to keep the initial set of practices and change only as the external definition of “best” changes ends up dis-empowering the organization’s employees. It sends the message, “You aren’t smart enough to figure this out and improve on your own.” When denied the opportunity to excel and improve, employees that need that quality in their work will move on. Over time, the organization is left with just the sort of people who indeed are not inclined to improve – the type of individuals who need well defined job responsibilities and actively resist change of any sort. The friction builds until change and adaptation grind along at glacial speeds or stop altogether.

The inertia endemic to “best” practices often goes unnoticed. When one group reaches a level of success by implementing a particular practice, it is touted as one of the keys to its success. And so other groups or organizations adopt the practice. Since everyone wants success, these practices are faithfully implemented according to tradition and change little even as the world around them changes dramatically. Classic cargo cult thinking.

In his Harvard Business Review article “Which Best Practice Is Ruining Your Business?”, Freek Vermeulen observes that “when managers don’t see [a] practice as the root cause of their eroding competitive position, the practice persists — and may even spread further to other organizations in the same line of business.” Consequently, business leaders “never connect the problems of today with [a] practice launched years ago.” Common practices, on the other hand, suggest there is room for improvement. They are common because a collection of people have accepted them as generally valuable, not because they are presumed universally true or anointed as “best.” They are derived internally, not imposed externally. As a result, letting go of a “common” practice for a better practice is easier and carries less stigma. With enough adoption throughout the organization, the better practice often becomes the common practice. When we use practices that build upon the collected wisdom from an organization’s experiences we are more likely to take ownership of the process and adapt in ways that naturally lead to improvement.

There are long term benefits to framing prevailing practices as “common.” It reverses the “you are not smart enough” message and encourages practitioners to take more control and ownership in the quality of their practices. Cal Newport argues that “[g]iving people more control over what they do and how they do it increases their happiness, engagement, and sense of fulfillment.” This message is at the heart of Dan Pink’s book, “Drive,” in which he makes the case that more control leads to better grades, better sports performance, better productivity, and more happiness. Pink cites research from Cornell that followed over three hundred small businesses. Half of the businesses deliberately gave substantial control and autonomy to their employees. Over time, these businesses grew at four times the rate of their counterparts.

When you are considering the adoption or pursuit of any best practice, ask yourself, “best” according to whom? It may help avoid some unintended consequences down the line where someone else’s “best” practice yields the worst results for you, your team, or your organization.

Image by Clker-Free-Vector-Images from Pixabay

References

Newport, C. (2012). So Good They Can’t Ignore You. New York, NY: Grand Central Publishing.

Pink, D.H. (2009). Drive: The Surprising Truth About What Motivates Us. New York, NY: Riverhead

Vermeulen, F. (2012). Which Best Practice Is Ruining Your Business? Retrieved from https://hbr.org/2012/12/which-best-practice-is-ruining

Drive for Teams

I recently re-read Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.” I read it when it was first published and I was still managing technical teams. Super brief summary: The central idea of the book is that people are mostly driven by intrinsic motivation based on three aspects:

  • Autonomy — The desire to be self directed.
  • Mastery — The urge to improve skills.
  • Purpose — The desire to engage with work that has meaning and purpose.

I find this holds true for individuals. However, when applied to teams optimizing for these three aspects can be problematic. If an individual on a team seeks to maximize autonomy, they are likely to come into conflict with the objectives of the team. For example, a software team that is tasked with developing a component that is expected to interact with several other components developed by other teams. If a single developer, in the interests of maximizing their individual autonomy, has decided to develop the component according to standards, design principles, and tools that are different from those of teammates and other teams (essentially, a local optimization,) then the result is likely to be sub-optimal overall.

Some individual autonomy must necessarily be sacrificed in the interests of effective collaboration. It’s possible, even desirable, that individual pursuits of mastery and purpose can be maintained. However, it may be necessary for an individual to focus on mundane tasks and the objectives of the team for periods of time. Finding ways to maintain a healthy balance between the intrinsic motivators and the purpose of the team is no small task and, when found, requires constant attention to maintain.

Perhaps it is possible to attach the team’s or organization’s purpose to the interests of the individual. Or sort for hiring people who have a personal purpose that is in-line with the organization’s purpose.

Image by M. Maggs from Pixabay

The Novice and the Master

When coaching people in a new skill, there are several things I watch for in their development from novice to master. Insuring they have the requisite foundational knowledge can be considered a given. Tightly coupled with this is a demonstration of working from first principles. If neither of these are in place than it can be said the learner has yet to begin their journey toward mastery.

Beyond the basics, I look for signs of what’s happening behind the curtain. I watch for how they respond to challenges and conflict. And how they work through difficult decisions.

How a difficult decision is handled is an important indicator for whether an individual is a novice, a master, or somewhere in between. Where novices struggle trying to figure out what to do, masters resolve quickly. Certainly a common issue in play would be doubts about the outcome of any particular action and the probability of recovering from any associated consequences. It is also possible that the issue – either instead of or in addition to – is that the novice has become stuck at a decision node that has an uncomfortable degree of uncertainty associated with it on the front end and they are unskilled at thinking through the “disjunction,” as Eldar Shafir1 calls situations like this.

With the former issue, the tack taken by the novice is to plan out as many details as possible so as to account for every contingency and squeeze out as much doubt as possible regarding the outcome. In the later, the novice simply doesn’t have the information needed to make the decision and lacks the skill to play out n number of scenarios leading up to the decision node such that they can then evaluate subsequent paths.

An example given by Shafir has to do with a student that has just taken a rather important exam (say, for graduate school) but doesn’t yet know the results. If they’ve passed, they move forward. If they’ve failed, they have to retake the exam in a couple of months after the end-of-year holidays. On the same day, they are presented with a incredibly sweet deal for a 5-day Hawaiian vacation over the end-of-year holidays. The vacation deal is good for today and grades won’t be released until tomorrow. What does the student do?

Notice that the outcome of the exam will be known long before the vacation begins. Thus, the uncertainty characterizes the present, disjunctive situation, not the eventual vacation. Additional, related versions were presented in which subjects were to assume that they had passed the exam, or that they had failed, before they had to decide about the vacation. We discovered that many subjects who would have bought the vacation to Hawaii if they were to pass the exam and if they were to fail, chose not to buy the vacation when the exam’s outcome was not known. The data show that more than half of the students chose the vacation package when they knew that they passed the exam and an even larger percentage chose the vacation when they knew they they failed. However, when they did not know whether they had passed or failed, less than one-third of the students chose the vacation and the majority (61%) were willing to pay $5 to postpone the decision until the following day, when the results of the exam would be known.

A solution to this simple example of disjunction (Shafir provides many other examples) is for the student to ask themselves two questions:

  1. “Would I take this vacation deal if I passed?”
  2. “Would I take this vacation deal if I failed?”

If the answer is “Yes” to both or “No” to both, then the decision about the vacation deal is easy. If the answer is still mixed, then I suppose the student will have to dig a bit deeper to get at a level of leading criteria that will shake out the decision. (When I was a student, I would have had to consult my financial adviser – a.k.a. my wallet – first. The answer to everything beyond beer was “NO!”) In the experiment described above where students remained uninformed as to the outcome of the exam, they didn’t have a skill or strategy for resolving the uncertainty and were even willing to pay to make it go away!

Shafir’s work was instrumental in helping me tap into new skills for developing mastery in several areas of interest (specifically, martial arts and woodworking). Disjunction has a distinct visceral sensation for me. It gives me pause to ask questions not about potential future events, but about past events leading up to the present. I find I’m usually missing something about the history of events that either help sort out the indecision once known or cause me to think through better scenarios on emerging events that will influence the decision I’m trying to make.

References

1 Eldar Shafir’s chapter in “Cognition on Cognition” titled “Uncertainty and the difficulty of thinking through disjunctions”

Photo by Motoki Tonn on Unsplash

System Dynamics and Causal Loop Diagrams 101

Reading causal loop diagrams can be a little counter-intuitive. It will be important to understand how to read them in order to understanding the dynamic quality of the models that will appear in subsequent posts. The interactions between the various elements and the effects of those interactions on stocks and flows are typically represented by a solid black arrow (Figure 1.)

Figure 1

“A” has an interaction with “B” and that interaction is in the direction of “A” to “B.” But what’s the effect of “A’s” interaction with “B?” To display this effect, a green open head arrow or a red closed head arrow is used to describe the type of interaction between the two elements.

Figure 2
Figure 3

A green open-head arrow (Figure 2) is a direct relationship. A red closed-head arrow (Figure 3) is an inverse relationship.

To help understand these relationships, consider the analogy of being in the driver’s seat of a car. Imagine the car has a constant speed of 40 miles per hour. The car has been designed to go this speed with your feet off the peddles. (Not a particularly safe design feature, I’ll grant. But this is a thought experiment. So ride along with me for a little while. I promise we won’t crash.) Now, when you increase (↑) pressure on the gas peddle the car’s speed increases (↑). If you then decrease (↓) pressure on the gas peddle the car’s speed decreases (↓) until it returns to the original 40 MPH. That’s the direct relationship illustrated between “A” and “B” in Figure 2. As “A” increases, so does “B.” Increase pressure on the gas peddle and the speed of the car increases. As “A” decreases, so does “B.” Decrease pressure on the gas peddle and the car speed decreases until it slows down the the original 40 MPH. More of “A” results in more of “B” (↑↑) while less of “A” results in less of  “B.” (↓↓)

Now for the brake. If you increase (↑) pressure on the brake peddle the car’s speed decreases (↓) – it slows down to something less than 40 miles per hour. Increase the pressure on the brake enough and the car will stop. However, if you decrease (↓) pressure on the brake the car’s speed begins to increase (↑). If you remove all pressure on the brake peddle, the car returns to the constant 40 mile per hour speed. That’s the inverse relationship illustrated between “A” and “B” in Figure 3. As “A” increases, “B” goes the opposite way and decreases. Increase pressure on the brake peddle and the speed of the car decreases. As “A” decreases, “B” goes the opposite way and increases. Decrease pressure on the brake and the speed of the car increases until it is once again moving at 40 MPH. More of “A” results in of less of “B” (↑↓) while less of “A” results in more of  “B.” (↓↑)

For an example of these relationships in action, let’s look at the dynamics behind two cosmic quandaries: Which came first, the chicken or the egg and why do chickens cross the road?

No matter which came first, eggs come from chickens and chickens come from eggs. If the number of eggs increase, the number of chickens will increase. If the number of eggs decrease, the number of chickens will decrease (Figure 4.)

Figure 4

If the number of chickens increase, the number of eggs will increase. If the number of chickens decrease, the number of eggs will decrease (Figure 5.)

Figure 5

These are direct relationships as described for Figure 2. Taken together, the causal loop diagram is shown in Figure 6.

Figure 6

If times are good, there are more and more eggs leading to more and more chickens and Chicken World starts to get a bit crowded. In search of a better life, some of the chickens decide to cross the road (now you know why they cross the road!) Another direct relationship in the system (Figure 7.)

Figure 7

However, life is so good on the other side of the road that chickens never cross back over to where they started. An increase in the number road crossings result in a decrease in the number of chickens. (Figure 8.) This is an inverse relationship as described for Figure 3.

Figure 8

Connecting all the pieces, the very simple causal loop diagram describing Chicken World is shown in Figure 9.

Figure 9

This simple example illustrates how systems stay balanced. If there are too many eggs, leading to too many chickens, more chickens cross the road until the population is restored to a sustainable level. If too many chickens cross the road, the number of chickens decrease and therefore so do the number of eggs which means there are fewer chickens crossing road. Once again, the population is eventually restored to a sustainable level.

That’s all the system dynamics you’ll need to read the causal loop diagrams presented in subsequent posts.