Estimating Effort – Adaptation

I’ve been running the informed intuition (or if you prefer, “disciplined intuition”)  approach to estimating effort for close to nine months now. For the most part, it has gone very well. The primary objective – inspire and support a conversation around the effort needed to complete a story – has most definitely been realized. Along the way the process has shifted to better support both the conversation and the team’s ability to internalize the process.

Originally, it was proposed that teams rate each of the effort characteristics on a sliding scale – 1 to 10 or 1 to 15, or whatever the team decided was most useful. Feedback from the teams lead to the discovery that it is easier to evaluate each effort characteristic using the modified Fibonacci scale rather than a sliding scale. This provides continuity across the method in that everything about a story’s effort value is considered using the same scale. It also reinforces the rationale behind the use of the Fibonacci scale and seems to facilitating the team’s ability to internalize the method. They are moving more quickly when deriving effort values.

A second adaptation is the use of several sets of characteristics, depending on the type of story, the predominant functional area represented by the team, and the nature of the work. For example, a story that involves the development of a computer board has a different set of criteria from stories that involve the creation of firmware for the board or the UI/UX features of the hardware product. The sets usually contain 3 or 4 common characteristics, such as “complexity” or “dependencies.” However, the hardware board may include something like “part sourcing” or “compliance testing.” This illustrates the importance of having the team deconstruct what “effort” means in the context of their world. When they determine the characteristics, the follow-on conversations about the effort are much more robust and meaningful.

In essence, this method is a reflection of the product owner’s responsibility for the “what” of the story and the team’s responsibility for figuring out the “how” of the story. “What I want,” says the product owner, “is an estimate of the effort involved to complete this story.” The teams effort criteria demonstrate to the product owner how they arrive at any particular value.

Determining Effort Value – Tactics

While the concept and practice is straightforward, shifting a team from intuitive guesses about story points to a more deliberate approach for determining effort value (a.k.a. story points) can be a challenge at first. The following approach may help start the process.

  1. Begin by focusing on product backlog items (PBIs) that the team has estimated using their previous approach that are at a 5 or greater. There isn’t much to be gained by applying this approach to PBIs estimated at 1 or 2. PBIs that the team knows are a bigger effort but may not be able to articulate why that is the case are good candidates for learning how to apply this technique.
  2. Ask the team how much time it may take to complete a PBI. While I have written before about the importance of excluding time criteria when determining effort values, this can be a good place to start. It is what teams are most familiar with – for better or worse. Teams usually have not problem throwing out a time: 8 hours, 16 hours, etc.
  3. With the time estimate in hand ask the team:

“If you sit in front of your computer and start the clock, will the PBI be done if you do nothing and the estimated time elapses?”

I would hope the team would answer “No.”

  1. With the answer to the first question in hand, ask the following question:

If the passage of time alone won’t get the PBI work completed, what will you be doing (actions and behaviors) to complete the work?

The conversation that follows from this questions is the basis for determining the effort criteria the team needs to better describe what they will be doing on their way to completing the PBI. The techniques around establishing effort criteria are described in an earlier post.

The Perfect System in an Imperfect World

With apologies to Winston Churchill,

Many forms of project management have been tried, and will be tried in this world of sin and woe. No one pretends that Scrum is perfect or all-wise. Indeed, it has been said that Scrum is the worst form of project management except all those other forms that have been tried from time to time.

Agile in general, and scrum in particular, has suffered their share of hard yet deserved knocks. But many of these complaints come from people who are expecting perfection, some panacea or magic remedy to what ails their project management world. Often they want this perfection out of the box and miss the hard work needed to implement a relatively simple set of rules and guidelines while shifting from the “old ways” of getting work done.

Consider a flock of geese.

Over the course of hundreds of thousands of years they have worked out an efficient way to migrate. Not perfect, but well adapted to the world in which they live. At the heart of this behavior are several important principles: Shared responsibility, clear communication, and coordinated effort.

Consider Agile similarly. It is a perfect system for an imperfect world. The principles found in the formation of a flock of geese can be found within the Agile Manifesto. Its foundation of assuming the need for experimentation, learning, and adaptation is central to it’s enduring success. If these values are absent from or poorly represented in an organization’s culture, the chances for sustainable success using any methodology are diminished.

