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

Posted on February 3, 2014 by jpacklick

What’s Agility?

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.

Feedback

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

Asking The Wrong Question: Are We Following All The Elements Of Scrum?

Posted on January 12, 2013 by jpacklick

“Have we implemented all the elements of Scrum?”

I hear variations of this question asked all the time and it concerns me.

It concerns me because it places the focus on the elements and not their objectives.The definition of done for a Scrum adoption can easily become ‘implement all the elements’ rather than deliver the results those elements exist to provide.

Have a certified Scum master? Check!
Have Product owner? Check!
Have a product backlog? Check!
Conducting Sprint planning meetings? Check!
Doing Daily Scrums under 15 minutes? Check!
Holding Retrospectives every Sprint? Check!

So… are we productively and creatively delivering products of the highest possible value?

Hmm… maybe not so much.

Following A Practice != Achieving A Result

It’s not only possible, it’s common for teams to follow every element of Scrum and fail to achieve their objectives.

Dont’ get me wrong; as an Agile coach part of my role is ensuring that teams not only adopt the elements of the Scrum framework but do so successfully. (If it were easy my clients wouldn’t need me). A focus on practices though can actually be an impediment to helping teams improve.

Here’s why…

Novice Thinking

In adopting Scrum, newcomers invariably pass through the first stage of the Dreyfus model of skill acquisition; the ‘novice’.

What characterizes the novice?

rigid adherence to taught rules
NO exercise of discretionary judgment
Having mastered the rules, an exaggerated perception of mastery

The typical novice frequently lacks an appreciation for the stuff they don’t know that they don’t know. A consequence of this is that having implemented a practice, the motivation to gain mastery and improve beyond the novice level can quickly evaporate – particularly in a climate of heavy deadline pressure. I’ve seen this happen with scrum masters plenty of times. Often, they’re baked before they’ve even have a chance for the dough to rise.

Ask A Smarter Question – Get A Better Result

So here’s a more powerful question I’d like to see every leader engaged in a Scrum adoption ask. A question that earnestly asked, thoughtfully considered, and truthfully answered can drive the right behaviors;

“How well are we achieving the DESIRED OUTCOMES for all the elements of the Scrum framework?”

It may seem like a subtle distinction but framed this way, the question sets a context for the goal of continuous improvement that underlies every successful adoption of Scrum. Implied are important questions that often go unasked;

What are all the elements?
What are the desired outcomes of this element?
How can we tell how well we’re achieving them?

We can do a little better though…..

“What actions are we taking to improve the outcomes for all the elements of the Scrum framework (and how can I help you)?”

Asking the question this way promotes not only awareness of the elements of Scrum but establishes an expectation for action to better achieve them.

What’s In Your Agile Playbook?

Posted on July 21, 2012 by jpacklick

What options does a team have to finish all the stuff they’ve committed to when they’re mid-Sprint and realize they’re off track?

Last Tuesday at the DFW Scrum group meeting (How to support changes during a sprint), a dozen curious souls followed me into the Improving Enterprises break room to explore the above question.

I encouraged everyone to think of Sprints as a game with the goal of getting all the ‘balls’ (User Stories) to the other end of the field before the end of the Sprint. With that metaphor in mind, we came up with…….a playbook. A pretty robust set of possible moves a team could make to ‘win the game’.

So…what are the possible moves?

Here are the plays we came up with;

