Agile n+1

My Agile is better than your Agile.

Nah nah, no it's not.

Yes it is!

Is not!

Is too!

Et cetera...

To the point that eventually someone says, "Well, we're beyond Agile anyway. It's so yesterday."

To which I ask, "What part of Agile are we beyond?" If it's dogma, immutable bias, or canned solutions, I say good riddance for a' that! (with apologies to Robert Burns). They weren't consistent with Agile in any case.

Agile, in the Manifesto for Agile Software Development sense, is and always has been about a mindset. That mindset is expressed through 4 value statements and 12 principles. If you haven't checked them out in a while, go ahead and refresh your memory ( I'll wait...

Good, you're back. As you may have noted, as expressed in the "Manifesto", Agile is not a methodology or a specific set of practices. It's not that simple, and we haven't even begun to get it even slightly right in most implementations. Face it. There's a lot of bad Agile out there.

So let's stop these Agile 2.0, Agile 3.0, Agile n+1.0 escalations and brash, sword-rattling posturing about abandoning Agile for the next bright shiny object and get on with it. There's still a lot of work to do.



Scaling — What's it all about?

Recent discussions around scaling agile remind me of the applicability of the shu ha ri model in martial art to success in agile. The path to mastery is not found in a cookbook or by taking a pill. As in the martial arts, scaling agile requires starting with the simple and progressing through practice to mastery.

Scaling agile requires starting with the simple and progressing through practice to mastery.

Getting started is simple

The first step in scaling agile is easy — well, relatively easy compared to later steps. Before you contemplate scaling, first make sure you can create a single effective agile team. At a minimum, to create a single effective agile team you must start by giving the team what it needs to be successful, then listen for their emerging needs, and fulfill those needs quickly. Given the right ingredients and the right support, accomplishing this first step is almost a given barring major organizational culture issues.

But it gets harder

Step 2 gets a bit more complicated. On the surface it's pretty straightforward. Simply repeat whatever you did to create that first effective agile team. Be prepared though. It might not be so easy the second time around. Here’s why:

To achieve the first effective agile team, most organizations do things like dedicate staffing to the team; establish a team room; allocate tools, equipment, environments, and so forth to that team's exclusive use... in other words, remove all of the impediments that might otherwise get it the team's way of being an effective agile team. Then, if anything was missed and the team discovers a new impediment, swoop in and get the impediment out of the team's way.

Removing impediments for the agile team usually has the side effect of further constraining the rest of the organization.

The problem lies in that removing impediments for the agile team usually has the side effect of further constraining the rest of the organization. For example, pulling staff to work on just one initiative, without reducing the total number of initiatives in progress, increases the workload for the remaining staff. Likewise, reserving a conference room for the exclusive use of an agile team as their "team room" takes formerly shared space out of the pool of available shared space for the rest of the organization.

So, while achieving the first team was relatively easy, getting a the second team to the same level is progressively harder. And…

We’re not done yet

Once you’ve proven that you can create a single agile team and then that you can do it again with a second team, you are still not ready to scale. You must now be able to repeat the process that you used to create your first 2 effective agile teams until you have enough teams to meet the demands of the initiative you wish to tackle.

notre dame façade.jpg

And here is where the wheels might fall off the bus. Unless something is done to balance the needs of the agile teams with the constraints of the environment in which they operate, the teams will cease to be effective agile teams — and you can’t scale effectively without the building blocks of these effective agile teams.

Scaling agile changes the organization

The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams.

The bottom line is that scaling agile requires significant organizational change. The ripple effect of the changes realized by the act of creating a single agile team grows with each additional effective agile team. The cumulative effect of these ripples gives rise to massive waves of change that can overwhelm an unprepared organization. The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams. Increasing that capacity is ultimately what agile is all about.


The Elusive Product Owner


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. 22 March 2016, p.5

†† ibid. p.13


The need for simplicity

Simplicity — 

the harmony of nothing that is not needed, and everything that is.
— Christopher Alexander †

Simplicity is integral to agility. It appears:

Simplicity – the art of maximizing the amount of work not done – is essential.
  • as one of Kent Beck's four values of XP:
What is the simplest thing that could possibly work?
— Kent Beck ††
Scrum is simple. Doing Scrum is hard.
— Jim York

Simply put, Agile's bet on simplicity is that lower cost, faster delivery, and earlier feedback trumps cost of potential rework in the future.

The grounding of simplicity is perhaps best expressed by Albert Einstein:

everything should be as simple as it can be, but not simpler.
— Albert Einstein

When was the last time you looked at your product ecosystem from the perspective of simplicity? Is it time to look at it again?

† Alexander, Christopher. A Pattern Language. New York: Oxford University Press , 1977, p. 390

†† Beck, Kent. Extreme Programming Explained. Reading: Addison-Wesley, 2000, p. 30

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|
1. A look ahead
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?