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

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).


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.


  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

Coaching Office Hours, Installment #1: Change

Welcome to our first installment of Coaching Office Hours with Davisbase! Each month we will select one Agile transformation topic to briefly explore with a Davisbase Coach. We encourage you to submit your questions and the topics you are interested in via twitter @davisbase with hashtag #askDavisbase or via email at coaching-questions@davisbase.com.

For our first session with the coach, we are speaking with Jeffrey Davidson, Agile Coach and Trainer for Davisbase. Jeffrey is a recognized expert and sought after speaker in agile methodologies. An engaging presenter, he is often found at conferences and professional associations across North America and Europe. Jeffrey’s ability to blend strategic thinking, powerful questions, and technical experience makes him a desired coach when companies want to turn theoretical knowledge into real-world application.

Our topic today is all about change, a fitting topic to begin our series on Agile transformation, and specifically what you should know about managing and supporting change in your organization as you begin pursuing agility.


DBC: Jeffrey, to get us started, would you briefly explain the Satir Change Model?

Jeffrey:  Satyrs? Do you mean the mythological Greek figure? Why do we want to talk about ancient ideas?


Statue eines Satyrs

Okay, just kidding.


The Satir Change Model talks about the very common path people and teams take when trying something new. It is a model 1 describing how people react to changes in 4 steps. The first is the status quo, where things are stable. The second stage begins when a satir-change-modelforeign element is introduced, adding chaos to what was once stable. This change will result in a performance dip while simultaneously stress levels are rising. The third stage is where you begin to integrate and practice with the transformation ideas 2. As you learn what works and become more skillful performance often rises higher than the starting point. The fourth stage is where performance levels off as skills are mastered and a new status quo is set.



DBC: How might one generally understand and apply this model when starting down the path of becoming Agile?

Jeffrey:  Like the Borg, “Resistance is futile.” And by that I mean don’t resist the chaos or the rest of these stages. They exist. It will take time to be good at this new thing.

Transitioning to Agile means learning new skills, including new ways to interact with your team, breakdown work, track progress, hold yourself and others accountable, increased transparency, and more. There is a lot that is different. You should expect that you will have to practice these new skills to become proficient in them. And in many Agile transformations you have to learn and practice all of them at the same time. Whew! 

Don’t focus on perfection. Instead, focus on on delivering value. Focus on learning how to work better with your team and product owner. Focus on improving. If you keep your eyes on the 12th Agile principle, everything will be alright.

 At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behavior accordingly.


DBC: And have you seen any pitfalls in your experience with helping teams and organizations progress through the J-curve? What should people look out for?

 Jeffrey:  Unfortunately, yes. The Satir model is really the best case model. There are plenty of individuals and teams who succumb to the chaos or give up before they reach competence in the new skills. Whether fighting through complacency or denial, disillusionment or hostility, reaching the new status quo takes discipline and effort and a supportive environment. 

First, be honest about the reason for change and don’t over promise the benefits.

Second, don’t presume those who lack enthusiasm are against change or Agile. They may have valid questions or concerns that are waiting to be addressed.

Third, explain why the new processes help. Many teams are derailed because of an “Agile expert” telling everyone how to act and neither modeling the correct behavior, nor helping a team understand why it’s a benefit.

Fourth, try to find support high enough in the organization that the people doing the work can be assured this isn’t the latest management fad of the month.

This recent image from twitter is a great example of what goes on and what to look out for:

Screen Shot 2015-03-03 at 1.50.15 AM


DBC: Teams in large enterprises are often geographically dispersed, or as a ScrumMaster at a DBC client once said, “dislocated” (as opposed to co-located). Does this lack of co-location affect in any way the J-curve process and change adoption? If so, how?

Jeffrey: I think distance, whether you call it co-location or dislocation (great phrase, btw!), has a huge impact on communication. It’s just harder to have a good conversation by email, phone, or often video, too. If teams are located across the globe and don’t work the same hours, it’s atrocious. And when you add in the possibilities of different cultural norms, it’s almost too much to bear. 