Look at the ‘score board – (Some people call it a burn down chart) If you don’t know whether you’re on the 30 yard line or the 70, it’s pretty hard to figure out whether you should kick a field goal or throw a pass. Rule 1: Pay attention to the game.
Fix the broken scoreboard – Sometimes the burn-down looks horrible but the team is doing just fine getting all the balls to the other end of the field. The scoreboard lies. There’s no point in scrambling to address a problem that doesn’t exist. Decide how to fix it. You can’t be a winning team if you don’t know where you are.
Do Nothing – a popular play many teams have developed considerable proficiency in executing, often to the exclusion of pretty much any other play. Unfortunately, it’s a strategy most often destined to lose the Sprint game.
Seek Advice – admit that you don’t know which play you should use, ask for a time out, and turn to your team, a trusted coach, manager, or a magic eight ball to help recommend a play.
Ask for help – this is a move executed by a team member who realizes that they’re having trouble with a task and their ‘ball’ probably isn’t going to make it to the other end without help of some kind.
Offer to help – related to ‘Ask for help’, sometimes a team member is struggling to move their ball but’s reluctant to ask for help. Put down your ball for a bit and offer to help a team member in need.
Move to a team room – assuming that the team doesn’t already work in a team room, finding an available meeting room to work in together for a day or so magically causes the balls to move across the field faster – often enough to win the game. No really.. it’s kind of like magic. As a side benefit, the team moves from selecting plays once a day to ‘as needed’ causing a lot more balls to make it to the end of the field. (warning!!!; the almost instantaneous improvement in team performance can be pretty hard to miss: Somebody might even get the crazy idea that working in a team room is something the team should do more often… like, maybe even daily?)
Play overtime – increase team capacity temporarily by adding the number of hours the players play per day. Note: all plays have risk / reward factors to consider. Unfortunately, this is another play that tends to be used in lieu of more effective plays.
Bring in additional players – find somebody not slated to play that sprint who can jump in and help get all the balls to the other end.
Create some reserve capacity – this really isn’t an available play but more of a “wish we’d done that” strategy to consider when planning future sprints (i.e. let’s hold back a little capacity for stuff we didn’t expect… umm, because maybe stuff usually happens?)
Re-prioritize Stories – decide to work the remaining backlog in a different order to win the most points for the sprint (not all balls are created equal).
Take a ball out of the game – acknowledge that the team just isn’t going to get a ball to the end of the field (ideally one a player hasn’t moved yet) and work with the product owner to select which.
Reduce the number of balls In play – this is one of those plays that seems to rarely occur to many teams (probably because they’re so enamored of the ‘doing nothing’ and ‘play overtime’ plays) but limiting the number of balls the players are kicking around the field at the same time can significantly improve the score. Single pice flow really works; check it out.
Reduce Tasks In Progress – This is kind of like ‘reduce the number of balls in play’ above but focused on tasks. A team member (or team members) are bouncing around working different tasks kind of like the clown balancing on top of a stack of teetering chairs – trying to keep a half dozen plates spinning on sticks. It’s impressive, you can’t argue that the player isn’t terrifically busy but the balls are crawling across the field.
Turn big balls down into smaller balls – Some stories are still too big so a way to score more points is to decompose them mid-iteration and score more points. Shouldn’t you do this before you start the Sprint? Sure, but some things are better late than never.
Take on Technical Debt (i.e. the ‘kludge’ play) – Reduce your standards (definition of ‘done’) for the Sprint – take a hit later, and go for the goal. A dangerous play with some long-term consequences but it’s logically an option.
Switch Players – Shuffle tasks or Stories between members of the team in a way that enables the team to win the game. Maybe somebody is weak in an area and the team decides to strengthen that player’s skill in a later sprint rather than take the hit now.
Change the task breakdown – develop another way to approach moving the ball down the field (i.e. changing the design, etc.) – possibly a different task breakdown (design approach) will allow more swarming or better distribute the problem complexity.
Swarm on tasks – team up to complete higher value stories before the end of the Sprint. See ‘change the task breakdown’ to enable this.
Pair on task(s) – rather than working solo. A cousin to ‘ask for help’, this is counter intuitive to a lot of teams but sometimes pairing not only improves a team’s score the quality of the solution is greatly improved.

We ran out of time to explore this further but the power in the discussion – the act of creating the playbook was much more than just coming up with the plays because;

