Agile Interns

I had the privilege of presenting to a group of potential interns from the Colorado School of Mines interested in agile project management. Action shot…

The slide shows what we can offer them as interns: Failure, chaos, and confusion. I unpacked that as follows…

Failure

It’s important interns have the opportunity to learn how to fail in small, deliberate and safe increments along with the opportunity to learn how to extract every possible lesson from failures and how those failures lead to eventual success. Much of our business is driven by experimentation and hypothesis testing. Most of those experiments will fail, at least initially.

Chaos

We strive to be anti-fragile. One way to accomplish this is to be good at working under chaotic and ambiguous conditions. When involved with highly evolutionary design sessions, shifting sands can seem like the most solid ground around.

Confusion

One of the values for bringing interns into the organization is the fresh perspective they offer.  Why waste that on having them fetch coffee? However, interns can often be intimidated by working with people who have decades of experience under their belt. So it’s important they know they have the opportunity to work in an environment that expects questions and recognizes no one knows it all. They are in an environment that  seeks alternative points of view. In this organization, everyone gets their own coffee.

Waste

What comes to mind when you think of the word “waste?” I’d wager a ten spot it wasn’t something pleasant. Rather, something to be pushed to the curb, rinsed down the drain, or thrown into a hole in the ground and buried. Even the sterile waste from technology projects has a high “ick” factor. If Josef Oehmen and Eric Rebentisch of MIT’s Lean Advancement Institute put the amount of time, money, and resource waste in corporate product development at 77%, how can there be anything good about waste?

Now think of something you value quite highly – a piece of fine jewelry, mastery of a sport or musical instrument, or your home. Have you considered how many resources may have been “wasted” to bring those highly valued things into existence? Shiny diamonds get that way by cutting and throwing away pieces of the original, mastering a sport or a musical instrument involves years filled with bad moves or cringe worthy sounds, and a significant amount of material was used and discarded while building your home.

When organizations consider implementing one of Agile’s many formalized methodologies or frameworks, the idea of eliminating waste is a prominent promise that helps close the sale. Cutting out waste means saving money and saving money means increasing profits. Unfortunately, this promise is frequently delivered to the agile teams as: “All waste is bad. Get it right the first time.” This message doesn’t support exploration and discovery. It doesn’t allow teams the space they need to find innovative solutions in what Stuart Kauffman called the “adjacent possible.” And it certainly doesn’t encourage the iterative development of numerous minimum viable products that build upon each other and lead the way toward the delivery of quality products.

The message I work to reinforce is: “Expect to throw stuff away, especially early on.” By itself, this isn’t enough to overcome the many negative connotations around waste. What is needed is a fundamental re-framing around the activities that have resulted in something one expects to throw away. A couple of questions are worth asking. What value is anticipated from the activity? What are the potential positive effects of having engaged in an effort at risk for ending as waste? Pursuing a goal of zero wasted effort is a fool’s errand. What we want to reduce is any effort that doesn’t add value. If 40 hours were spent exploring a technical option “only” to find out that it wasn’t a viable option in the long term, that throw-away 40 hour effort may just have saved 400 hours of developer time spent trying to make it work. And had the less-than-optimal long term option gone to market, the expense of supporting the early wrong decision could make or break the product, perhaps even the business.

Skilled agile practitioners have a strategy for monitoring the value of any project related efforts:

  • Establish definitions of activities that create value. By identifying the intent behind the effort and acknowledging the value, the team is better positioned for focusing on the goals and objectives of the activity. Discovery, exploration, risk assessment, even fun can be worthwhile justifications if it is clear they add value to the overall effort and end goal success.
  • Identify efforts that are wasteful, but nonetheless necessary, and work to minimize the effects of these efforts. Transitioning from a design sprint to actual production work often results in a lull in activity as the design team works to communicate to the production team what needs to be done. Similarly, when production work is handed off to deployment, support, and maintenance teams.
  • Identify clear signs of waste. Gold-plating (over-engineering), lack of a product vision or road map that causes the agile team to “make it up as they go along” and react to the customer’s reaction, infrequent opportunities for feedback (both inter-team and with the client), or time-tracker cards that attract dozens of hours of nondescript time.

