A Blog About Agile from Davisbase Consulting

Becoming Agile is the Davisbase Consulting blog about all things Agile. It features regular posts by our staff, whose diverse expertise and backgrounds enable us to offer fresh perspectives and insightful observations.

Check out some of our favorite entries by visiting the top posts page, and be sure to subscribe by RSS feed or email to keep up-to-date.


Print pagePDF page

The What vs. The How

The What vs. The HowI drew this picture last summer when co-coaching with Dan Moody for a client down in South Carolina. It was one of those cool moments where I magically drew something on the white board and everyone loved it.

Since then, I’ve used this image with other clients, captured it (in this form via Paper by FiftyThree) to use in conference presentations, and shown it to my Davisbase colleagues at our all-team meeting last week in Utah during an open space session on Info-graphics (thanks Bonnie!). Now, I’m sharing it  here for you to use as well. Hope you enjoy!

The What vs. The How

User Stories are not a once-and-done sort of thing. They are a placeholder for conversation.  They should be written on a card in order to keep them brief, and they are ABSOLUTELY negotiable.

The challenge is that team’s often jump straight to the solution (the how) before having a clear understanding of the what. There is progressive elaboration that must occur for each user story, and it’s nearly impossible for a team to derive the best solution unless the “what” for the story is clearly articulated up-front.

The lifecycle of a user story has 6 main stages. (Visual on the lifecycle of a user story to come in some future post. Perhaps co-authored with Jeffrey Davidson.)

1. Rough Cut 2. Clear What 3. Planned
Something on a card, with high-level acceptance criteria. Enough for the team to make a guess at its relative size. Refined story content with more detailed acceptance criteria and a more confident sizing. Its also now prioritized. The story has been targeted for a specific iteration within the release horizon (see Sizing to the Horizon).
4. Ready 5. Committed 6. Accepted
The team has refined the content, talked enough about the “how” to feel it matches a Definition of Ready. The team has committed to the story during a Sprint Planning session. The team has demo’d the story to the Product Owner and it has been accepted.

As you move through the stages, the “what” conversation becomes more of a “how” conversation. I also don’t expect a team to know 100% about the story before they commit to it. You learn more as you go. Its a good thing, and requires collaboration among ALL team members. I suggest you try it!

The What vs. The How

PS – You probably don’t even know 100% about the story at the end of the sprint. You don’t really know if it satisfies customers until it is in production! ;-)

PPS – It’s nearly impossible for me to write about, or talk about, user story refinement and the idea of “rough cut” versus “good what” without fondly remembering one of our fearless and inspirational leaders, Bill Gaiennie. He will forever be missed.


Print pagePDF page

Definition of Ready – Revisited.

 

Since authoring my first post on Definition of Ready (Getting a Story “Ready”) back in December 2012 (wow… that long), I’ve slightly refined my 4 questions, and have added a few other guidelines for avoiding a failure to launch within the sprint.

In this post, I’ll give you the most important highlights and guidelines you’ll need to be successful!

Definition of Ready User Story

The 4 Must-Haves in a Definition of Ready

  1. All team members have a shared understanding.
  2. The story is sized accurately & appropriately.
  3. The team knows “enough” to plan the tasks.
  4. All incoming dependencies have been fulfilled.

Struggling with “Sized Appropriately?” Check out Sizing to the Horizon.

Three Questions to Determine Shared Understanding

Individuals OTHER THAN the Product Owner, Tech Lead, QA Lead or other “lead” type team members are able to describe (using their own words)…

  1. The technology approach for building that increment of the solution.
  2. The testing approach and key scenarios to ensure it’s fully functioning and hasn’t broken anything else.
  3. How to demo the functionality to prove it has met the Acceptance Criteria.

Print pagePDF page

Coaching Office Hours, Installment #2: The Agile Manager

Welcome to our second installment of Coaching Office Hours with Davisbase! Last installment, we spoke with Jeffrey Davidson on the topic of change. If you missed it, be sure to check out his insights on the topic of change here!

Our topic today is about management and leadership, specifically the role of the manager in an Agile transformation. The role of management has often been overlooked in Agile transformations in the past. Fortunately, it is now receiving far greater attention and support as seen in the SAFe framework, conference talks, and myriad articles and papers around the web. The message to management is changing from “give the teams some training and coaching and get out of the way” to “you are needed as a key enabler and an active contributor for the success of the transformation”.