It prompted members to think about ‘daily planning’ in a new way; as a strategic opportunity to win the game rather than just a boring routine where team members discuss status.
By discussing the possible plays and exploring options we increased awareness that more options existed than many had considered. We only spent about 30 minutes on this list. Who knows what the number of possible plays are? Why not spend a little more time and find out?
By collaborating together to create the playbook – it becomes a product of the ‘team’ (vs. ideas and a problem for just one member of the team to solve). The list we created above isn’t a bad one – you can keep it handy if you’re facilitating a discussion like this to prompt ideas – but encourage the team to create their own. On a real team, this has the potential to increase the sense of ownership and engage them to…. (gasp) self organize to win.

Creating the playbook together also creates the possibility for the team to consider more deeply these plays and evaluate which ones to use and when; not just in the moment but far in advance before the inevitable challenges to winning the game emerge.

Conclusion

Winning teams don’t just get out there on the field and play. They pause to consider their strategies. They work with their coach to develop play books and they learn the plays. They’re constantly on the lookout for new strategies. They retrospect about specific plays that worked and which didn’t and they decide to decide better.

There are lots of ceremonies in the agile cannon for which teams have no playbook. They repeat the same plays over and over without really learning new ways to plan or win the game.

So consider…

What’s in your playbook?

What Is Agility?

Posted on July 16, 2012 by jpacklick

What’s Agile?

Ask the purveyors and practitioners of ‘Agile’ what ‘Agile’ is and you’ll get a scatter plot of responses with heavy clustering around ‘responding to change’, ‘individuals and interactions‘, and even ‘Scrum‘.

They’re wrong

Well… not exactly wrong but they’re missing the point and by missing the point they’re limiting what their organizations can achieve.

Now ask a different question.

What is Agility?

Ask what’s agility and you’ll end up with another scatter plot with clusters that begin to target the right things, again with ‘responding to change’ leading the pack.

Here’s my point; if leaders and individuals tasked with increasing agility within their organization don’t clearly and unambiguously understand what agility is, if they’re asking the wrong questions – how on earth can they ever hope to achieve it? It’s like being handed the wrong specifications and expected to produce a great product.

It’s not going to happen

‘Responding to change’ isn’t a terrible definition of agility in business but it’s woefully incomplete. If your organization has been contemplating moving into a new market in Brazil and you open your favorite morning blog to find that your leading competitor has just made a splash there with a picture of the CEO shaking the hand of Dilma Rousseff you can ‘respond to change’ all you want; you’re already screwed. The contracts are signed.

If you’re a fighter pilot and your focus is on ‘responding to change‘ rather than hosing the other guy first, you’re going to get hosed.

‘Responding to change’ is not the primary goal – it’s an outcome of a more fundamental focus.

Agility starts with asking the right question

Agility is an organization’s ability to make and execute decisions quickly. If success in business is predicated upon our ability to increase agility, than it’s utterly critical that we stop and understand what agility is.

To illustrate:

If it takes your CEO a month to make a hiring decision that’s already been vetted by the team needing that talent – you’re probably not agile
If key strategic decisions are being made by consensus by default – you’re probably not agile.
If a four hour decision takes four weeks to make because everybody is too busy to get together long enough to make it – make all the excuses you want; you’re probably not agile.
If there’s a key decision to be made and nobody knows who’s responsible for making it – you’re definitely not agile.

Agility in organizations is possible, but it must start with asking the right questions.

“How do we change how we operate so that we can make decisions better and faster than our competition?”

Who has a director, CIO, or CEO asking something like the above question every chance she gets?

You already know; practically nobody.

Why? Because they don’t understand what agility really is. Agility, as I’ve defined it, is off the radar. It doesn’t exist as a separate and direct concern.

Most of my focus in this blog will be on how we can change this. How we can create the conditions for sustainable agility in organizations.

It starts with awareness. An awareness around the goal of effective decision making. I’ll be exploring the techniques to increase decision agility and how you can personally bring those changes about within your organization.