Context Considered: Focusing Agile Investments for a Better Return

 Leadership/Team Feedback Loop

Leadership/Team Feedback Loop

Organizations invest a lot of money, time, and energy in Agile. Arguably we’re decades into the Agile game. We should be pretty good with this Agile stuff by now. So why are we not consistently seeing good results? Why do some Agile initiatives fizzle out? Why do some organizations abandon Agile in favor of the next big fad? In other words, why are we not seeing the bang for the buck?

Maybe it’s because we are so caught up in Agile as a idea that we don’t focus our investments on the relevant parts of Agile that matter most. Agile ain’t cheap. So why invest in those parts that don’t matter? The trick is to identify which do.

Agile ain’t cheap. So why invest in those parts that don’t matter?

Agile practices and how they are employed can support many outcomes. That said, some practices are better at supporting specific outcomes than others. For example, a shared team space tends to support the outcome of "we're all on the same team" better than the agile practice of automated testing. It's not that automated testing is a bad thing, it's just that it is not as effective in driving a one-team mindset. On the other hand, automated testing might be generally more effective at driving quality than a shared team space. (Shared team space can go a long way towards improving quality, but it's not as targeted as automated testing.) What I am driving at is that some Agile practices might matter more than others when you consider the context of the outcomes you wish to achieve.

Perhaps even more confusing is that the outcome that matters most to the organization might not be the outcome that matters most to a specific team. For example, the organization might choose improving quality as a goal, but an individual team might choose faster delivery due to a specific market opportunity. You see, context matters. Only when there is an inappropriate misalignment of goals or execution between organization and the team is there dysfunction.

So how do you consider context? Well, first step is to establish a meaningful organizational strategic improvement goal. A meaningful goal should address the greatest opportunity or risk that the organization faces.

agile-fluency-model-v2-simple-portrait-page.png

How do you check goal alignment between the organization and the team? Basically, ask the teams what matters most to them. A tool such as the Agile Fluency Diagnostic™ can generate good conversations about Agile proficiencies and their benefits and which fit best with the team's needs. (The Agile Fluency Diagnostic is a facilitated self-diagnostic that generates insights regarding default team behaviors. If you are interested in learning more about the Agile Fluency Model™ and its companion diagnostic tool, Jim is a licensed Agile Fluency Diagnostic facilitator and would be happy to answer your questions.)

How do your re-align if there is inappropriate misalignment? First, make sure that the misalignment is a problem. Organizational goals and team goals might be justifiably different. Also, the initial goal may be an invalid hypothesis. The key is to establish clear goals, execute, and then assess the impact. Check to see if you achieved the outcome that you wished. Were there unexpected and undesirable outcomes? Inspecting the outcome and adjusting course by revising the hypothesis is a basic tenet of Agile.

By focusing on the Agile practices that fit best with the outcomes that matter most we get better results. Better targeted investments generate better returns. Given that time, money, and capacity are limited, it's wise to be a good Agile investor.

The Elusive Product Owner

elusivePO.jpg

Every Scrum Team needs a Product Owner. You know you need one — a good one preferably. Where are you going to get one? Why are they so hard to find?

To start, recognize that the bar for a Product Owner is pretty high. The Scrum Guide™ says "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team... the sole person responsible for managing the Product Backlog."† These simple words convey a lot of responsibility. Let's consider the implications and how these implications might help you identify your best candidate for the role.

"Responsible for maximizing the value of the product"

Hmmm... when does the responsibility for maximizing the value of the product begin and end? The Scrum Guide™ does not explicitly tell us, but there are some pretty clear hints. For example, the statement that "The Product Owner is the sole person responsible for managing the Product Backlog."† combined with a later statement that "As long as a product exists, its Product Backlog also exists."†† imply that the Product Owner's tenure of responsibility for maximizing the value of the product coincides with the existence of the product.

How long is that for your product? Some products have lifespans that span decades, or longer. The Product Owner is not maximizing value for a segment of the product's lifecycle, but rather for its entire life. Is your Product Owner going to be around that long? If not, perhaps we're looking for a Level 5 leader to fill the Product Owner role — someone who builds enduring success even when they are no longer present.

In a different dimension, where does the responsibility for maximizing the value of the product begin and end? To explore this dimension, let's look at the second part of The Scrum Guide™'s statement.

"Maximizing the work of the Development Team"

In addition to maximizing the value of the product over its life, the Product Owner is responsible for "maximizing the value of the work of the Development Team." Yes, a Product Owner supports the Development Team, helping them be the best that they can be, but this responsibility extends beyond the Development Team.

Keep in mind that the Development Team does not exist in a vacuum. The Development Team is a single element on a potentially complex value stream. The work of the Development Team creates no value if the output of that work is blocked by other elements on the value stream.

So, if the Product Owner is responsible for maximizing the work of the Development Team, by extension, the Product Owner is responsible for the whole value stream. This holistic perspective implies that we're looking for someone who sees the big picture as well as the discrete elements that constitute the whole.

A VERY big responsibility

Recognizing that the Product Owner is responsible for maximizing the value of the product and the work of the Development Team leads us to the inescapable conclusion that the Product Owner is responsible for maximizing the product value in both time and space. The time extends over the life of the product. The space extends across the value stream. Little wonder the role is so difficult to fill and execute well.

Based on these implications, who do you believe is best suited to fill the Product Owner role on your Scrum Team? What can you do to help them be the best they can be?


† Schwaber, Ken and Sutherland, Jeff. "The Scrum Guide™". Scrum Guides. http://www.scrumguides.org. 22 March 2016, p.5

†† ibid. p.13

 

An argument for a look ahead

Photo by Andy Reynolds/DigitalVision / Getty Images

Retrospectives are great, no doubt about it. Retrospectives, along with the experiences that we are retrospecting, are the fuel for our future improvement. But what about when we are just starting out? Is there a place for a retrospective before we begin?

By definition, retrospectives are a look back. When we are just starting out, we don't have a back to look at. We only have our way forward. But which way forward... and how forward? Even with agile and its short iterations, we typically wait to retrospect until the end of a iteration. (I know we don't have to wait until the end, but that is the way it is normally played.)