I start with this because teams need to work together through the change curve. If they are working at cross-purposes, or simply aren’t working on the same items, they will spend more time in the resistance phase and it take longer to make progress during the integration phrase. 

What’s the secret to progressing through these stages? Include fast-feedback loops, sharing ideas and reactions, setbacks and progress to find the best way forward. Expecting teams to make fast progress when they struggle with communication roadblocks is silly, at best.


DBC: Last question: What didn’t I ask you about change management as it relates to Agile transformations that I should have?

Jeffrey:  Ooo, good question! Let’s start off with a Chinese proverb.

Rather seven dragons I know

than one I don’t. 

Change is hard. Very few people like change for the fun of it. When you are trying to introduce change and others are resisting, it can feel like people are deliberately sabotaging your efforts. Rather than pull out your hair or plan retaliation, stop and think about why folks don’t want to change.

Everyone you meet has achieved some success in their life. They have been hired for their skills and potential, promoted for their contributions, and experienced the joy of solving problems that stumped others. No matter who you talk to or work with, everyone has achieved this level of success. And you want them to change!

And changing, despite all of it’s promised benefits, also brings risks. It is possible your changes will mean it is harder for people to experience the same success they are used to. At the least, they will have to learn new ways to succeed. Maybe it will be easier, but maybe it wont!

When you add all these things together it’s simple to see why people resist change. If you cannot explain how change is either beneficial to the individual, the organization, or both, then you should expect serious resistance. Don’t forget the WIIFM (What’s In It For Me)!

If I had space for a second point I might warn about the Dunning-Kruger effect, but I’ll save that for another post.

Jeffrey’s Notes:

  1. George E. P. Box stated, “Essentially, all models are wrong, but some are useful.” By this I want you to think this model is an approximation for what you or your team may go through. It may not be exact and that’s okay.
  2. Agile is seen as both the foreign element causing chaos and the transformational idea we want people to practice. This is not correct, but it is viewed this way. The way to combat this is to explain how the status quo is not meeting the current organization needs and why the development process is considered to be in a state of chaos already!
  3. If you are looking for another good model, try John Fisher’s Process of Personal Change.


– – – –


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

As always, we hope you find this series relevant, informative and helpful as you begin or continue your journey to becoming Agile. Help us make it even more relevant by contacting us with your questions or suggested topics on Agile transformations via twitter @davisbase with hashtag #askDavisbase, or via email at coaching-questions@davisbase.com.

Print pagePDF page

Four Steps to Assess Agile Effectiveness

Regular retrospectives are fantastic for checking the heartbeat of a team.

However, in order to truly embrace a Kaizen mindset and culture it’s important to have models and techniques that allow for deep exploration and visualization of how teams are doing and what is changing over time.

Within this post I outline a model and approach teams and organizations can use to self-assess a wide array of topics. While there are only 4 steps to the process, I’ve taken the time to explain each with examples, rationale, and options for you to consider. At the end of the post you will find a scenario that illustrates a teams progression through the model. I look forward to your comments and thoughts.

Here is a quick summary before digging into the details of each step.

1. Determine the Topic 2. Gather & Plot Data
determineTopic gatherData
3. Determine Action Plan 4. Track Progress
actiopnPlan trackProgress

You can see there are two axes used; thus, two questions or aspects of any given topic are assessed.

  1. Y-Axis – Usage/Alignment
    The degree to which the participants are working in alignment with the topic you identify. e.g. Are you in alignment with the Agile principle, The most efficient and effective method of conveying information to and within a development team is face-to-face conversation?
  2. X-Axis – Ease
    The degree to which the participants find this easy.  e.g. Do you find it easy and effortless to convey information via face-to-face conversation?

Based on responses, you can then visualize the team’s current performance and track trends over time.


Step 1: Determine the Topic

This model can be used to assess nearly any topic. In order to determine the topics to run through the framework, you likely want to look towards your team or organization’s Improvement Backlog (an artifact that is hopefully coming out of your Retrospectives). If you’re taking the time to do full Agile Maturity Assessments, then you may want to select questions and topics where the team scored lower than expected.