At Davisbase, we’re committed to helping not just the teams become Agile, but their management as well. So today we are speaking with Scott Frost, Agile Coach & Trainer, to help shine some light on how you as a manager can be a key enabler and active contributor to your organization’s Agile transformation.

DBC: One of the most common challenges in an Agile transformation is the changing role of the team manager. First, though, help us understand why the manager role needs to change.

Scott:  In past Agile team implementations, it was all about the teams: good Scrum, skilled Scrum Masters and inspiringly focused Product Owners.  But when we talk about Agile “transformation” today, we are talking first and foremost about leading broader organizational “systemic” change, which can only be done by the managers and supervisors (and their managers and supervisors).

“People are already doing their best; the problems are not the people but are with the system.  Only management can change the system.” ~W. Edwards Deming

 If managers have not had this type of leadership experience, then they should read John Kotter’s book, “Leading Change”.

DBC: Now that we better understand why the manager’s role needs to change, how does the manager role change in an Agile transformation?

Scott:  In three ways.  Decentralize many existing decisions you make today; become a Lean-Agile Thinking-Teaching manager; become a servant leader.

First, a manager needs to recognize that in a Lean-Agile transformation it is not enough to commit your teams to change: you have to openly hand them decisions you used to make and coach them how to make them – never assume they know how.  Do not use ubiquitous, management fluff-words like ‘empowerment’ that will do nothing but make your teams roll their eyes, whether in front of your or behind your back.  Instead, take immediate and tangible actions to let them know you are taking responsibility for the change.

Second, become a Lean-Agile Thinking-Teaching manager. Read several Lean-Agile books and take a class or two, then buy some books for your teams (or subscribe them  to Safari or Scribd).  Acknowledge that, as a manager, you may not be educated enough to help LEAD the change, then take action to correct your knowledge gap because the responsibility to lead cannot be delegated: to develop your people you must develop yourself.

Finally, become a servant leader.  Agile leaders are there to help remove impediments, take a long-term view, and create a culture which anchors everyone in Agile principles.  Agile managers should provide structured problem solving workshops and teach their teams to find and solve their own problems, then they need to get out of the way.

DBC: What are some things to focus on getting right and some pitfalls to look out for as a new Agile manager?

Scott:  Focus on enabling behaviors. Changing a culture is done by modifying the principles and habits of the organization.  At whatever level a manager may reside, there are people to be developed, inspiration and alignment to missions to be fostered, and knowledge workers to be motivated.  It is not enough to have an “IT Strategy” to move an ineffective culture toward better and sustainable habits.  As Peter Drucker once said, “Culture eats strategy for breakfast.”  Culture is systemic.  Remember: only management can change the system.

DBC: How can Agile managers help all team members regardless of their positional rank or power become leaders in the agile transformation?

Scott:  Leadership is a task, not a title or a role.  I like to use the analogy from the Matrix movies:  In the first movie, Keanu Reeves goes to see the Oracle for the first time and marvels at a little girl bending a spoon with her mind.  She tells Keanu that the trick is, “There is no spoon.”  In other words, the constraints he places on his own mind create impediments to accomplishing his objectives inside the Matrix.

It’s similarly true for Agile managers:  you must first let go of your prior cultural and organizational biases that leadership is granted through title or position.  Leadership is a task which is freely picked up by the best person for the task at a given time and handed to another person for other tasks.  Anyone may perform a leadership task just as any manager may serve the teams, irrespective of organizational reporting structures.

DBC: Last question – what didn’t I ask you about Agile management and leadership that I should have?

Scott:  Dean Leffingwell, author of Scaled Agile Framework (SAFe), promotes being a lifelong learner.  Leffingwell says, “Lean-Agile Leaders are lifelong learners who help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking, and Agile development.”

So is that accomplished by a one-time read of a collection of books or a couple of classes? Well, that’s a start, but not enough.  Fundamental shifts are taking place in our industry.  I find it amazing that literature from the 80’s and 90’s are still so under-read yet very relevant today.  Even so, there’s an endless list of new works being published which an agile manager should challenge themselves and their teams to read. How about setting a goal of 2-4 books a month?

What?  Is this guy kidding?  Nope, no joke.

