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 (http://agilemanifesto.org). 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.

Agile:

    think,
    
    understand,
    
    act;
    
    quickly;
    
    repeat.

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?

5 Hints to Being a Better ScrumMaster

Great ScrumMasters, like their teams, never stop getting better. How do they do it? Here are 5 things great ScrumMasters do:

  1. Listen - Great ScrumMasters listen and watch what is going on. Through observation, they are better informed to help their team. They "go to the gemba" to learn what their team needs.
  2. Container Hierarchy
  3. Focus - Great ScrumMasters use focus to create containers for action. The hierarchy of containers starts with vision, followed by strategy, and finally execution. Each level of container further constrains action. Containers serve to focus action on what matters most. It is within these containers that creativity thrives.
  4. Intersection of Vision and Acceptance
  5. Practice Pragmatism - Great ScrumMasters understand the intersection between vision and acceptance.  Through patience and persistence, they grow the intersection.
  6. Look Beyond the Team - Great ScrumMasters strive to optimize globally rather than locally. The team is only part of the value stream. Improving the team doesn't matter if the customer doesn't see a difference.
  7. Grow - Great ScrumMasters never stop growing and learning. They read, network and continuously build their skills.

Where do you want to get to?

331px-Alice_par_John_Tenniel_23
‘Would you tell me, please, which way I ought to go from here?’

’That depends a good deal on where you want to get to,’ said the Cat.

’I don’t much care where—‘ said Alice.

’Then it doesn’t matter which way you go,’ said the Cat.
— - Alice’s Adventures in Wonderland, Lewis Carroll

Where you want to get to matters, unless, like Alice, you are on an adventure and you are just trying to get back to where you started. In my work with organizations, the general intent is to get to somewhere different, somewhere better. As an Agile coach with 20+ years helping others develop proficiency in Agile, I've found effective "where you want to get to" strategies  tend to fall into one of 4 contexts -- team, skills, customer, or flow.

4 Dimensions of Agile Proficiency

These contexts establish frames for selecting specific agile practices and choosing goals for measuring progress towards proficiency in those practices. For example, the "skills" frame might lead to the use of practices such as coding standards, paired programming, and continuous integration. A reduction in production defects would indicate an increase in skills proficiency.

Of course, Agile practices are not restricted to just one frame. Paired programming would be an equally valid practice in the "team" frame. The frames might be viewed in a venn diagram with some practices such as retrospectives living in all 4 frames. Likewise, a measure of progress, like team satisfaction, could span more than one frame.

Agile Proficiencies Overlap

Agile Proficiencies Overlap

The main benefit of frames is focus.  You don't need to, nor should you try to, do all Agile practices at once, right out of the gate.  Just like incremental product development, you should adopt agile practices incrementally, respecting your organization's capacity to absorb change in process and practice, and keeping an eye on your goal -- where you want to get to.