Photo by Josh Massey on Unsplash

Time Out!

In Estimating Effort – An Explicitly Implicit Approach I stated that time cannot be one of the attributes the team uses to describe what they mean by “effort.” The importance of this warrants the need for a deeper dive into the rationale behind this rule and how excluding time can lead to better predictability for team performance.

The primary objective for coaching teams to think about effort independent of time constraints is so that they can improve their skills for thinking about the actual work involved. Certainly they will spend time completing the work. But the simple passage of time won’t get the work done. Someone has to actually DO something. That something is the effort.

For example, maybe someone on the team says the product backlog item requires a lot of documentation. It isn’t complex and there aren’t any dependencies, it’s just going to take a lot of time – 7 days, maybe. So they want to give that PBI an effort value of 5 or 8 (or 5 or 8 story points, if that’s what you’re using) because it’s going to take a lot of time.

Remember, the purpose of these criteria is to generate a conversation around what the actual effort is. The criteria are just a set of guideposts that help the team hold a meaningful conversation about the effort.  So when someone on a team insists that they estimate using time, I ask them “What are you doing as the time you’ve estimated is passing? Are you just sitting there, watching the seconds tick away?” Of course they aren’t just sitting there. I’m asking the questions to elicit a comment about the actual work they are doing. Maybe they answer with something a little less vague, like “typing words.” That’s good. “What’s the difference between typing those words in a word processor and typing code in Vim?”

Continuing down this line of inquiry usually leads to the realization that typing documentation has many similar traits to coding. It can be complex. It may have dependencies.  It may require research for accuracy and it certainly will need a lot of debugging (professional writers call this “editing.”) Coders typically don’t like writing documentation. To them it’s just about the tedium of banging something out that’s not as fun as code. Sussing out the effort like this will lead to better acceptance criteria and definition of done associated with the PBI.

The downside of time estimates is that they hide all manner of sins and rabbit holes. The planning fallacy, precision bias, availability heuristic, and survivorship bias are just a few of the mental obstacles guaranteed to reduce the accuracy of time estimates. Or you may have to deal with a team member who wants to estimate using time because they know full well it offers the opportunity to hide slow work. (Gamers gotta game.) When teams have run the gauntlet of effort criteria, they are more likely to end up with a better picture of how much work they are being asked to do when time is excluded from the conversation. Effort criteria force the team to be more explicit about the activities they are engaged with as the clock ticks.

The investment in identifying time-independent effort criteria yields further benefits in the retrospective. Was the team unable to complete a PBI in the sprint? Was all the work finished two days early? Have a look at the effort criteria and ask which of them were a factor in making the PBIs a bigger or smaller effort than initially estimated. This is how teams learn and improve their skill at estimating. The better they are at estimating the more predictable their productivity.

OK, so let’s say you have a team doing a great job of determining the effort needed to complete a PBI and they do so without including time. No doubt, management will be unimpressed. They want time estimates. Good news! We can give them time estimates…in two week increments.

With the team focused on figuring out time independent effort values for every PBI in the backlog and an ongoing experience of how much effort they can reliably complete in two week increments, product owners can provide a reasonable forecast for when the release or project will be complete. The team focuses on accurate time independent effort estimates. The scrum master and product owner worry about the performance metrics and time projections.

It’s surprising how hard of a sell this can be for teams. They are hard wired to think in terms of time because that’s what traditional project management has hounded them for since before coding was a thing. I tell teams, “With Agile and scrum, you no longer have to worry about time. That’s the product owner’s job. But you do have to develop very good skills at estimating effort.” It’s common for them to have a hard time adjusting to the new paradigm.

Broken Windows and Broken Scrum

Recently, I was in a conversation with a scrum master that was of the opinion that correcting teams on all the small details of practicing scrum was the best way to develop them into a high performing team. For example, if someone is a minute late to stand-up, call them out. Or the daily stand-up must not deviate from the “Yesterday, today, and in the way” script regardless how well the team is communicating.