If you have experienced success in Agile teams then you know that one of the fundamental tenets of Lean and Agile is to continuously bring to light the issues and impediments of a team or a team of agile teams.  If the impediments are continuously and evermore increasingly complex, how does a good Agile manager stay ahead? Yep, that’s right: always be reading, learning from others, talking to peers, and challenging your own knowledge.

If you have team issues,read The Five Dysfunctions of a Team by Patrick Lencioni If you do not understand flow-based systems and lean principles, read Don Reinertsen’s Principles of Product Development Flow.f your teams struggle with basic scrum, read Jeff Sutherland or many other Scrum authors. If your teams are discussing Set-based Design or Emergent Architecture, read Dean Leffingwell’s Agile Software Requirements and The Lean Machine by Dantar Oosterwald…..and the list goes on and on.

Final thoughts: trust your people to make good change and trust yourself to stand alongside them and assist.  Take the journey. Seek mastery and purpose. Enjoy the ride.

– – – –

Alright, that’s it for this month! Thanks to Scott for his time and keen insights! You can continue the conversation on Agile management and leadership with Scott on twitter @getfrosty and Davisbase @davisbase. Check back soon for the next installment!

As always, we hope you find this series relevant, informative and helpful on your journey to becoming Agile. We would love to hear from you so you can help us make it even more relevant! Submit your questions or suggested topics on Agile transformations to us via twitter @davisbase with hashtag #askDavisbase, or via email at coaching-questions@davisbase.com.

 

 


Print pagePDF page

Sizing to the Horizon

Sizing to the HorizonIt’s never fun to have to use the go-to consultant response “It Depends.”  Sadly, it’s part of my vocabulary when working with teams and it inevitably is used when teaching teams about “Sized Appropriately” aka “Small Enough” from Bill Wake’s INVEST model.

It’s true though: “it depends.” Every team has a different definition of what “small enough” is. The key to a good, high-quality backlog is having your highest priority items “sized appropriately.” So today, I will give you a few models and guidelines for how to know if things are “small enough” and why its important to “size appropriately.”  (Think I’ve used the phrases enough to drive home the point it’s important?)

Understand the Horizons

There are four horizons your team should understand.

  1. Now – The stories the team has committed to and are part of your Sprint Backlog
  2. Next – The stories at the very top of the product backlog and likely to be pulled into next sprint. (Hopefully they are already laid out on your Release Plan / PI Plan / Sprint Forecast.)
  3. Soon – The stories prioritized to work on within the current Release / PI Cycle / the next 2 – 4 iterations (aka Sprint Forecast).
  4. Later – The stories outside (or beyond) the current Release/PI/Sprint Forecast.

Know the Sizing Guidelines for each Horizon

Stories within each horizon should start and finish in…

Now Next Soon Later
< 50% of a sprint < 50% of a sprint < 1 sprint > 1 sprint is OK

Why do Now & Next have the same guideline? Because it is a best-practice to have the next sprint’s stories already in a “Ready” state in case you need to pull them in early or make trade-offs mid-sprint due to blockers/severe impediments.

What does 50% of a sprint mean?  An example will probably help you understand.

Consider a team with an average velocity of 35 points. (We will assume they are using the standard modified Fibonacci sequence for sizing.)

  •      Size of 20 – This is more than 50% of the team’s velocity, and likely takes the majority of the sprint to complete.
  •      Size of 13 – Nearly 40% of the team’s velocity, and likely takes about half of the sprint to complete.

In this case, we would say the following guidelines would apply:

Now Next Soon Later
< 13pts < 13pts ≤ 20pts > 20pts is OK

Here is another way to think about the guidelines based on passing time. Let’s consider a team with a 2-week sprint cadence. (Note: days = “working days.”)

Now Next Soon Later
3-5 days 3-5 days < 10 days > 10 days is OK

Why Small Enough is Important

Ultimately, it’s related to three things:

  1.     Ensuring Quality
  2.     Mitigating Risk
  3.     Minimizing Bottlenecks

Here is a brief description of each:

Ensuring Quality

“Test Early, Test Often” is a mantra in the Agile community. Small stories enable you to test early in the sprint and create a continuous pattern of inspect and adapt cycles for the product throughout the entire sprint

Why does CvC Matter? Because it measures the accuracy of a team’s commitment and is a primary way of measuring team performance.

Mitigating Risk

If something goes wrong with a large story and it doesn’t get finished, then a considerable percentage of the sprint backlog will not be delivered. This is important because it would result in a low CvC (Complete vs Commit) metric.

