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.


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.


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/

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.

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.


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!


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.

 


Transparency & Authenticity in Daily Planning

blogimage_authenticity-daily-planningConsider this a continuation of my earlier discussion, Daily Planning saves Canaries (Projects). There I discussed how projects go off-track one day at a time, and how the Daily Planning session provides a vehicle for ensuring we don’t kill our canaries (or projects). Here I want to reinforce 6 concepts that are essential to transparency and authenticity in Daily Planning:

  1. Commitment to the Sprint
  2. Collaboration and Clarification
  3. Everyone has a Voice
  4. Remove the Roadblocks
  5. Improvement Opportunities
  6. WIP Limits

Commitment to the Sprint

Completing the work the Team committed to can be a challenge for Teams new to Agile. It is imperative that the ScrumMaster instill the importance of meeting commitments to develop the right mindset. Commitment to the Sprint entails dedication by each Team member in time and spirit. Over time, the Team understands what it can realistically commit to.

Collaboration and Clarification

Planning has a very strong human element, it’s not just about 0’s and 1’s

When used at a high level, Daily Planning can enhance collaboration and clarification. Daily Planning has a very strong human element:

  • It’s not just about 0’s and 1’s
  • It’s about the shared interaction
  • It’s about positive experiences
  • It’s about driving toward an outcome
  • It’s about personal commitment and accountability

Everyone has a Voice

Team members should be encouraged to actively participate regardless of title or tenure. Daily Planning should reinforce a collective mindset. Your voice should matter.

Remove the Roadblocks

A key component of Agile is about flow and removing those things that cause the flow of value to stop. The Daily Planning session allows the Team to recognize and address impediments. Once an impediment is identified, the Team needs to determine its priority and how to remove it. If it is something the Team has the ability to address, then they should self organize to remove the impediment based on its priority. If the impediment is beyond the control of the team then the ScrumMaster should escalate the issue in order to get it addressed at the right level and in the most expeditious manner possible.

Improvement Opportunities

The Daily Planning session allows Team members the opportunity to pull away from their busy day to inspect and adapt

The Daily Planning session allows Team members the opportunity to pull away from their busy day to inspect and adapt to what is happening at the Sprint level and make the necessary adjustments before diving back into their work. It helps to foster improvements and learned behaviors that correlate to higher proficiency and higher quality.

WIP Limits

Setting work in progress (or WIP) limits is helpful in maximizing the flow of work within a Sprint. The ScrumMaster can monitor and adjust the flow of work by:
Limiting the number of Stories that are worked on concurrently.
Limiting the number of Tasks worked on concurrently either at the Team Level using WIP limits at the appropriate Task State or at the individual level using avatars.

Establishing WIP limits can be part of the Team’s working agreements and it allows a Team to focus and concentrate on a pre-defined set of items emphasizing the mantra “stop starting, start finishing”.

Final Thoughts

Essential things to remember to get the most out of your Daily Planning session is to:

  • Make all work visible
  • Update the physical or electronic board prior to the Daily Planning session
  • Maintain discipline regarding the Daily Planning structure
  • Avoid pitfalls and smells at all costs!
  • Encourage creativity by the Team members regarding the Daily Planning session to keep it fresh.
  • Have fun!

Remember, projects get late one day a time. Using working software as the true measure of progress and conducting effective Daily Planning will help your Team to better meet their commitments without killing any canaries. (What is this business about killing canaries? Go back and read “Daily Planning saves Canaries (Projects)” a post from earlier this month.)


Enhanced Agile Glossary: Daily Planning

Using disparate terminology and an inconsistent vocabulary will make your Agile transformation harder. There is enough to learn absent the new terms and definitions associated with Agile, so don’t make it any harder than you have to.  This year, we’re making a concerted effort to revamp our online Agile Glossary with better, more in-depth definitions, and supplemental links to other online resources.

Our latest definition enhancement is Daily Planning (aka Daily Scrum, Daily Stand-Up). Here are a few other links and resources for Daily Planning you might find useful:

We hope you gain some valuable knowledge from these resources, and don’t forget to sign up for our upcoming webinar on March 5th: High Performance in Sprint Execution with Leslie Morse.

 


High Performance in Sprint Execution

