The Lens Of Agility: How to improve the outcome of almost any decision

What’s Agility?

magnifying glass on white

Ask folks what words come to mind when you say ‘agility’ and you’re likely to hear words like ‘adaptable’, ‘flexible’, ‘fast’, and ‘responsive’; all valuable qualities for anyone seeking to thrive in highly complex, competitive, and evolving conditions.

But what gives rise to these qualities?  What underlying quality of agile organizations makes it possible to be fast, flexible, adaptable, and responsive?

It turns out that the answer is so simple and basic that almost everyone misses it completely; put simply, agile organizations…

  • make decisions quickly,
  • make decisions at the right time,
  • make decisions that achieve the desired results and,
  • act on their decisions.

The most crucial quality of an agile organization is how well it’s members make decisions that produce the results needed.

The problem with this ‘truth’ is that, by itself, it doesn’t provide much guidance.  It’s hard not respond with, “Make good decisions?! Well… duh!  Of course we all try to make good decisions!”

That’s why I came up with a ‘tool’ to view the underlying dynamics of how decisions are made in a way that reveals opportunities to change them.  I call it the ‘Lens of Agility‘.

What If Decision ‘agility’ Were A User Story?

The ‘lens’ began with a simple question: What if the ability to make decisions effective were stated as a User Story?  What would it look like?  What would the acceptance criteria be?   It’s something I’ve been noodling over for awhile.  Here’s what I’ve come up with so far:

As someone responsible for achieving a set of goals, I need to decide the actions required to achieve those goals based on current reality with sufficient frequency and lead-time so that the desired results are achieved within the time frame required.

Here’s a few acceptance criteria: verify that….

  • A set of goals exists that are clearly understood
  • someone is responsible for achieving the goals
  • decisions are made at the best time to achieve those goals
  • those decisions are based on current reality (rather than what is imagined to be true)
  • action is taken based on those decisions
  • those actions produce the desired results

Read that user story over a few times and let it sink in. Then we’ll explore what we can do with it.

How Can We Use The ‘agility’ User Story To Help Us?

The whole point of a user story is to express a need without specifying a solution; relying on the natural creativity of the team to come up with a solution when it’s time.  This story happens to be a ‘meta’ story that can be applied to any decision to improve it.   Let’s see how we can put it to use.

Think about some important decisions that need to be made in your organization or by one of your teams; particularly decisions that you think aren’t being made so well right now (or not at all!).

Ask yourself:

  • Do we really understand what the goals are?  Do we know what success means?
  • Do we know who’s responsible for achieving those goals?  Do they?
  • Are they the right person to make that decision?
  • Are they taking responsibility for getting the decisions made?
  • Are we able to make the decision when they need to be made?
  • Are we making the decision frequently enough (if conditions change rapidly)?
  • Is it taking longer than we’d like to get the decisions made?
  • Are we basing our decisions on what’s really true – or what we believe to be true?
  • Are we following through on our decisions promptly with action?
  • Are we achieving the goals we set out to achieve? Are we bothering to check?

Here’s an Example:

I was working with a team not long ago that was clearly experiencing far more delays than they expected (most outside of their control). A simple glance at the project stats made it obvious that they didn’t have a prayer of finishing all of the scope they’d committed to for the release. There was a clear decision that needed to be made only, nobody was making it.

“What changes to our plan do we need to make and communicate so that we achieve our goals for the release?”

This is one of those basic questions that are often asked far too late in a release or not at all – long after valuable options to meet the goals have been forever lost. I could tell by their body language that the question made them uncomfortable.  Applying the user story above it became obvious that

  • Goals?: there was no clear alignment within the team on what a ‘successful release’ even meant. Without a goal, there really wasn’t any decisions to be made and no reason to make it.
  • Responsibility?:  Nobody on the team wanted to be responsible for answering the question. Nobody ‘owned’ the decision (or rather, wanted to own it).
  • Decisions Made at the best time?:  Evidence that they weren’t going to make the goals for the release had begun to emerge weeks before. The team wound up making no decision at all during the meeting. Their available options to hit their target was fading daily.
  • Reality based?:  the team didn’t ‘like’ the statistics.  Some believed they could somehow increase their velocity when nothing empirically indicated that was possible. Most actually believed they would still somehow make their goal.
  • Achieved their goal?:  Nope – they didn’t.

The fact is, the team had the skill, creativity, and capacity to have achieved much more than they did however, they failed to make this one often overlooked decision well.

The Lens Of Agility

I call the ‘User Story’ above and the questions that go with it the ‘Lens’ of agility‘; a mental model that makes it easy to see where the greatest opportunities exist to improve the outcome of almost any decision.  When practices fail, it’s almost aways because key  decisions aren’t being made well or at all.  In later blogs I’ll share how you can explicitly identify these decisions and help teams to develop their own strategies to improve them.