Minimizing Bottlenecks

Large stories take nearly the entire sprint to complete; thus, all the quality assurance and testing activities will be piled into the last 2-3 days of the sprint. This bottleneck doesn’t really give much time for defect remediation either (see Ensuring Quality above).

SizingToTheHorizon-image2

Alternate Models to Consider

If the term “horizon” is not resonating for you, then consider these alternatives:

Now & Next Front Burner Good Rut
Soon Back Burner Clear What
Later The Fridge Rough Cut

Print pagePDF page

Help! My Teams Need More Engagement in Backlog Definition

Who: Jeffrey Davidson

What: FREE! Webinar

When: Tomorrow, Thursday, April 9, 2015

Where: WebEx – Register HERE

You’ve seen some symptoms that there may be some inefficiency in your story writing process: your teams don’t fully understand the stories; refinement sessions are taking too long; team members are disengaged from the discussion. What you need is a dose of collaboration and conversation, and perhaps finding a better way to engage your team in the Backlog definition is just what the doctor ordered.

Without a collaborative approach to defining Product Backlog Items, Agile Teams run the risk of creating shared documentation as opposed to shared understanding. Interactive workshops and approaches for defining backlog items will not only ensure engagement from all team members, but will also pay dividends in the long run as the team develops a proper foundation for future conversations and refinements.

If this sounds like something your team needs to get better with, or you know a ScrumMaster/Product Owner in need of a push in the right direction, we invite you to come engage with our own Jeffrey Davidson with an informative, interactive, 1-hour webinar where you’ll be guided through:

  • Pre-conditions for engaging Agile teams for backlog definition
  • Three approaches for conducting Backlog Definition Workshops
  • Characteristics of well-defined backlog items

The webinar is tomorrow, and Jeffrey is ready to help you get your teams more engaged. Sign Up Now!

12:00 pm EST  |  11:00 am CST  |  10:00 am MST  |  9:00 am PST


Print pagePDF page

15 Questions – High Quality Backlog Items

We’ve officially formed a habit. It’s been 82 days since the first ‘15 Questions’ post went live. This month we explore 15 questions that will help you gauge the quality of your backlog items. (Remember, each of these posts is written so that your goal should be to respond “true” or “yes” to each question.)

  1. Are team members engaged in defining backlog items?
  2. Can everyone on the team (that includes Product Owners) understand the backlog items?
  3. Does every item have corresponding Acceptance Criteria enabling you to confirm the desired function is behaving in alignment with the end-users needs?
  4. Is there enough detail available for the team to have a brief discussion clarifying the scope?
  5. Can everyone on the team accurately paraphrase the intent and approach for delivering that increment’s value?
  6. Is each item aligned to achieving the next step towards a grand vision?
  7. Will your backlog benefit real people?
  8. Do backlog items expand to cover critical non-functional characteristics of the product?
  9. Are you able to define an approach for how the product increment will be demonstrated for acceptance?
  10. Does each item represent a discrete piece of functionality that can be demonstrated in any order?
  11. Do items evolve as the team learns more, resulting in a brief statement that is clear and concise?
  12. Is it clear how the desired functionality shows value to end-users/the organization?
  13. Can you estimate the size and complexity of every item?
  14. Are high-priority items small enough to be completed within a single iteration?
  15. Is it clear how you can test each backlog item and prove the Acceptance Criteria are met?

A little commentary on each question…

Are team members engaged in defining backlog items?

Product Backlogs are not intended to be ‘shared documentation.’  If a team relies on shared documentation…at BEST, you will get what is written down. Writing something down does not guarantee you will get what you need. Starting with a collaborative approach for defining backlog items will help build a foundation of shared understanding.

Want to know techniques for collaboratively defining backlog items? Check out the March 2015 #BecomingAgile webinar hosted by Jeffrey Davidson.

Can everyone on the team (including Product Owners) understand the backlog items?

The President, CEO, and Chairman of the Board should be able to walk in, read a backlog item, and understand it. Please use “plain English” and general business terms – NOT geek-speak!

Does every item have corresponding Acceptance Criteria enabling you to confirm the desired function is behaving in alignment with the end-users needs?

Acceptance Criteria provide boundaries for the story as well as clear conditions of satisfaction. Without them, it is impossible to ensure you will build things the “right way.” More importantly, without them you’re unable to define the scope of the story and will not be able to estimate the size and complexity of the work.

