We Need A Germ Theory of Agile Transformation

In 1847 a doctor digging his fingers into your wound probably wouldn’t have bothered to wash his hands. You might have died because he lacked a basic understanding of germ theory (that took a few more decades to catch on). It’s horrifying to ponder but that’s about the current level of practice in most Agile transformations today.

3fswam

Even with thousands of books, countless conferences and blogs, and an explosion of certifications the fundamental nature of the problems we are paid to help solve are poorly understood at best and completely opaque to most. In short, many in our profession are like the physicians of old; sincere in their desire to help  but applying leaches where antibiotics are required.

That’s why I almost never describe myself as an ‘Agile coach’ anymore; the eye rolls and looks of disgust are laughably predictable and for good reason; a lot of harm has been done to good people in the name of ‘Agile’ and ‘SAFe’.  In my eighteen years as an ‘Agile coach’ I’ve done my share of harm and it’s all so unnecessary.

But what if there were a germ theory of Agile transformation?  What if we deeply understood the nature and forces at work in organizations to such a degree that the next step we needed to take was almost ridiculously obvious?

Such a theory exists, in parts, but it’s just not yet cohesive, well known, or understood.  It’s buried in (and obscured by) glib admonitions to ‘be servant leaders’ or ‘be agile’ that clarifies not the slightest what actually needs to be done. This journal is my first attempt to shed some light on this as a cohesive model both to help and to attract collaborators to expand on it because, without a germ theory of the problems we’re helping to solve, we will continue to do harm that can be avoided.

A Cohesive Germ Theory of Transformation

Parts of what I’m about to share here have  been bubbling around in my head for close to a decade. I’ve shared some of it at conferences and in user groups but even I was struggling to reason around it and apply it consistently.  Now, however, it’s come together in a way I think I’m ready to share because it’s changed everything about my practice. It informs every step, every decision, every interaction and the impact has been massive; a step function improvement in my ability to help others.

The future is already here – it’s just not evenly distributed.

Parts of this will be familiar to many of you but it’s the practical application of these parts as an interdependent whole that provides the value.  I’ll do my best to expand on these concepts and tie the elements together over my next set of journals.

In the meantime I’d like to get this ‘out there’ for discussion. I’ll share the ‘tip of the iceberg’ of this germ theory of Agile transformation in terms of some simple advice. These are the surface elements more easily understood without going too deep into the underlying principles that inform them.  Consider this then as a teaser; a hint of what is to come.