I can see the merits of developing discipline. However, this approach reminds me of the Broken Windows Theory of crime reduction. Without explanation or coaching that includes the rational for practicing scrum in such a way, there is a real possibility for negative unintended consequences.

  • The Broken Windows theory was meant to be applied to situations in need of a reduction of crime. To apply this approach to scrum practices is to imply that any deviation from the scrum framework is criminal.
  • Similar to how the Broken Windows theory resulted in the emergence of “zero tolerance” laws, applying such an approach to scrum teams and strictly enforcing how they may or may not follow the scrum framework is likely to result in a lot of command-and-control zero tolerance behaviors. The guides will become rules and, in turn, inflexible laws.

The approach I’ve found to be more effective is to hunt down the root causes to issues, for which being late to stand-ups or poor communication during stand-ups are a symptom. It’s more like being a big game hunger. Seek out the root of the problem, solve that problem, and it’s likely many of the lesser issues will resolve themselves.

Estimating Effort – An Explicitly Implicit Approach

It is difficult to make predictions, especially about the future.Unknown

Sage advice.

So why bother estimating the amount of work needed to complete a product backlog item? After all, since estimates are about the future the probability is high that they will be wrong. Actually, they may very well be guaranteed to be wrong. It’s just that some of the guesses will be more accurate than others. And if they happen to match what the effort ended up to be, they just look like they were “right.”

I’ve written in the past expressing my thoughts about estimating the effort needed to complete product backlog items, particularly with respect to story points. I believe working to find a relative gauge to how well teams are estimating work is important. Without them, cognitive biases such as the optimism bias and planning fallacy can significantly distort a project delivery timeline. However, the phrase “story point” is burdened with a lot of baggage. It has been abused and misused such that invoking the phrase often causes more harm than good.

I’ve been experimenting recently with a different approach to estimating effort. The method I’ll describe in this post got a bit of a boost after listening to a recent interview with Psychologist and Nobel laureate Daniel Kahneman. In this interview, Kahneman describes an experience he had while serving in the Israeli army some sixty years ago. He was assigned the job of setting up an interview process that would determine how well a recruit would do as a combat soldier. For this process, he selected six traits and instructed the interviewers to ask questions designed to evaluate each trait independently and score them. The interviewers were not happy with this approach. As a compromise, Kahneman instructed the interviewers, when they were finished asking about the six traits, to close their eyes and just jot down a number they felt matched how good a soldier the recruit might be. What he discovered:

When we validated the results of the interview, it was a big improvement on what had gone on before. But the other surprise was that the final intuitive judgments added, it was good. It was as good as the average of the six traits, and not the same. It added information, so actually we ended up with a score that was half determined by the specific ratings, and the intuition got half the weight. That, by the way, stayed in the Israeli army for well over 50 years.Daniel Kahneman

This intuitive evaluation made by the interviewers is similar to what Agile methods ask of development teams when determining a value for “story points.” T-shirt sizes, planning poker, dot voting, affinity mapping and many similar techniques are all designed to elicit an intuitive sense of the effort involved. If there is a disagreement between team members, than a dialog follows to understand what the discrepancy is all about. This continues until there is alignment on what the team believes the effort to be. When it works, it works well.

So on to the details of the approach I’ve been experimenting with. (It doesn’t have a name yet.) The result of this approach is a number I call the “effort value.” The word “value” is a reference to the actual elementary mathematics value being derived. Much like the answer to the question “What value results from adding 2 and 2?” Answer: 4. The word “value” also suggests an intrinsic worth, something beyond a hard number. My theory is that this will help teams think beyond the mere number and think also about the value they are delivering to stakeholders. The word “point” correlates to a hard number and lacks any association to intrinsic worth or value.

Changing the words introduces a simple and small shift that nonetheless has a significant impact. With the change, teams are more open to considering a different approach to determining estimates.

So how is the effort value derived?