From a lean product development perspective, Oehmen and Rebentisch describe eight types of waste. I’ve included my additions and comments in parenthesis.

  • Overproduction of information
    • Two different groups creating the same deliverable
    • Delivering information too early
  • Over-processing of information
    • Over-engineering of components and systems (Often referred to as Gold-platting.)
    • Working on different IT systems, converting data back and forth (The use of one-off tools rather than leveraging the capabilities within the organization’s suite of tools.)
  • Miscommunication of information
    • Large and long meetings, excessive email distribution lists
    • Unnecessary hand-offs instead of continuous responsibility
    • (Unacknowledged project dependencies, such as the effect of re-architecting system components, on client projects.)
  • Stockpiling of information
    • Saving information due to frequent interruptions
    • Creating large information repositories due to large batch sizes
    • (Withholding opportunities to review work and solicit feedback.)
  • Generating defective information
    • Making errors in component and architecture design
    • Delivering obsolete information to down-stream tasks (Insufficient feedback opportunities, delays in communication due to competing project responsibilities.)
  • Correcting information
    • Optimization iterations (Rework)
    • Reworking deliverables due to changing targets (Design ambiguity, client decision instability)
  • Waiting of people
    • Waiting for long lead time activities to finish
    • Waiting due to unrealistic schedules
  • Unnecessary movement of people
    • Obtaining information by walking up and down the hallway
    • Traveling to meetings

References

Kauffman, S.A. (2003). The Adjacent Possible, A Talk with Stuart A. Kauffman. Retrieved from https://www.edge.org/conversation/stuart_a_kauffman-the-adjacent-possible

Oehmen, J., Rebentisch, E. (2010). Waste in Lean Product Development. Lean Advancement Initiative. Retrieved from http://hdl.handle.net/1721.1/79838

Remote Teams: Non-verbal Communication

Scrum mastering remote teams demands an extra set of skills than those required for co-located teams. The non-verbal cues we’ve learned growing up and throughout our careers are often not available with remote teams. Consequently, we have to train our ears to listen more attentively and follow-up to verify any assumptions regarding meaning from conference call, email, or instant message communications.

As scrum masters, we also need to coach team members to deliberately introduce practices that accommodate the lack of non-verbal cues during scrum meetings. For example, there are two practices I implement during remote stand-ups that facilitate the feel of co-located stand-ups.

  1. I call out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. I’ve found this keeps the rest of the team focused on the conversation better as they won’t know when they’ll be called.  Everyone will have to track who has already presented to the team. In the past I would randomly call out names until everyone on the team had their chance to speak. While they didn’t know when their name would be called they could still count on me to make sure everyone had their turn. Frequently, however, I’d have to call out a name several times to get that person’s attention away from whatever it was they were “multitasking” on. Having the team call out the next person to present has helped resolve this issue.
  2. After the team member has presented and before they pass the conversation to the next team member, I coach them to pause and ask if there are any questions from the team. In addition to signaling the end of their presentation, this makes the remote stand-up a little less mechanical and puts the thought “Do I have any questions?” in the minds of the rest of the team. More specifically, I coach the team with some version of the following: “Pause after your presentation and ask the team if there are any questions, observations, suggestions, comments, or clever remarks.”

Using techniques like this with remote teams does not replace the richness of co-located scrum meetings. They do, however, move the two a little closer.

Agile in the Wild

There are some decidedly Zen-like paradoxes to practicing almost any form of agile methodology. People practice agile everywhere, yet they have a hard time finding it at work. It’s the most natural form of technical project management I’ve experienced, yet people seem determined to make it harder than it is and over-think the principles. And when they shift toward simplifying their agile practice, they go contrary to good advice that everything should be made as simple as possible, but not simpler.