Is there enough detail available for the team to have a brief discussion clarifying the scope?

“Enough” detail is somewhat vague and open to interpretation; what is “enough” for one team may not be “enough” for another team. If it takes much more than 2-10 minutes of discussion among the team, then the story’s scope is probably too large, acceptance criteria are too vague, and the PO is not prepared to articulate what the end-users truly need: this means there is not “enough” detail available.

Can everyone on the team accurately paraphrase the intent and approach for delivering that increment’s value?

This is the true mark of shared understanding over shared documentation. It is far too easy to read a story card and then ask team members if they understand. When you settle for everyone nodding, you’re taking the lazy way out. People nod to stuff all day long, but in their head are thinking, “I have no frikin’ idea!” Paraphrasing is your friend.

Is each item aligned to achieving the next step towards a grand vision?

Don’t treat your Product Backlog like a junk drawer of features you might need if you happen to remember they’re in there. If they aren’t important enough to store and care for properly…well…garbage in, garbage out. Writing user stories for your backlog items ensures that WHO needs it and WHY they need it are properly defined, which, combined with practicing all 5 Levels of Agile planning, will keep the team aligned for towards the grand vision.

Don’t treat your Product Backlog like a junk drawer of features

Will your backlog benefit real people?

There is a laundry list of sub-topics that could be addressed here. Essentially, we want you to think about whether or not you’re properly slicing user stories. Avoid generic use of the word “user,” and ensure there is a real, human, end-user who benefits from the functionality you’re building. You should avoid “horizontal” backlog items that benefit other IT processes/systems.

Struggling with what we mean by slicing? The folks at Adobe Systems describe it pretty well.

Do backlog items expand to cover critical non-functional characteristics of the product?

Backlog items are not only about the “functional requirements.”  You need to explore and expand them to cover critical non-functional elements as well. Your NFRs (non-functional requirements) may be manifested in the Definition of Done, Product Constraints, or global Acceptance Criteria. Regardless of how you capture them, you need to make sure you explore them.

Are you able to define an approach for how the product increment will be demonstrated for acceptance?

A shared understanding of how to develop the product increment is step 1, but take the team’s understanding of the story to the next level by asking individuals to paraphrase their understanding of how the story will be demonstrated to the PO and stakeholders. If the key scenarios can be outlined, and flow of the functionality can be described, you’re likely good to go!

Please note, questions 10 – 15 on the list are an interpretation on Bill Wake’s INVEST model for defining well written backlog items.

Does each item represent a discrete piece of functionality that can be demonstrated in any order?

I – INDEPENDENT – This question related to the idea of ‘slicing’ from #7 and advances the conversation to whether or not the stories can be developed and demonstrated independently of one another. Building software products/services is much more like filming a movie than it is building a house. If the most important room in a house is the 2nd floor Master Bath, then it is impossible to build that room first. On the other hand, if the most important function of your online shopping portal is “add to cart” – you could build that first.

Do items evolve as the team learns more, resulting in a brief statement that is clear and concise?

N – NEGOTIABLE – Backlog items are not etched into little 4×6 granite tablets and signed off in blood. They are placeholders for conversation, which expand and evolve as we learn more about them. The hope is to lock down the content during Sprint Planning, but in reality we probably only know 90%-95% of what we’re looking to understand about a story in advance of committing to it. And guess what – thats OK.

Is it clear how the desired functionality shows value to end-users/the organization?

V – VALUABLE – The interpretation of value is subjective. If our highest priority is to satisfy the customer, then it is critical to clearly articulate who the customer is. The value statement is further identified if you’re writing User Stories because the “why” is also included. Backlog items written in the form of “who? – them” and “why? – cause I said so” are simply not sufficient.

Can you estimate the size and complexity of every item?

E – ESTIMABLE – Relative measures of size and complexity enable teams to better manage expectations, track commitments, and project potential future deliveries. If an item has been added to the backlog, then it pretty quickly needs a size, especially if it is within your next release (or PI) horizon.

Are high-priority items small enough to be completed within a single iteration?

S – SIZED APPROPRIATELY/SMALL – The statement “sized appropriately” can be left to interpretation. In fact, it’s often interpreted poorly by teams and organizations. Check back in a few weeks for a special post on “Sizing for the Horizon” to get some guidelines on when and how much to break-down backlog items, but until then consider these two guidelines.