I begin by having the team define 4-5 characteristics or attributes that, to them, describe what they mean by “effort.” It is important for the team to define these attributes. By doing so, they own the definition and it becomes much harder for them to dismiss the attributes as “someone else’s” and thereby object to their use in deriving an effort value. These attributes can be anything that is meaningful to the team. Examples:

  • Complexity – Is the work straightforward (e.g. code a bubble sort function) or does it involve interrelated systems (e.g. code a predictive inventory control algorithm)?
  • Dependencies – How dependent is the product backlog item on other backlog items or other teams?
  • Familiarity – Is this work very similar to work the team has done in the past or something quite new? Tasking a coder with documenting a piece of straightforward code may actually be a difficult effort because the coding language they spend most of their day with is familiar whereas writing clear sentences that non-technical people can understand is unfamiliar.
  • Information – Is the detail in the product backlog item complete? Are the acceptance criteria and definition of done clear?
  • Technical Debt Risk – Does the PBI require any refactoring of related code? Is any technical debt being incurred with the PBI?
  • Design Stability – Is there a lot of discovery and exploration needed to complete the PBI?
  • Confidence for Completing a PBI within the Sprint – This category may roll up several categories.
  • Tedium – Perhaps the effort involves a lot of repetitive copy and paste that nonetheless requires careful attention to avoid simple mistakes.

The team can define any attribute they wish. However, there are a few criteria to consider:

  • Keep the list limited to 4-6 attributes. More than that risks turning the derivation of an effort value into the equivalent of a product backlog item navel-gazing exercise.
  • Time cannot be one of the attributes.
  • The attributes should be reasonable. Assessing a product backlog item’s effort value by evaluating it’s “aura” or the current position of the stars are generally not useful attributes. On the other hand, I’ve listened to arguments against evaluating estimates in terms of “complexity” as being similarly useless. I see the point of those arguments, but my view is that the attributes must first and foremost be meaningful to the entire team. In the end, it’s an educated guess and arguments about the definition of terms like “complexity” are counterproductive to the overall intent of deriving an effort value.

Each of these attributes is then given a scale, the same scale for each attribute – 1 to 10, 1 to 15 – whatever the team feels is most appropriate. The team then goes through each of these attributes and evaluates the product backlog item attribute on the scale. (NB: After nine months of Plan-Do-Check-Adapt, a better approach for scoring the attributes has been determined.) The low number on the scale represents very little impact. If dependency, for example, is one of the attributes then a 1 might mean that the product backlog item is entirely self-contained. A 10 might represent a case where the product backlog item is dependent on several other product backlog items or perhaps the output from other teams.

When this is done, ask the team where on the modified Fibonacci scale they think this particular product backlog item’s effort value should be. If they’re struggling you can do the math: find the average for all the attributes and match that number in the modified Fibonacci scale. If the average is a decimal, for example 3.1, match the value to the next highest modified Fibonacci scale number. In this case the value would be 5. Then ask the team if they feel that number it’s a good representation of the effort value for the product backlog item.

This may seem like a lot of unnecessary gyrations, but for technical people it’s a simple process they can understand. The bonus is a number they can calculate. The number isn’t what’s important here. What’s important is the conversation that happens around the attributes and what the team feels about the number that results from the conversation. This exercise is meant to develop their intuitive muscles for considering multiple aspects and dimensions behind the “effort” needed for them to get the work done.

Use this process enough times and eventually calculating the average can be dropped from the process. Continue using this process and eventually calculating the numbers for the individual attributes can be dropped from the process. I don’t know if it’s a good idea to drop the use of the attributes for generating the needed conversation around the effort needed, but it will certainly be valuable to reconsider the list of attributes from time to time so as to fine tune the list to match what the team feels is important.

With this approach I’m turning the estimation process on its head (or back on its feet, if Kahneman is right.) Rather than seek the intuitive response first (e.g. t-shirt size) and elicit details later if there is a mismatch between team members, this method seeks to better prime and develop the team’s intuition about the effort value by having them explicitly consider a list of self-selected attributes (or traits) for effort first and then include an intuitive evaluation for effort.

Don’t try to form an intuition quickly, which was what we normally do. Focus on the separate points, and then when you have the whole profile, then you can have an intuition and it’s going to be better. Because people form intuitions too quickly, and the rapid intuitions are not particularly good. If you delay intuition until you have more information, it’s going to be better.Daniel Kahneman

Update