So a challenge: Before the month is out, take a moment to reflect on some important task you completed that had nothing to do with work and see how many things you did reflect an agile principle or common practice. Maybe it’s work you did on a hobby or at a volunteer gig. Perhaps it involved some kitchen wizardry, a tactful communication maneuver with your children, or routine house maintenance. Did you iterate across several possible solutions until you found success? Did you decide to decide something later so that you could gather more information? Did you take a particular task to “good enough” so that you could complete a more urgent related task? And which of your insights can you bring into work with you?

In this article I’ll describe a recent experience with Agile in the Wild and the lessons that can be applied in your work environment.

(Click for larger image.)
(Click for larger image.)

The end result was a not-quite-bent-enough piece of wood (Westie terrier, “Rose,” for scale.) The wood needed to be steamed again.

(Click for larger image.)

Version 1 of the steamer was modified such that the drip pan was flipped (1) for a better seal on the kettle, metal piping (2) replaced the PVC, and a more flexible radiator hose (3) was used for easier positioning. Version 2 of the steamer was a significant improvement. I got better steam output from this rig so the lignin in the wood was a little easier to bend in a shorter amount of time. Most importantly, a throw-away jig (4) was built for much better clamping.

(Click for larger image.)

Must have safety feature: An anti-curious-dog flame guard made out of sheep fence (1). Curious dog (2) optional.

(Click for larger image.)

After bending and clamping in place the steam was removed, the plastic cut away, and the wood left in the shop until I had free time to unclamp the oak from the jig. With the jig I was able to clamp the wood at multiple places across the arc. And no worries about damaging the expensive walnut of the actual table top.

(Click for larger image.)

Back in the shop, the edge is glued, clamped, and left to set after dealing with an unexpectedly uncooperative bend that shows signs of having been cut from stock near a knot (1).

(Click for larger image.)
(Click for larger image.)

Agile Lessons

  • Get help. Someone already knows the solution you seek, or most of it anyway.
  • Short cuts are often the long way to get to where you are going.
  • The MVP: Goes together fast, is cheap, built just good enough to actually test in the wild (safely, I would add.)
  • Reuse existing assets that are adapted to suit the current need (Can equipment used for brewing beer be used in fine woodworking? Absolutely! All you have to do is think outside the brew kettle.)
  • The Jig: It isn’t part of the final product. In all likelihood it won’t ever be used again. Was it waste or an essential part of getting to the final product? Design flow diagrams and wireframes are analogous to jigs. You’re supposed to throw them away! Think how utterly horrific our final products would be if we included all the interim work in what we delivered to the client.

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 one. 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.

There is a dangerous inertia to “best” practices that 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. 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.

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

Practicing Agile – Building Mastery One Day At A Time

Old joke: A young couple visiting New York City for the first time has lost their way. They spot a street musician, just the person to help them get reoriented. “Excuse us, but can you tell us how to get to Carnegie Hall?” The musician stopped playing and thought for a moment before replying: “Practice.”

The prevailing wisdom is that it takes 10,000 hours of practice to achieve the level of mastery in any particular field of endeavor. Turns out, this is true for fields with well-defined measures for excellence like chess and music. In each of these areas, the rules are relatively simple, but mastering them isn’t easy. It’s pretty easy to tell when someone is playing an instrument out of tune or off-beat. And yet, a pawn shop guitar in the hands of Joe Satriani or Liona Boyd will likely result in that instrument expressing a voice no one knew it had. As for chess masters, they’re the ones who win against all challengers regardless the time or place of the match.

For areas of human endeavor where the edges are less well defined, like business or coaching, there may be no marker for how much practice it takes to reach a stable mastery. Having successfully started and built one business does not guarantee the next venture will be equally successful. A coach with a winning system for one team may end up at the bottom of the ranks when the same system is used with a different team.