Here are three suggestions for assessment:

  1. Alignment with Agile Principles
    Is your team (or organization) operating in alignment with all 12 Agile principles?  Present the twelve principles and gather data on each.
  2. Adoption of Scrum (or XP) Practices
    Is your team using all required/suggested Scrum and/or XP practices? Present the ceremonies, roles, and artifacts of Scrum/XP and gather data on each.
  3. Continuous Planning Across Five Levels
    Is your team progressively elaborating details across all 5 Levels of Agile Planning? Present each level of planning and gather data on each.

For more ideas on topics to consider, be sure to finish the post. Down in ‘Step 4: Track Progress’, I’ve outlined two scenarios for rotating topics through a monthly inspect & adapt forum. You can also leverage content each of the “15 Questions” posts we have made this year (and will continue to make as the months progress).

Step 2: Gather & Plot Data

There are 2 ways you might want to collect and plot data within the model.

  1. Visual Data Collection
    Provide each team member a copy of the quadrants and ask them to place a dot appropriately. Gather graphs from all participants and compare results. In fact, you can use a poster-chart and place all the dots on the chart and use the differences in order to fuel discussion and reach a consensus.
  2. Survey Collection
    Present the topic to participants and have them rank a topic on a scale from 1 (low) – 5 (high) for each axis on the chart.  You can then average the responses and plot those data points, or plot each participant’s data point and discuss variances.


If you are using a rating scale.  Consider the following anchors for participant responses.

X-Axis: Degree of Ease

Y-Axis: Degree of Usage/Alignment

5 Feels effortless and automatic In complete alignment
4 Feels like a natural part of our process Mostly in alignment
3 Is not difficult, but takes time and patience Neither in or out of alignment
2 Takes effort and practice to get it done Somewhat out of alignment
1 Feels difficult and burdensome Not at all in alignment

Do not feel constrained by this 5-point scale. Define a measurement scale that works best for you. In fact, you may want to consider a seven or 10 point Likert scale that allows you to measure greater degrees of moderate alignment and support.

Step 3: Determine Action Plan

Remember: the value in this exercise is less about where the the data falls within the model, and more about the rich discussion that should ensue after the data is visualized. Use standard Retrospective practices to determine action items that the team can use in a commitment to improve.

In some cases the team will be able to course correct and advance progress on their own, however, in other instances you may need to look for additional help and support. The visual below offers suggestions of approaches that may be considered.


Step 4: Track Progress

Visualizing the progress and changes over time can help teams assess their maturity and evolution. The frequency you use to check progress will vary based on topic and needs of the team/organization. If you choose to use this model, please do not consider it a once-and-done. At a minimum, a quarterly review cycle is sufficient. You may also choose to leverage this model upon conclusion of each PI cycle during the Inspect & Adapt event (if you are using SAFe), or just after a product release to customers.

For some groups, a monthly review cadence with this model is useful.  Leverage the model each month during an explicit inspect & adapt event, and define a cadence for the topics you want to review. Check out the example below.

Scenario A

This scenario covers 10 assessment topics. Some are measured monthly or bi-monthly. Others are quarterly or annually.

Scenario B

This scenario divides 9 assessment topics and rotates them quarterly.

Month 1
  • Authenticity of Commitment
  • Simplicity, Maximize Work NOT Done
  • Test Early/Test Often
  • Authenticity of Commitments
  • Proactive Customer/Stakeholder Feedback
  • Test Early/Test Often
Month 2
  • Authenticity of Commitment
  • Satisfy the Customer
  • Deliver Frequently
  • Delivery Frequently
  • Satisfy the Customer
  • Follow-Through on Improvements
Month 3
  • Authenticity of Commitment
  • Follow-Through on Improvements
  • Simplicity, Maximize Work NOT Done
  • Simplicity, Maximize Work NOT Done
  • Swarming & WIP Limits
  • Prompt Impediment Resolution
Month 4
  • Authenticity of Commitment
  • Test Early/Test Often
  • Improve Team Morale
  • Authenticity of Commitments
  • Proactive Customer/Stakeholder Feedback
  • Test Early/Test Often