See Time Out! and Determining Effort Value – Tactics for additional information on this technique.

Openness, Grapevines, and Strangleholds

If you truly value openness on your Agile teams, you must untangle them from the grapevine.

Openness is one of the core scrum values. As stated on Scrum.org:

“The scrum team and it’s stakeholders agree to be open about all the work and the challenges with performing the work.”

This is a very broad statement, encompassing not only openness around work products and processes, but also each individual’s responsibility for ensuring that any challenges related to overall team performance are identified, acknowledged, and resolved. In my experience, issues with openness related to work products or the processes that impact them are relatively straightforward to recognize and resolve. If a key tool, for example, is mis-configured or ill-suited to what the team needs to accomplish than the need to focus on issues with the tool should be obvious. If there is an information hoarder on the team preventing the free flow of information, this will reveal itself within a few sprints after a string of unknown dependencies or misaligned deliverables have had a negative impact on the team’s performance. Similarly, if a team member is struggling with a particular story card and for whatever reason lacks the initiative to ask for help, this will reveal itself in short order.

Satisfying the need for openness around individual and team performance, however, is a much more difficult behavior to measure. Everyone – and by “everyone” I mean everyone – is by nature very sensitive to being called out as having come up short in any way. Maybe it’s a surprise to them. Maybe it isn’t. But it’s always a hot button. As much as we’d like to avoiding treading across this terrain, it’s precisely this hypersensitivity that points to where we need to go to make the most effective changes that impact team performance.

At the top of my list of things to constantly scan for at the team level are the degrees of separation (space and time) between a problem and the people who are part of the problem. Variously referred to as “the grapevine”, back channeling, or triangulation, it can be one of the most corrosive behaviors to a team’s trust and their ability to collaborate effectively. From his research over the past 30 years, Joseph Grenny [1] has observed “that you can largely predict the health of an organization by measuring the average lag time between identifying and discussing problems.” I’ve found this to be true. Triangulation and back-channeling adds significantly to the lag time.

To illustrate the problem and a possible solution: I was a newly hired scrum master responsible for two teams, about 15 people in total. At the end of my first week I was approached by one of the other scrum masters in the company. “Greg,” they said in a whisper, “You’ve triggered someone’s PTSD by using a bad word.” [2]

Not an easy thing to learn, having been on the job for less than a week. Double so because I couldn’t for the life of me think of what I could have said that would have “triggered” a PTSD response. This set me back on my heels but I did manage to ask the scrum master to please ask this individual to reach out to me so I could speak with them one-to-one and apologize. At the very least, suggest they contact HR as a PTSD response triggered by a word is a sign that someone needs help beyond what any one of us can provide. My colleague’s responses was “I’ll pass that on to the person who told me about this.”

“Hold up a minute. Your knowledge of this issue is second hand?”

Indeed it was. Someone told someone who told the scrum master who then told me. Knowing this, I retracted my request for the scrum master to pass along my request. The problem here was the grapevine and a different tack was needed. I coached the scrum master to 1) never bring something like this to me again, 2) inform the person who told you this tale that you will not be passing anything like this along to me in the future, and 3) to coach that person to do the same to the person who told them. The person for whom this was an issue should either come to me directly or to my manager. I then coached my manager and my product owners that if anyone were to approach them with a complaint like this to listen carefully to the person, acknowledge that you heard them, and to also encourage them to speak directly with me.

This should be the strategy for anyone with complaints that do not rise to the level of needing HR intervention. The goal of this approach is to develop behaviors around personal complaints such that everyone on the team knows they have a third person to talk to and that the issue isn’t going to be resolved unless they talked directly to the person with whom they have an issue. It’s a good strategy for cutting the grapevines and short circuiting triangulation (or in my case the quadrangulation.) To seal the strategy, I gave a blanket apology to each of my teams the following Monday and let them know what I requested of my manager and product owners.