The first five items serve as principles that form the nucleus of this germ theory of transformation. Again, this is just scratching the surface but I hope it will do for now.

  1. Transformation is a VUCA Problem: “What do you know about VUCA?” is the second question out of my mouth when I meet a client (after, “why am I here?”  VUCA  is a an acronym for Volatile, Uncertain, Complex, Ambiguous.  Middle East problems are VUCA problems. Eradicating Ebola is a VUCA problem.  Avoiding financial collapse is a VUCA problem and most Transformations are fundamentally VUCA problems.  Strangely, VUCA remains a vague and foreign concept to most people yet its the fundamental nature of every non-trivial Agile transformation. This goes beyond just the Cynefin framework or the Stacey diagram glibly trotted out in Agile 101 discussions. Understand VUCA. Make sure your clients understand it too. 
  2. VUCA Problems require an incremental approach:  Only a highly adaptive and incremental approach to change works well with VUCA problems, thus successful Agile transformation requires an iterative, incremental, and adaptive Agile approach to succeed. Kind of obvious isn’t it? All of your choices get a lot easier when you realize they’re made in a VUCA context (i.e. many of them are going to be dead wrong). Your moves get a lot smaller. You’re more humble. You pay attention to the results a lot more. As a simple example, delaying the freezing of decisions prematurely is crucial to a successful transformation. Consider that virtually every decision you make along the way may be open to change. How ironic is it then that most change management frameworks such as Kotter or ADKAR (if they’re used at all) are routinely executed in a linear waterfall manner?  The mind boggles.
  3. Most of the hard challenges are adaptive: The Harvard research psychologist Robert Kegan opened my eyes to the concept of adaptive challenges in his book Immunity to Change. Ken Wilbur’s Integral Theory has helped too. Far more than half of the challenges limiting the success of transformations are adaptive in nature rather than technical. They’re invisible to us. Accessing them can be hard but the concept is more simple than you might imagine.  Most people I’ve shared this with quickly grasp the importance of paying attention to the adaptive side of the equation.  It doesn’t require a lot of theory or explanation. We openly discuss them daily. I find often a brief exercise and simple picture (see below) will do.  After they get the idea, they start to see the challenges and the opportunities everywhere. It enables conversations that are impossible without this understanding. Everyone involved needs to know the difference, why it’s important, and learn to see and cope with the difference. Otherwise, you’re blind to more than half the problems and opportunities.  In my opinion it’s not culture or uninformed leadership that’s the biggest barrier to change; it’s the failure to grasp this fundamental concept. It’s what I pay attention to most in my practice and it changes everything.  Screen Shot 2019-11-09 at 4.24.03 PM
  4. Adaptive Challenges Require Level-2 Relationships: Adaptive challenges are deeply personal in nature and can not be overcome operating in level-1 relationships; level-2 leadership and relationships are required. Everyone effectively leading change must learn to foster and operate at level-2. In transformational change, this is not optional. My first act as a coach is to move to a level-2 relationships as quickly as possible. This is probably the greatest value an effective coach can bring to an organization; the ability to show up operating from level-2.  The impact of just modeling the behavior is like a super power. But it’s not enough for just the coaches to operate at level-2. The more leaders and individual contributors who can operate at level-2, the better the results. It’s that simple.
  5. Job 2 is more important than Job 1: I learned about Job 1 and Job 2 from Robert Kegan in Immunity to change.  When we show up at work we have two jobs: Job 1 is obvious; it’s the content of the conversation; the stuff we think we’re talking about. Also present is Job 2; the thought and energy we put into saving our asses. When I work with clients now half of my focus is what’s happening in service to Job 2 and not just for them but for me too. Learning to see this, helping others notice it, and deciding what to do about it is crucial to successful transformation. If you’re focusing on Job 1 when Job 2 is the problem, you’re just making things worse. I’ll have a lot to say about this in later journals.

The following practices are based on the underlying ‘germ theory’ of Agile transformation and will be expanded on further in later journals.

  1. Transform, don’t Adopt: Agile transformation is to Agile adoption what losing weight is to following a diet. It’s not that you don’t use a diet, you have to start somewhere, but  if your goal is to truly help your client (vs. collecting a fat paycheck) whenever possible help your clients pursue transformation over adoption. Focus on results and be prepared for the complexity of that. Make sure everyone involved knows the difference.
  2. Start with leadership, not teams:  Senior and mid-level leaders, not teams, control and have the most influence over both the technical and adaptive dimensions of changing landscape. Whenever possible, partner with, educate, and coach them to lead from a transformational stance (vs. transactional) to help incrementally create the conditions required for the transformation to succeed. The research behind the book ‘Accelerate’ has made the compelling case that  Transformational Leadership and a climate of learning is the foundation for successful Agile / DevOps transformations. Without it, the best you can hope for is somewhat less painful Agile adoption.
  3. Partner with your client – The old model of medical care was the doctor as expert with tragic results.  When things get serious, the best physicians enter into a partnership with their patients. It’s no different for coaches in an Agile transformations. The book Flawless Consulting by Pet Block opened my eye to this in a big way. If you are able to operate as a partner with shared responsibilities and respect rather than ‘the expert’ or worse, a ‘pair of hands’ the results are invariably better.
  4. Respect culture, help with behavior: The roots of culture run far too deep to change them. Most people have an almost toy-like understanding of what ‘culture’ actually is. Even Edgar Schein, who arguably knows more about corporate culture than anyone else alive, focuses on results and behavior. Understanding models like Spiral Dynamics can help but in the day to day, just meet your client where they are, respect their culture, their wisdom, and help them interact in level-2 relationships to change the behaviors they see fit to change in the ways they see fit.
  5. Stop focusing on ‘Agile’;  create a focus on Results, Outcomes, and Capabilities: “Then don’t call it Scrum!” said no customer ever. An over-focus on frameworks alone is probably responsible for more than half the failed transformations out there. Fewer than half the experts I interview can even begin to clearly articulate the results and outcomes that justify the activities they promote.  Regardless of the frameworks your client chooses to use, help them discover and focus on the results, outcomes and capabilities they most need to reach their goals. I shared the approach I use to do this at the Agile 2016 conference.  It’s a core part of my practice now. The book Accelerate is a great source for some of these. Modern Agile is another. Help them make these visible, and inspect and adapt their progress frequently. In a VUCA world, adaptation and incremental learning are the key to success.
  6. Stop Selling Shoes and focus on happy feet – Would you go to a doctor who shoved the same prescription into the hand of every patient who came to her?   Or would your rather go to a doctor who really listened to your problem, considered your lifestyle and needs, and then took their time to actively work with you to find a solution that worked for YOU?  To cram another analogy into this, there are far too many Prince Charmings out there trying to force fit a shoe that fit Cindella perfectly onto every foot they can get their hands on no matter how much it hurts.  It’s horrifying bordering on unethical. If you want a transformation to succeed, you need to treat every client as unique with their own needs and priorities. Remember that context is king, helping comes first, and avoid at all costs doing harm.

shoe

Successful Treatment Requires An Understanding of the Underlying Problems

There is so much opportunity to help our clients. As professionals, we need to do less harm.

Like a doctor treating a wound, those of us in the business of change need a deeper and more fundamental understanding of the forces at work limiting change. The current level of practice is far too superficial and over focused on the technical challenges (easy) at the expense of the adaptive (hard). We need a way to start talking about, thinking about, and acting on these VUCA forces in an iterative and adaptive way in partnership with our clients. We need to understand it.  So do our clients.

What I’ve listed here isn’t quite that ‘germ theory’ of Agile transformation yet but it’s a start. Some of the bones are there. I’ve listed some of the aspects and learning that have arisen from its application.  I’ll share some of my experiences and learning pursuing this in later journals.

I need to acknowledge too that none of these elements by themselves are original with me and I owe a deep debt to my many mentors, muses, and guides along my journey (I promise to enumerate them and their contributions soon). I do believe I’m on the verge of synthesizing these into a useful whole that anyone in the business of Agile Transformation can put to use in practical ways.   My hope is to simplify and share this learning in a way that almost anyone can understand and can shave years off of the journey for others.

In the meantime,

Help!

I’m actively seeking collaboration with and support from those who I think of as members of the ‘Agile Dark Web’; those individuals who

  • Aren’t afraid of radical ideas and, ideally, are often the source of them
  • want to stop the madness and the harm inflicted in the name of ‘Agile’ or ‘agility’
  • seek to help and never harm; focusing on their clients needs without ignoring their own
  • respect the wisdom and creativity of their clients
  • believe our purpose is to help people do their very best work
  • believe context is king; that there is no ‘one true way’ thus,
  • have no strong allegiance to or passion around any particular framework
  • are unfettered by dogma and are willing to discard even closely held beliefs if a better way is found
  • are far enough along the Dunning Kruger curve to have obtained a state of humble competence and know there’s still so much to learn
  • are willing to contribute to this body of work in service to the larger community who share these same values

If that describes you or someone you know, please reach out to me on the DFW Agile Dark Web

Humbling consulting and trying to figure this stuff out, J.

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.

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?

“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?

oops

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.

J.

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.

What’s In Your Agile Playbook?

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;

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?)
  8. 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.
  9. 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.
  10. 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?)
  11. 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).
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Swarm on tasks – team up to complete higher value stories before the end of the Sprint.  See ‘change the task breakdown’ to enable this.
  20. 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?