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

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

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.

the-process-of-transition-fisher-s-personal-transition-curve--1 

– – – –

 

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.

determineTopic

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.

gatherData

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.

actiopnPlan

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.

trackProgress

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

15 Questions: High Performing Sprint Execution

blogimage_15-questionsThe two previous “15 Questions” posts have been pretty straight forward because they have addressed specific ceremonies within the Scrum framework (Sprint Planning and Daily Planning). This month we are going to dig into 15 Questions that explore the performance of teams as the sprint is progressing.

  1. Does the team limit the # of backlog items in progress at a time?
  2. Does the team limit the # of tasks in process at a time?
  3. Does the team proactively communicate the status of items that may not be finished within the timebox?
  4. Do team members swarm to assist in resolving impediments?
  5. When the team encounters a significant impediment or blocker and it is clear this will jeopardize the ability to deliver against the sprint commitment, do team members provide the Product Owner the choice to defer the story with the impediment or proactively defer another committed story for the sprint?
  6. Do team members pull the next highest priority task regardless of the person originally planned to take on that activity?
  7. Are team members taking on tasks outside of their traditional job responsibilities?
  8. Does the team preview stories with the Product Owner in advance of Sprint Review and/or Demo?
  9. Are impediments assigned a “solve by” date that indicates when they will become a blocker?
  10. Does the team deploy a build multiple times a day in order to test early and often?
  11. Are testing and quality assurance activities taking place throughout the sprint?
  12. Do team members actively collaborate to resolve defects/issues discovered within the sprint?
  13. Do team members pair on tasks in order to increase quality and find defects/issues sooners?
  14. Does the ScrumMaster protect the scope of the sprint so that the team can focus and be free of distractions?
  15. Is the Product Owner readily available to answer questions and remove ambiguity about how the product should work?

A little commentary about each question…

1. Does the team limit the # of backlog items in progress at a time?
e.g. The team committed to 7 backlog items, but only 3 are ever in progress at once. This policy for the team will encourage swarming and prevent teams from leaving multiple stories partially done at the end of the sprint.

2. Does the team limit the # of tasks in progress at a time?
e.g. The team has a WIP limit of 5 on in-progress tasks. This level of policy helps increase efficiency of teams by preventing context switching.

3. Does the team proactively communicate the status of items that may not be finished within the timebox?
Complete versus Commit surprises should be limited. The moment it is clear that an item may not be completed during the confines of the sprint everyone should be aware and understand the potential impact that has to other sprints and the overall plan for the product increment/release.

4. Do team members swarm to assist in resolving impediments?
Impediments are an issue for the entire team, not just the individual (or set of individuals) working on one of the backlog items. Pausing other work in progress to swarm and resolve an impediment as a team indicates a strong team culture and mindset.

5. When the team encounters a significant impediment or blocker and it is clear this will jeopardize the ability to deliver against the sprint commitment, do team members provide the Product Owner the choice to defer the story with the impediment or proactively defer another committed story for the sprint?
There are times when it makes more sense to pause work that has a significant impediment in favor of finishing other work. The ability to pause, refine the story further, and recommit in a future sprint can minimize rework and swirl within the sprint. This should not be a decision made in isolation though. Ultimately the PO should decide which backlog items are of most importance.

6. Do team members pull the highest priority next task regardless of the person originally planned to take on that activity?
Identifying target team members during Sprint Planning can help with the authenticity of commitments, but that doesn’t mean those are hard-and-fast task assignments. Working tasks in priority order assists with limiting story WIP and minimizing the amount of work left partially done.

7. Are team members taking on tasks outside of their traditional job responsibilities?
Pi-shaped employees are essential for realizing the highest levels of organizational agility. If individuals only take on tasks within their traditional skill-set then a silo’d culture will continue to prevail and bottlenecks will most certainly exist within the flow of work.

8. Does the team preview a story with the Product Owner in advance of Sprint Review and/or Demo?
Product Owners should be treated as a part of the team not apart from the team. As soon as there is something working, preview it with the PO. This early and continuous feedback increases the chance of gaining acceptance at the end of the iteration.

9. Are impediments assigned a “solve by” date that indicates when they will become a blocker?
All impediments are a risk to meeting the sprint commitment. Knowing a “drop-dead” date on resolution will help ensure everyone is on the same page and that impediments do not linger too long.

10. Does the team deploy a build multiple times a day in order to test early and often?
This is a good leading indicator of the teams’ technical maturity. Come back later this month for a full post on measuring the Technical Excellence within an organization/team.

11. Are testing and quality assurance activities taking place throughout the sprint?
Teams should avoid “scrummerfall” where a few days within each iteration are spent analyzing the stories, developing the stories and then testing the stories. Activities from each discipline should be occurring at all times throughout the time-box.

12. Do team members actively collaborate to resolve defects/issues discovered within the sprint?
This helps assess the level of engagement and team-based-mindset that the individuals possess. Note: this is different than the idea of swarming to resolve an impediment.  This question is intended to explore how teams collaborate to resolve functional defects within the product.

13. Do team members pair on tasks in order to increase quality and find defects/issues sooner?
Pairing need not be exclusively between individuals that share the same skill-set. Consider promiscuous pairing across disciplines.

14. Does the ScrumMaster protect the scope of the sprint so that the team can focus and be free of distractions?
The integrity of the sprint is essential. The ScrumMaster should act as a shield for the team proactively addresses and preventing disruptions and ensuring that scope is not added mid-sprint.

15. Is the Product Owner readily available to answer questions and remove ambiguity about how the product should work?
Any lag time that exists between when a question is raised and response provided represents waste within the system. Product Owners should be Available, Knowledgeable, and Empowered to aid and assist teams on a daily basis.

 


Print pagePDF page