The objective was to establish a practice of resolving issues like this at the team level. It’s highly unlikely (and in my case 100% certain) that a person new to a job would have prior knowledge of sensitive words and purposely use language that upsets their new co-workers. The presupposition of malice or an assumption that a new hire should know such things suggested a number of systemic issues with the teams, something later revealed to be accurate. It wouldn’t be a stretch to say that in this organization the grapevine supplanted instant messaging and email as the primary communication channel. With the cooperation of my manager and product owners, several sizable branches to the grapevine had been cut away. Indeed, there was a marked increase in the teams attention at stand-ups and the retrospectives became more animated and productive in the weeks that followed.

Each situation is unique, but the intervention pattern is more broadly applicable: Reduce the number of node hops and associated lag time between the people directly involved with any issues around openness. This in and of itself may not resolve the issues. It didn’t in the example described above. But it does significantly reduce the barriers to applying subsequent techniques for working through the issues to a successful resolution. Removing the grapevine changes the conversation.

References

[1] Grenny, J. (2016, August 19). How to Make Feedback Feel Normal. Harvard Business Review, Retrieved from https://hbr.org/2016/08/how-to-make-feedback-feel-normal

[2] The “bad” word was “refinement.” The team had been using the word “grooming” to refer to backlog refinement and I had suggested we use the more generally accepted word. Apparently, a previous scrum master for the team had been, shall we say, overly zealous in pressing this same recommendation such that it was a rather traumatic experience for someone on the one of the teams. It later became known that this event was grossly exaggerated, “crying PTSD” as a variation of “crying wolf,” and that the reporting scrum master was probably working to establish a superior position. It would have worked, had I simply cowered and accepted the report as complete and accurate. The strategy described in this article proved effective at preventing this type of behavior.

Behind the Curtain: The Delivery Team Member Role

Even with the formalization of Agile practices into numerous frameworks and methodologies, I have to say not much has changed for the software developer or engineer with respect to how they get work done. I’m not referring to technology. The changes in what software developers and engineers use to get work done has been seismic. The biggest shift in the “how,” in my experience, is that what were once underground practices are now openly accepted and encouraged.

When I was coding full time, in the pre-Agile days and under the burden of CMM, we followed all the practices for documenting use cases, hammering out technical and functional specs, and laboriously talking through requirements. (I smile when I hear developers today complain about the burden of meetings under Scrum.) And when it came time to actually code, I and my fellow developers set the multiple binders of documentation aside and engaged in many then unnamed Agile practices. We mixed and matched use cases in a way that allowed for more efficient coding of larger functional components. We “huddled” each morning in the passage way to cube pods to discuss dependencies and brainstorm solutions to technical challenges. Each of these became more efficiently organized in Agile as backlog refinement and daily stand-ups. We had numerous other loose practices that were not described in tomes such as CMM.

But Agile delivery teams today are frequently composed of more than just technical functional domains. There may be non-technical expertise included as integral members of the team. Learning strategists, content editors, creative illustrators, and marketing experts may be part of the team, depending on the objectives of the project. Consequently, this represents a significant challenge to technical members of the team (i.e. software development and  tech QA) who are unused to working with non-technical team members. Twenty years ago a developer who might say “Leave me alone so I can code.” would have been viewed as a dedicated worker. Today, it’s a sign that the developer risks working in isolation and consequently delivering something that is mis-matched with the work being done by the rest of the team.