stories should be small enough to finish in 2-5 days.

  1. Any backlog item you believe you will work on within the next 4-5 iterations should already be small enough to start and finish in a single iteration.
  2. Any backlog item in the current iteration, or the next iteration, should be sized small enough to start-and-finish in less than 50% of your total iteration duration. With the most popular sprint length being 2-weeks, that means stories should be small enough to finish in 2-5 days.

Is it clear how you can test each backlog item and prove the Acceptance Criteria are met?

T – TESTABLE – All good ‘requirements’ should be testable. Words like “fast,” “easy,” “user friendly” are very subjective.  Consider statements like… page should load in under 3 seconds during peak load times, customers can find the call to action on the page in under 5 seconds, patients can complete the pre-op registration process in under 7 minutes more than 75% of the time.

Looking for more on backlogs and user stories? Continue visiting the site next month, our theme for content is going to focus on backlog elaboration!


Print pagePDF page

Industry Favorites: Product Backlog Resources

Ahhh, Spring is finally upon us. Temperatures are rising, leaves are popping out, and before we know it the yellow-crush of pollen will be here. In the spirit of “spring cleaning” we’re doing to take this spring to focus on cleaning house when it comes to Product Backlogs.  This month the majority of our content, webinars, newsletters, and resources will focus on Product Backlog Definition & User Story Creation. As we turn the corner for May Showers we’ll take the conversation to the next level and start exploring the real art of backlog management and how to support and elaborate your backlog items.

To kick-off this content mini-series, we thought it would be useful to showcase some of the outstanding resources from across the industry.

  • 7 Product Dimensions from Discover to Deliver
    • This short video introduces the concepts of the 7 product dimensions, and the Discover to Deliver site has a list of resources related to that content. (www.discovertodeliver.com)
  • Uncomfortable Truths About User Stories (YouTube Video)
    • There are so many great things about this video, and it’s worth finding the 80 minutes to watch the whole thing, even if you need to do it in 4 roughly 20 minute chunks. Jeff Patton makes a particularly interesting comparison of developing features to an artist producing a work of art from 59:00 to 1:00:54 that ties in very well to the next link…
  • Splitting User Stories: the hamburger method
    • We find ourselves sharing this link with more and more people because how Gojko Adzic describes and depicts splitting user stories is very clever. Many people struggle with splitting stories because they’re concerned with building every component in the perfect end state, which simply isn’t possible to do in short sprints. Gojko explains how to think of splitting stories to decide how to write stories that iterate to the desired end state. Definitely worth a read…and a bookmark.
  • What Characteristics Make Good Agile Acceptance Criteria?
    • Acceptance Criteria are critical to defining the boundaries and specific needs of a User Story. This blog post is a concise description of what should be included in Acceptance Criteria with some great examples.
  • The Difference Between a Story and a Task
    • Mike Cohn discusses how something that seemed so clear in his head wasn’t so easy to answer, and takes us on the thought process to a simple, clear answer that should help distinguish between what is a Story and what is a Task. (hint: a Task is not just a smaller Story)

Print pagePDF page

Agile at the OK Corral: Gamifying tiebreaker authority

file0001839843565It’s high-noon and the town felt deserted. The wind blew dust across the empty streets while closed shutters hid any signs of life inside the building. No one could be found, except for two lone gunfighters in an empty corral, as they fought to determine who was the fast gun.

Whenever we bring together a team of very smart, experienced, capable and motivated people who are working together to solve problems or innovate, conflict will occur.  Conflict is healthy, and even necessary, to get the best work and ideas out of the best teams…to a point.  But beyond that point it can be crippling.  When two seemingly valid solutions are presented and we must choose one, there needs to be a mechanism for tiebreaking or resolving the impasse.  A standoff between team members as to who is right and whose idea should be adopted can be difficult to resolve at times.  This brings to mind the shootout at OK Corral. Both sides feel they are right and justified, and neither is willing to concede to the other easily.

How do we break the tie, forge through the impasse, and decide what to do?

The challenge in overcoming the impasse is twofold: first, get the work done in the most efficient way possible to maximizing the value to the customer; second, nurture an Agile self-organizing team.

A more innovative and fun approach to consider is to gamify how tiebreaking authority is determined within the team to both enable quick decisions and foster a healthy team environment.