What if we started with a something like a retrospective at the beginning? Only we couldn't call it a retrospective because it wouldn't be a look back now, would it? What if we started with a "prespective", a before look, a sort of "look before you leap" or "begin with the end in mind"? What difference might a prespective make?

Before diving into the possibilities, let's define prespective.

Prespective |prē'-spĕk'tĭv|
adj.
1. A look ahead
noun
1. An forward-looking activity in which future possibilities are considered with intent to influence focus or direction

Sounds a bit like a kickoff or a launch doesn't it? However, kickoffs or launches tend to focus on the thing that we're creating rather than the process by which we will create it. Instead of looking at the what, a prespective would look exclusively at the how, and as we do with the what, we also ask the question "why?" In fact, the question "why" is at the root of both what and how, if you think about it.

Now, there might be an objection here that good kickoffs do include the consideration of how and why. But seriously, when was the last time you experienced a truly good kickoff?... and one where there was an intentional pause to consider improvements to current process before the start? This part is key. It must be intentional and a pause, not just lip service or a jumping on the bandwagon of the latest improvement fad.

We are talking about the gap between where you are and where you want to be with your process -- your how. The prespective is a serious consideration of the improvements that you wish to see and why those improvements are important.

Knowing why facilitates buy-in

Now, to what difference a prespective might make... if you know why the improvements are important, it becomes easier to get buy-in from stakeholders. Stakeholder buy-in to the reason for a change is key to successful change. 

Vision creates focus

Knowing the reason for a change also makes it possible to paint a vision of a better future that will result from the change. This vision creates focus for the team.

Defining success helps us to know when we’ve reached the goal

A vision also helps in defining success. The definition of success answers the question, "How will we know when we've got there?"

Metrics facilitate inspection

A definition of success also helps in identification of meaningful metrics to measure progress toward and ultimate realization of the vision.

At its core, a prespective simplifies the problem space. By identifying a strategic improvement target, the prespective narrows the possible solution sets. The constraints on the problem space actually makes it easier for the team to construct experiments for improvement. In other words, guided by the prespective, the team designs experiments intended to move the needle in the right direction.

Hypotheses can be wrong!

Now for a word of caution: always remember that a prespective results in a hypothesis based on a perceived improvement opportunity. The perception of the "right" improvement target is colored by past experience, beliefs, bias, preferences... after all, the hypothesis is created by people, who by their nature, are imperfect. If we were perfect, we would already have an optimal process. So, the hypothesis might be... wrong!

Learning loops enable new hypotheses

Given that we might have picked the wrong target, we now need to make sure our process includes a couple of learning loops  one that assesses the impact of our experiment in process improvement on the intended target... and a second loop to reconsider the validity of the target hypothesis. These looks at the results of our experiments?... yes, you've got it, these looks are what we call... retrospectives. And so we begin. Are you ready?

The Role of the Project Manager in Scrum

The Agile framework called Scrum defines three roles -- Product Owner, ScrumMaster and Development Team. Nowhere in the authoritative definition of Scrum, "The Scrum Guide", authored by Jeff Sutherland and Ken Schwaber, is there mention of a role, title, or person called a project manager. In fact, there is just one mention of the word "project" and that is in reference to a Sprint. The word "manager" doesn't appear even once. What is a project manager to do then in the context of Scrum?

Read More

4 things - Getting Started with Scaling Agile

4 things - Getting Started with Scaling Agile

A couple of weeks ago I was sorting through some books left to me by an uncle in the early '90s when I came across a copy of The U.S. Armed Forces Survival Manual, published in 1980. Leafing through I found all sorts of advice such as how to build a shelter, find direction, trap and prepare food, and how to protect yourself from natural hazards. It was this last topic that caught my attention, particularly the section about poisonous snakes of the world. Who knew there were so many ways to die?...

Read More