On an Agile delivery team, whether composed of a diverse set of functional domains or exclusively technical experts, individual team members need to be thinking of the larger picture and the impact of their work on that of their team mates and the overall work flow. They need to be much more attentive to market influences than in the past. The half-life of major versions, let along entire products, is such that most software products outside a special niche can’t survive without leveraging Agile principles and practices. Their knowledge must expand beyond just their functional domain. The extent to which they possess this knowledge is reflected in the day-to-day behaviors displayed by the team and it’s individuals.

  • Is everyone on the team sensitive and respectful of everyone else’s time? This means following through on commitments and promises, including agreed upon meeting start times. One person showing up five minutes late to a 15 minute stand-up has just missed out on a third of the meeting at least. If the team waits for everyone to show up before starting, the late individual has just squandered 5 minutes multiplied by the number of team mates. For a 6 member team, that’s a half hour. And if it happens every day, that’s 2.5 hours a week. It adds up quickly. Habitual late-comers are also signaling a lack of respect to other team members. They are implicitly saying “Me and my time is more important than anyone else on the team.” Unchecked, this quickly spills over into other areas of the team’s interactions. Enforcing an on-time rule like this is key to encouraging the personal discipline necessary to work effectively as a team. When a scrum master keeps the team in line with a few basic items like this, the larger discipline issues never seem to arise. As U.S. Army General Ann Dunwoody (ret.) succinctly points out in her book, never walk by a mistake. Doing so gives implicit acceptance for the transgression. Problems blossom from there, and it isn’t a pretty flower. (As a scrum master, I cannot “make” someone show up on time. But I can address the respect aspect of this issue by always starting on time. That way, late-comers stand out as late, not more important. Over time, this tends to correct the lateness issue as well.)
  • Everyone on the team must be capable of tracking a constantly evolving set of dependencies and knowing where their work fits within the flow. To whom will they be delivering work? From whom are they expecting completed work? The answer to these questions may not be a name on the immediate team. Scrum masters must periodically explicitly ask these questions if the connections aren’t coming out naturally during stand-ups. Developing this behavior is about coaching the team to look beyond the work on their desk and understand how they are connected to the larger effort. Software programmers seem to have a natural tendency to build walls around their work. Software engineers less so. And on teams with diverse functional groups it is important for both the scrum master and product owner to be watchful for when barriers appear for reasons that have more to due to lack of familiarity across functional domains than anything else.
  • Is the entire team actively and consistently engaged with identifying and writing stories?
  • Is the team capable and willing to cross domain boundaries and help? Are they interested in learning about other parts of the product and business?

Product owners and scrum masters need to be constantly scanning for these and other signs of disengagement as well as opportunities to connect cross functional needs.

Behind the Curtain: The Product Owner Role

When someone owns something they tend to keep a closer watch on where that something is and whether or not it’s in good working order. Owners are more sensitive to actions that may adversely affect the value of their investment. It’s the car you own vs the car you rent. This holds true for products, projects, and teams. For this reason the title of “product owner” is well suited to the responsibilities assigned to the role. The explicit call-out to ownership carries a lot of goodness related to responsibility, leadership, and action.

Having been a product owner and having coached product owners, I have a deep respect for anyone who takes on the challenges associated with this role. In my view, it’s the most difficult position to fill on an Agile team. For starters, there are all the things a product owner is responsible for as described in any decent book on scrum: setting the product vision and road map, ordering the product backlog, creating epics and story cards, defining acceptance criteria, etc. What’s often missing from the standard set of bullet items is the “how” for doing them well. Newly minted product owners are usually left to their own devices for figuring this out. And unfortunately, in this short post I won’t be offering any how-to guidance for developing any of the skills generally recognized to be part of the product owner role.

What I’d most like to achieve in this post is calling out several of the key skills associated with quality product ownership that are usually omitted from the books and trainings – the beyond-the-basics items that any product owner will want to include in their continuous learning journey with Agile. In no particular order…

  • Product owners must be superb negotiators when working with stakeholders and team members. The techniques used for each group are different so it’s important to understand the motivations that drive them. I’ve found Jim Camp’s “Start with No” and Chris Voss’ “Never Split the Difference” to be particularly helpful in this regard.
  • One of the four values stated in the Agile Manifesto is “Responding to change over following a plan.” Unfortunately, this is often construed to mean any change at any time is valuable. This Agile value isn’t a directive for maximum entropy and chaos. Product owners must remain vigilant to scope changes. And the boundaries for scope are defined by the decisions product owners make. So product owners must be decisive and committed to the decisions, agreements, and promises that have been made with stakeholders and the team.
  • Product owners need to have a good sense for when experimentation may be needed to sort out any complex or risky features in the project – creating spikes or proof-of-concept work early enough in the project so as to avoid any costly pivots later in the project.
  • Even with experimentation, making the call to pivot will require a product owner’s clear understanding of past events and any path forward that offers the greatest chance for success. As the sage says, predictions are difficult to make, particularly about the future. The expectation isn’t for clairvoyance, rather for the ability to pay close attention to what the (non-vanity) data are telling them.
  • Understanding how to work through failures and dealing with “The Dip,” as Seth Godin calls it, are also important skills for a product owner. The team and the stakeholders are going to look to the product owner’s leadership to demonstrate confidence that they are on the right track.