Month 5
  • Authenticity of Commitment
  • Simplicity, Maximize Work NOT Done
  • Satisfy the Customer
  • Delivery Frequently
  • Satisfy the Customer
  • Follow-Through on Improvements
Month 6
  • Authenticity of Commitment
  • Follow-Through on Improvements
  • Improve Quality
  • Simplicity, Maximize Work NOT Done
  • Swarming & WIP Limits
  • Prompt Impediment Resolution
Month 7
  • Authenticity of Commitment
  • Simplicity, Maximize Work NOT Done
  • Test Early/Test Often
  • Authenticity of Commitments
  • Proactive Customer/Stakeholder Feedback
  • Test Early/Test Often
Month 8
  • Authenticity of Commitment
  • Satisfy the Customer
  • Delivery Frequently
  • Delivery Frequently
  • Satisfy the Customer
  • Follow-Through on Improvements
Month 9
  • Authenticity of Commitment
  • Follow-Through on Improvements
  • Simplicity, Maximize Work NOT Done
  • Simplicity, Maximize Work NOT Done
  • Swarming & WIP Limits
  • Prompt Impediment Resolution
Month 10
  • Authenticity of Commitment
  • Test Early/Test Often
  • Self-Organizing Teams
  • Authenticity of Commitments
  • Proactive Customer/Stakeholder Feedback
  • Test Early/Test Often
Month 11
  • Authenticity of Commitment
  • Simplicity, Maximize Work NOT Done
  • Satisfy the Customer
  • Delivery Frequently
  • Satisfy the Customer
  • Follow-Through on Improvements
Month 12
  • Authenticity of Commitment
  • Follow-Through on Improvements
  • Increase Productivity
  • Simplicity, Maximize Work NOT Done
  • Swarming & WIP Limits
  • Prompt Impediment Resolution

Here is a scenario that maps to the evolution visualized.


The Topic:  The team makes authentic commitments to what can be completed during a single sprint.

    • 1/15/2014 – The team agreed they were definitely not making authentic commitments during sprint planning, but they didn’t necessarily feel as if the sprint planning process was very difficult. It took time and patience, but wasn’t that hard.   This is an interesting place to be. Essentially the team is acknowledging we are “doing” this thing, but we are not necessarily getting the intended outcome we should achieve. How were they behaving? The sprint planning process involved task identification, but only commitment based on expected velocity.
    • 4/5/2014 – A few months later the team has drastically improved their ability to be authentic. They are not overcommitting as often and feel as if the predictability of their sprint commitments has increased. Unfortunately, the new way of achieving this feels more cumbersome and difficult than the “less beneficial” sprint commitments from before. Now its time to improve the way the outcome is achieved. How were they behaving? The sprint planning process included task identification, paperclip allocation to task to visualize hours, and reconciliation of task estimates to actual capacity.
    • 7/20/2014 – Time again has passed and the team is even a little better at authenticity, the process has improved as well. Definitely on the right track. How were they behaving?  Sprint planning still included task identification, hour estimates and capacity reconciliation, but they dropped the physical paper clips, an XLS spreadsheet was doing the tedious work for them.
    • 10/15/2014 – Oh no, something has gone wrong. The authenticity of the commitments is still high, but the process isn’t as smooth and easy as it used to be. How were they behaving?  The team adopted an Agile Project Management tool, and instead of using “just enough” technology to optimize the collaboration, they were getting bogged down in doing it the “right way” in the tool. It was getting in the way of their efficiency as a team.
    • 1/17/2015 – In a great spot. The team worked through process and tool issues and now is achieving high performance in the authenticity of sprint commitments. How were they behaving? The ScrumMaster took on the responsibility of transcribing task break-downs and hour estimates within the tool and allowed the team to collaborate using the right mix of tactile methods and calculators to help with reconciling capacity and commitment.

What’s a future level of maturity for Sprint Planning?  Check out the 4-Level maturity model outlined in our #BecomingAgile Webinar – High Performing Sprint Execution!

Scaling the Model

This model can be applied to more than a single team.  Select a single topic and plot the maturity of an array of teams to look at differences.  Allow the teams to come together to discuss their successes and challenges with the topic to build a true learning culture within your organization!

Print pagePDF page