Developing expertise with scrum is a blend of both of these. The rules are simple, but they are not easy to master. At the same time the territory isn’t well defined and frequently changes. A new client, a new team, or a new project and the edges for what is possible change. Misunderstanding this has been at the root of much of the frustration I’ve observed among people new to agile. They come from a world with well-defined edges – traditional project management practices filled with Gantt charts, milestones, functional specifications, use cases, deployment requirements, and a plethora of other artifacts that “must” be in place before work can begin. As many unknowns as possible must be made known, risks pounded down to trivial annoyances, and all traces of ambiguity squeezed out of the project plan. Learning how to let go of deeply rooted practices like this is no small thing. We like the comfort of well-defined rules. And when there’s work to be done with scarce resources to make it happen, we reach for the rules most familiar to us.

So how can we update the tried-and-true, super comfy confines of past practices and rule sets?

Practice.

Research following on the “10,000 hours of practice” generalization has shown that it isn’t just that someone has completed 10,000 hours of practice. The critical factor was how they practiced. Was each hour spent completing the same motions and behaviors from the previous hour or were they spent building on successive experiences, seeking greater challenges, and developing a deeper understanding of their craft? Following the latter path leads to the incremental improvements required to build mastery. And once obtained, the same attitude toward practice helps sustain a level of mastery. There will always be something more to learn, a fresh perspective to experience, or a more satisfying way to experience success.

There is a great deal of neuroscience at the foundation of practice and few would dispute the value of learning how to learn. And yet as our experience grows and we master a particular field, it’s deceptively easy to fall into a complacency of thought whereby we convince ourselves there isn’t anything else to learn. That is until some seismic paradigm shift makes it clear the rules have changed and we’d let our mastery go stale. The consequences of this are captured by Greene (2012) in his book, Mastery:

“We prefer to live with familiar ideas and habits of thinking, but we pay a steep price for this: our minds go dead from the lack of challenge and novelty; we reach a limit in our field and lose control over our fate because we become replaceable.” (pg. 176)

If this happens, learning how to learn may not be enough. Learning how to unlearn may be equally valuable for regaining mastery.

In classic hacker culture, you aren’t a hacker until other recognized hackers call you a hacker. It’s a title to be earned, not claimed. The unfortunate title of “scrum master” aside, it is useful to take this credentialing tradition to heart with scrum as well. Consider yourself an apprentice scrum practitioner until other recognized scrum masters recognize your mastery. Holding such a frame keeps us humble, curious, and open to constant and never ending improvement.

I’ve been practicing, leading, or coaching scrum in one capacity or another for over 10 years and based on my billable hours over the past several years, I’m quite confident I’ve passed the 10,000 hour mark for practicing scrum. Even so, I’m not a master scrum master…yet. The reason is simple and is expressed by the great cellist Pablo Casals’ response to filmmaker Robert Snyder’s query as to why Casals continues to practice five hours a day at 80 years of age, “Because I think I am making progress.” I keep building upon my practice because each day I discover new ways to enhance team performance and improve my skills. Perhaps more telling, any time I think I’ve heard every excuse for not following the scrum framework, someone on one of my teams surprises me.

If you’re interested in staying on the path toward scrum mastery, you need to get out of the books and into the world. There are a variety of ready opportunities to mark and gauge your progress.

  • Frequently review the framework for scrum and compare what’s there with your current projects. If there are mismatches, find out why. Is there really a good reason for straying from the framework? If so, open a dialog about these differences during your retrospectives.
  • If possible, ask your fellow agile practitioners when they are holding their next review, backlog refinement, or sprint planning session and get yourself invited as an observer.
  • There are probably a number of excellent agile related meet-ups in your area. Speaking from personal experience, these are incredibly valuable communities of support and new ideas.

References

Greene, R. (2012). Mastery. New York, NY: Viking Penguin

This article was originally published by the Scrum Alliance under Member Articles.

Moving Past “I Don’t Know”

Recently I had the opportunity to attend the Mile High Agile 2015 conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve  been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”

This article was originally published by the Scrum Alliance under Member Articles.

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.

Page 4 of 41234