The Lens of Agility can be applied to any level of the organization, any role, any activity, and virtually any decision.  Asking a few simple questions like the ones above and following them up with powerful questions can lead to opportunities to improve that a team might otherwise miss.


This is just the tip of the iceberg.  I’m constantly coming up with better questions and patterns that using the lens reveals.  It’s becoming vastly easier to help teams find and create the biggest opportunities for breakthroughs.

This is a work in progress.  I’d love to hear from you.  What would you change about the lens to make it more useful?  What acceptance criteria would you use? What other questions might help a team improve the outcome of their decisions?

J. Packlick

Visualizing Agility – Agile2012 @Open_Jam Brainstorm

About 10 of us gathered on 8/16/2012 for an open jam at the Agile 2012 conference to brainstorm various ways one might attempt to ‘visualize agility’.  Various metrics were discussed (including a number that we all agreed had absolutely no value) and posted on a grid with ‘potential value’ on the ‘Y’ axis and ‘potential for evil / abuse’ on the X.

It was interesting to observe that a slope emerged; in general, metrics with the greatest potential for abuse (evil) were also those judged to provide the least value.  There were a few outliers.  One in particular, “Using the the Dreyfus Skill Model” to identify the skill level of team members had great potential value but also had great potential for misuse.

Thanks to everyone who came by to participate.  The discussion was lively and entertaining.

The results of the exercise appear below.   Thanks to everyone who joined in on the conversation.

J. Packlick

Various metrics for measuring ‘Agility’ plotted by ‘potential for value’ vs. ‘potential for evil’.

What’s In Your Agile Playbook – Agile 2012 OpenJam

Following are the results of an open Jam session I lead at the Agile 2012 Conference on 8/16/2012.

What’s In your Agile Playbook? Strategies to win the ‘Iteration Game

Participants freely brainstormed some potential ‘plays’ a team might possibly use to get all of the stories planned for an iteration to done where the prospects of completing them appeared dim. We employed the metaphor of iterations as a game – won by moving all of the balls (stories) to end of the field (‘done’) by the end of the iteration.

The point of the exercise is to 1) encourage team members to think more strategically 2) consider options beyond the obvious when things don’t go according to plan, 3) ponder the pros and cons of each and 4) prompt the team to take action rather than defaulting to the ‘do nothing’ play.

  1. Do Nothing
  2. Work Late
  3. Break the story down (and move part to the backlog)
  4. Move a story not yet in play back to product backlog
  5. Move a story in-play back to the product backlog
  6. Find a better (faster) way to implement the solution (that doesn’t compromise quality)
  7. Do the ‘kludge’ – incur technical debt to get the story to ‘done’
  8. Pair up on tasks
  9. Swap the players (change who’s working on tasks)
  10. Divide and conquer; break the work up differently to allow for swarming
  11. Move everyone together into a team room
  12. Add a player (bring somebody in to help)
  13. Remove a player from the game
  14. ‘Outsource’ the task / story (tap another team to help finish the work)
  15. Reduce number of tasks in work
  16. Reduce number of stories in work
  17. Combine stories (gain some efficiencies by grouping stories)
  18. Combine tasks
  19. Decompose the story
  20. Change the definition of done (negotiate criteria, shift to another story, etc.)

GAO Findings Reveal; Thar’s Agile Gold In Them Thar Hills!

Where some people see obstacles I see opportunity.

Fellow improver Joe Valone shared a link to the GAO’s recent findings on Agile software development; Effective Practices and Federal Challenges in Applying Agile Methods. They found 32 practices effective in applying Agile to IT projects.

What interested me most weren’t the 33 practices they found effective (kind of old news for most of us), it was the 14 challenges enumerated. Included are:

  • problems with procurement practices
  • difficulty in staff committing to more frequent input
  • agencies inability to commit staff
  • problems with compliance reviews
  • Federal reporting practices
  • lack of clarity in Agile guidance
  • Mistmatch with traditional status tracking

All of this points up the fact that reducing the impedance mismatch and drag factors that limit the agility of organizations and teams remains both a hurdle and a huge opportunity for those in the agile consulting space.

To put it another way, “Thar’s gold in them thar hills!!”

Granted, gold difficult to mine but gold nonetheless.  How much gold?  Consider this quote from the report:

“Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes.”

Focusing on Agile practices can certainly produce gains but Agile adoptions that focus on team level practices alone will remain forever limited in their impact and success.

Changing management level practices and culture must be part of the focus when adopting Agile.  Certainly that change presents more difficulties than implementing a bunch of Scrum practices, but the change also offers some of the biggest opportunities for sustainable gains.

In focusing on team practices alone, we’re picking up the gold pieces lying around but the biggest veins – the ones that produce fortunes remain beneath the surface.