There are a few straightforward and common techniques to consider which address both of these challenges at varying levels of success:

  • Allow the “alpha” personality to dominate
    • Helps teams make expedient decisions, but sometimes at the cost of nurturing the self-organizing team
  • Do a proof-of-concept or prototype
    • Helps foster the self-organizing team’s creativity and build their knowledge, but not a quick way to make a decision
  • Assign tiebreaker authority (e.g. someone with formal authority)
    • Enables quick decisions, but causes a team to feel “managed”

A more innovative and fun approach to consider is to gamify how tiebreaking authority is determined within the team to both enable quick decisions and foster a healthy team environment.

Draw Cards to Choose Tiebreaker Authority

  1. Make two stacks of planning poker cards with a complete series of number and no duplicate numbers in each stack.
  2. Shuffle both stacks of cards, and set one stack in the middle of the table where the team is going to work.
  3. Before each meeting starts, each team member draws a planning poker card from the shuffled deck that was not placed at the center of the table.
  4. If the team reaches an impasse and opposing viewpoints cannot be resolved through collaborative analysis, a card is drawn from a stack of planning poker cards at the center of the table.
  5. The team member with the matching number is the tiebreaker.
  6. Replace the cards drawn from the stack, reshuffle, and replace the deck in the middle of the table for the next impasse.

Draw Dowels to Choose Tiebreaker Authority

NOTE: An item to consider for the team working agreement is to include a commitment that the team abide by these tiebreaker decisions to make them as successful as they can be.

  1. Cut very small dowels cut to about 6″-8″ long and about half the diameter or a standard pencil.
  2. Color/paint the end of each dowel: you need one color for each person on the team, and two dowels in each color.
  3. The ScrumMaster holds up all the dowels in a bundle with the color end showing.
  4. Each team member will choose a color and draw both dowels of that color (there should only be two of each color as per Step 2).
  5. Each team member keeps one dowel and puts the other in a short vase with all the other team members’ remaining dowels, color end down so it doesn’t show.
  6. If impasse is reached and a tiebreaker is needed, a random team member draws a stick from the vase and the team member with the matching stick now has tiebreaker responsibility.

In either of the above games, there is a risk that the person who draws as tiebreaker may simply choose his or her own solution.  This risk is somewhat mitigated in that if we reached impasse it would be because we have arguably equal potential from either solution.  Knowing that the decision could ultimately be made by the luck of the draw is sometimes a motivator for people to resolve it in other ways before impasse is reached and we have an OK Corral like standoff.

Draw Straws to Choose “Devil’s Advocate”

Healthy conflict in the conversation will result in better vetting of our requirements and values.

  1. Prior to each refinement or planning meeting, draw straws to determine who plays the role of “devil’s advocate”.
  2. This team member must take the opposing view of the popular or consensus view to vet out what might be wrong or incomplete with our thinking (health conflict).

Healthy conflict in the conversation will result in better vetting of our requirements and values.  I like this to be a temporary role to prevent one team member from ever being characterized as always being negative or contrary; instead, we each take a turn.  The responsibility to analyze “why not?” and “what could go wrong?” is a necessary viewpoint to determine better solutions.  When a team member has played devil’s advocate they are safe for the next meeting.

All of the techniques I’ve touched on work to a certain extent. The question is, which one is going to foster the culture of collaborative development and shared responsibility?  While the more well-known and straightforward methods of overcoming an impasse within an Agile team work (some better than others), what I like about gamifying tiebreaker authority is that it arrives at a quick decision, but because every team member could potentially be the decision maker, they are forced to remain engaged in the conversation in order to be informed if they are the tiebreaker.  With engagement built into the model, gamification is almost guaranteed to foster a culture of collaborative development better than any other method that enables expedient decisions.


Print pagePDF page

The Best Answer Might Be A Conversation

blogimage_best-answer-might-be-a-conversationEarlier this year, I was coaching a team and they asked, “Which method should we use to complete a story within the current sprint: code review or whole team testing?”

This is an interesting question because of how it is framed. I appreciate all types of questions, but asking “either code reviews, or whole team testing” is loaded with pitfalls and hidden traps.

First, it presumes both code reviews and whole team testing solve the same problem. This logical fallacy1 is known as a “loaded question.” This type of fallacy includes false assumptions often cause people to defend themselves or appear flustered. Imagine instead if the person asked, “When did you stop kicking dogs?” This sly question implies you beat animals and cannot be answered without redirection. In our case, the question presumes these very different activities are interchangeable steps to our goal, completing the story.