TeamHuddleBecoming a high-performing Agile team is something every team strives to become.  Theses teams trust each other and have seamless collaboration and execution throughout the entire sprint. It is difficult to truly understand the characteristics of a high-maturity team until you’ve experienced it. As a result, you may find it difficult to guide your team to improve. More importantly, you may not be clear on what the different states of maturity are when it comes to achieving high-performance in Sprint execution.

During our March #BecomingAgile webinar, Leslie Morse will guide us through tell-tale characteristics of high-performing teams, observable traits of maturity in execution and a 4-level maturity model for assessing a team’s performance.

Register now and we hope to see you there!


Daily Planning Saves Canaries (Projects)

canary_art22Back in the early days of coal mining, a caged canary was brought into to the mine by the miners to act as an early warning system. The thought being that if the air was too noxious for the miners it would kill the canary before it killed the miners. A dead canary meant it was time to hightail it to the surface.

Years ago when taking my first project management training class, the instructor posed the following question to the class:

How does a project become late? … One day at a time.

“How does a project become late?”

After fielding many excellent responses, the instructor just smiled and said, “One day at a time”. The problem is that we usually did not know until the 11th hour that we were late. That is until we started to embrace working software as the true measure of progress.

The ‘Canary in a Coal Mine’ analogy, beyond just being a catchy Police tune, is an effective metaphor for the purpose of Daily Planning. Daily Planning allows an Agile team to see how they are tracking each day toward their Sprint commitments and make necessary and timely adjustments in order to meet those commitments.

Missing commitments at a daily level can create domino effect.

 Missed daily commitments impact the completion of commitments made at the Sprint level, which potentially have significant impact to a release.

At its core, Daily Planning provides the following:
It reaffirms Sprint Goal(s) so that the Team does not loose site of the forest for the trees.
It helps to build consensus within the Team through continually inspecting the work and process, holding each other accountable, seeking assistance, addressing issues and adapting to change.

While a Daily Planning session can help to save your canary (or project), if the session is not executed well, then you could simply be adding weight and inefficiency to a project that is already going off track. Think about the 15 Questions – Evaluate Excellence in Daily Planning as well as these potential pitfalls and smells of ineffective Daily Planning.

Pitfalls and Smells

Let’s explore some of the common pitfalls that occur during Daily Planning and the smells (anti-patterns) associated with them.

Not a Status Report

Think of the Daily Planning event as an information exchange by and for the Team. If the meeting turns into a status report, it may indicate that a Command and Control structure exists which isn’t ideal. If “all work is visible” and teams update the information radiators, then the “status update” is the physical or electronic board itself.

Not a Design Session

15 minutes doesn’t lend itself well to a design session. Teams shouldn’t allow the Daily Planning event to turn into a solution design workshop. It’s everyone’s responsibility to make sure that things stay on track. The ScrumMaster should observe when a discussion can be addressed within the timeframe or if it needs to move the “16th minute” so that the right people are involved and they have enough time to address the topic.

Do Not Focus on What Cannot be Controlled

It’s a natural inclination for Team members to focus their energy on things that are outside of their control. This is especially true when there are multiple dependencies with external groups or integration points within a release. This external focus can negatively impact the Team since it moves their energy away from those things they can control.

The ScrumMaster should keep the focus on what the Team has control over within the meeting and use their influence outside of the meeting to address issues and dependencies that impact the team.

It is Not About the ScrumMaster

Remember, the Daily Stand Up is not about the Team reporting their progress to the ScrumMaster. Rather, they are communicating to their peers. The focus of Daily Planning is about the Team, their commitments and the value being created. (If you are a ScrumMaster that feels like everyone is talking directly to you, consider turning your back to the team during the session to emphasize that they are meant to be talking to one another.)

Failure to Observe

Observation during the Daily Planning session is an essential and a critical skill for Team members, ScrumMasters and Product Owners. A ScrumMaster should be aware of their own body language, voice and mannerisms as well as those in the meeting to pick up on verbal and nonverbal communication that is occurring. Are Team members relaxed or stressed? Does anyone require assistance? Keen observation leads to powerful questions that can assist the Team by exposing issues and bringing them to the surface so they are addressed.

For more observation tips, read our post titled, 15 Questions – Evaluate Excellence in Daily Planning, which was referenced above.