More than other roles on an Agile team, the product owner must be a truly well-rounded and experienced individual. Paradoxically, it is a role that is both constrained by the highly visible nature of the position and dynamic due to the skill set required to maximize the chances for project success.

Behind the Curtain: The Scrum Master Role

It is popular to characterize the scrum master role as following a “servant leader” style of engagement with scrum teams. Beyond that, not much else is offered to help unpack just what that means. The more you read about “servant leadership” the more confused you’re likely to get. A lot of what’s available on the Internet and offered in trainings ends up being contradictory and overburdening to someone just trying to help their team excel. Telling someone they’ll need to become a “servant leader” can be like telling them to go away closer.

So let’s unpack that moniker a little and state what it means in more practical terms for the average, yet effective, scrum master.

To begin, it’s most helpful to put a little space between the two skills. As a scrum master you’ll need to serve. As a scrum master you’ll need to lead. When you’re a good scrum master you’ll know when to do each of those and how. Someone who tries to do both at once usually ends up succeeding at neither.

As a servant, a scrum master has to keep a vigilant eye on making sure their servant behaviors are in the best interests of helping the delivery team succeed. If the scrum master lets the role devolve to little more than an admin to the product owner or the team then they’ve lost their way. It will certainly seem easier to write the story cards for the team, for example, rather than spend the time coaching them how to write story cards. This is a case where leadership is needed. On the other hand, if someone on the team is blocked by a dependency due to a past due deliverable from another team, then the scrum master would indeed serve the best interests of the team by working with the other team to resolve the dependency rather than require the delivery team member to shift focus away from completing work in the queue.

As a leader, a scrum master has to recognize any constraints the context places on the scope of their responsibilities. In meet-ups and conferences I’ve heard people say the scrum master “should be the team spiritual leader,” the team “therapist,” or “a shaman,” and able to administer to the team’s emotional needs. I take a more pragmatic approach and believe a scrum master should be able to recognize when someone on their team is in need of a qualified professional and, if necessary, assist them in finding the help they need. (HR departments exists, in part, to handle these situations.) This is still good leadership. It’s important to recognize the limits of one’s own capabilities and qualifications. Scrum master as therapist is a quagmire, to be sure, and I’ve yet to meet one with the boots to handle it.

Servant leader aside, the “master” in “scrum master” is the source of no end of grief. It’s partly to blame for the tendency in people to ascribe super powers to the scrum master role, such as those described above. In addition, the “master” part of the title implies “boss” or “manager.” It is a common occurrence for team members to address their stand-up conversation to me – as scrum master – rather than the team. I have to interrupt and specifically direct the individual to speak to the team. I’ve had team members share that they assumed I was going to take what was communicated in the stand-up and report directly to the product owner or the department head or even higher in the organization. “How come you’re not taking notes?”, they ask.”The stand-up is for you, not for me. Take your own notes, if you wish,” I reply. (I do take notes, but only for the purpose of following-up on certain issues or capturing action items for myself – things I need to do to remove impediments that are outside the team’s ability to resolve, for example.)

All the downside of what I’ve describe so far can be amplified by the Dunning–Kruger afflicted scrum master. Amplified again if they are “certified.” To paraphrase from the hacker culture on how you know you’re a hacker (in the classical sense), you aren’t a scrum master until someone else calls you a scrum master. There is always more to learn and apply. A scrum master who remains attentive to that fact will naturally develop quality servant and strong leadership skills.

Finally, the scrum master role is often a thankless job. When new to a team and working to establish trust and credibility the scrum master will need to build respect but often won’t be liked during the process. Shifting individuals out of their comfort zone, changing bad habits, or negotiating 21st Century sensitivities is no easy task even when people like and respect you. So a quality scrum master will work to establish respect first and let the liking follow in due course.

Having succeed at this the scrum master’s business will likely shift to the background. So much so some may wonder why they’re taking up space on the team. Working to establish and maintain this level of performance with a team while remaining in the background is at the heart of the servant part of servant/leader.