Second, it presents two alternative states as if they are the only possibilities available for a solution. This logical fallacy is known as a “false dilemma” and paints life as black or white. Depending on the goal, there are many possible solutions, including paired programming, automated tests, or user acceptance testing.

The correct response to this question isn’t a simple answer.

Instead of picking between the choices they gave me, I responded with a few questions of my own. “What is your goal? What is your team’s ‘definition of done’? What problem are you trying to solve?”

Based upon their answers, we proceeded to talk how the team quality, what the product owner and organization wanted at sprint’s end, how much work is being loaded into the sprint, why testing happened primarily in the last few days, and more.

The answer they needed was more than the question allowed. The answer could only come from a conversation and more understanding.

 

Post Script: They are both good

Post Script #1 – Code reviews2 are a good thing, but they are not the only thing. Teams should spend time ensuring developers are writing clean and understandable code to accepted standards. There are a variety of practices around this including pair programming3, formal code reviews, and lightweight code reviews.

Post Script #2 – Whole team testing4 is a good thing, too. I believe the team succeeds and fails together; everything the team agrees to deliver is a team responsibility, not a set of individual commitments. Therefore, everyone should assist with testing to the extent they have time and skills and availability with the caveat you may not test your own code.

Similarly, everyone should help with writing stories, UX, and coding to the extent there is a need and team members are able, but that is a separate blog post.

References

  1. Logical Fallacies – Learn more about these so no one takes advantage of you. https://yourlogicalfallacyis.com/
  2. Code Review – There are multiple levels of code review. Start learning more here. http://en.wikipedia.org/wiki/Code_review
  3. Pair Programming – The benefits from pair programming are numerous, if often doubted.  http://goodrequirements.com/2013/pair-programming/
  4. Whole Team Testing – This phrase isn’t as popular as the concept is used.  http://testobsessed.com/2011/09/testing-as-a-whole-team-activity/

Print pagePDF page

When Should We Cancel a Sprint?

blogimage_when-should-we-cancel-a-sprintI recently had the opportunity to take a newly-formed team through a cancel/re-plan on their very first sprint; the results show why having the option to cancel a sprint can be a very powerful and effective tool to get a team back on track. The team completed all the stories they committed to in their re-planned sprint, turning what could have been a catastrophe into a success.

When is it “right” to cancel a sprint? There are many factors to consider, but likely one of the most important is the maturity of the team. Mature teams should fully embrace the second Agile principle:

Welcome changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage.

Mature teams, fully versed in inspect-and-adapt principles, are more fluid in how they adapt to the change of adding, removing, or changing stories mid-sprint. They likely go through the steps of a cancel/re-plan with such grace that, to the untrained observer, it looks like they’re just casually changing their plan.

Newly-formed teams, however, don’t often have the agility to turn on a dime like mature teams; the threshold for canceling a sprint is much lower. It should be. Newly-formed teams don’t have the discipline to change priorities quickly and must be stepped through the process mature teams finesse.

So, here I was with this newly-formed team on day 6 of a 10-day sprint. After collaborating with another team working on the same infrastructure, my team decided they were implementing a much less efficient design, which didn’t fall in-line with the architecture the other team was building towards.

After the daily Scrum, the team began discussing how those changes would impact their current work. After witnessing the team discuss the issues for about 90 minutes, which involved adding new stories that didn’t meet their Definition of “Ready” to the sprint, I interjected and forced the team down the path of canceling the sprint.

Within an hour, the team had a new, Product-Owner-approved plan, which included one less story than they were trying to cram into the sprint during their initial self-directed re-planning exercise.

At the end of the sprint, the team completed their re-planned commitment.

 

Post Script:

Ultimately, I hope the team learned a couple valuable lessons:

  1. Whether or not we called that activity “canceling the sprint”, and regardless of whether they would actually cancel a sprint in the future, it’s important to adhere to the fundamental Scrum practices when change occurs.
  2. It’s important it is to have a clear plan and a commitment to each other to get it done.
  3. It’s more efficient to tackle the replanning a story at a time, rather than trying to plan everything at once.
  4. Most importantly, re-planning may force stories they committed to in the original plan to fall out of the new plan, and that’s okay.

Print pagePDF page