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.


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.


15 Questions – Evaluate the Excellence of Daily Planning

blogimage_evaluate-the-excellence-of-daily-planningAre you curious as to how to put a coaching point-of-view on evaluating a Daily Planning session? Try out the following set of 15 questions to gather observations and assess trends over time:

  1. What Sprint is it?
  2. Were all Team Members present?
  3. Was the Product Owner in attendance?
  4. Were other stakeholders in attendance?
  5. How long did the session take?
  6. Were ALL team members engaged and committed to the outcome?
  7. Were Team Members providing status reports?
  8. Were metrics and information radiators reviewed to help determine if the team was on track?
  9. Did Team Members lead with the name of the backlog item when talking about tasks?
  10. Did Team Members make personal commitments to complete specific tasks?
  11. Did Team Members hold one another accountable for the previous day’s commitments?
  12. Did Team Members proactively raise (but not solve) impediments during the session?
  13. Did individuals other than Team Members contribute and participate during the session?
  14. How many backlog items had tasks in progress?
  15. Were all attendees invited to collaborate and resolve issues immediately after the session ended?

A little commentary about each question…

What Sprint is it?
e.g. Sprint 4 This is important to track so that you can associate these observations to other metrics and information.

Were all Team Members present?
When considering this, think about not only attendance of team members, but the appropriate co-location. The Daily Planning session is for the sole purpose of Team Members coordinating tasks for the day in order to determine if they are on track to meet the overall sprint commitment.

Was the Product Owner in attendance?
While the Product Owner is not ‘truly’ required, it is highly recommended that the they be in attendance. This will ensure that they are up-to-speed on whether or not the team will deliver everything they committed to, allow them to listen for indicators the team may be off track, hear questions the team has first-hand and be available to discuss answers during the after meeting.

Were other stakeholders in attendance?
This is useful to track over time to assess trends in effectiveness of the session. If you find team members have periods of time where the daily session is cumbersome and less effective, it will be interesting to see if this corresponds to times where non-team-members were in attendance.

How long did the session take?
Keep in mind the session is intended to be brief and to-the-point. If it consistently trends longer than 15-20 minutes, that is a sign that something may be going wrong.

Were ALL team members engaged and committed to the outcome?
Each team member should participate in this session equally, we are interested in understanding if team members are committed to the desired outcome from the Daily Planning session.

Were Team Members providing status reports?
The intent is not to report on the status of tasks, but to share with others what has been completed so the next logical task can be picked-up without lag time. This ensures that handoffs and coordination points can be as smooth as possible.

Were metrics and information radiators reviewed to help determine if the team was on track?
Up-to-date Burn-Down charts and Task Boards are the most effective way for a team to understand if they are on track. Additionally, actively engaging with a Task Board where team members physically move a task card to the “In Progress” column results in a greater sense of accountability to following-through on commitments.

Did Team Members lead with the name of the backlog item when talking about tasks?
Clearly referencing the backlog item the tasks are associated with ensures transparency in what items are being worked on. It also allows the ScrumMaster and other attendees to better notate what items are moving forward, which task impediments are tied to, and if too many items are in process simultaneously.

Did Team Members make personal commitments to complete specific tasks?
It is easy for Team Members to indicate what they are working on, however high-performing teams are comprised of individuals that are clear about what they commit to finishing on any given day.

Did Team Members hold one another accountable for the previous day’s commitments?
Personal commitments are worthless if people are not held accountable. A healthy level of peer pressure is present in mature Agile teams. If several days pass where the same task is supposed to finish, a colleague should step up and offer assistance or ask if there is an impediment.

Did Team Members proactively raise (but not solve) impediments during the session?
The Daily Planning session is not for solving impediments and answering questions. If the team takes the time to do that, then the length of the session is probably running too long.

Did individuals other than Team Members contribute and participate during the session?
The session is not for non-team-member attendees. A pattern of participation from stakeholders should be nipped in the bud as soon as possible.

How many backlog items had tasks in progress?
Context switching is detrimental to efficiency and effectiveness. If there are consistently more than 3 backlog items being worked on during any given day, then there is likely room for the team to look for swarming opportunities. Start less, finish more.

Were all attendees invited to collaborate and resolve issues immediately after the session ended?
If attendees immediately disperse when the session is over, then the clarity and awareness of issues will begin to fade. Reserve time and space immediately after the Daily Session to have a meeting for answering stakeholder questions, finer grain task coordination, and resolution of impediments.


Agile Q&A: Extra Sprint Capacity

blogimage_extra-sprint-planning-capacity

 

The Question: What should we do with extra capacity during Sprint Planning sessions?

The Answer: It depends. Isn’t that always the answer?

 

 

 

Before we dive into the response to this question, lets take a moment to review a few things about capacity and sprint planning.

  1. Teams measure capacity in hours. (Wondering what to consider when calculating an individual team member’s capacity? Check out the Capacity Planning Worksheet we have in the Agile Tool Kit.)
  2. Comparing tasks’ hour-estimates to the team’s available capacity to ensure authenticity. This helps the team avoid overcommitment.
  3. It is incorrect to pull a partial set of tasks for a backlog item. The goal is not “full utilization.” If the team will not complete the user story within the coming sprint, then the team should not start on it early.

It is quite common for teams to have “left over” hours,unallocated time at the end of a sprint planning session. In a perfect world, the team would have an item small enough that within the hours remaining they could complete all tasks. We all know that Agile teams live in an imperfect world.

So, what to do? Here are 4 great ideas for how to use your extra capacity.

  1. Pairing for Quality
  2. Pairing for Cross-Training
  3. Refinement
  4. Refactoring

 

Pairing for Quality

You can think of this as traditional pairing. Putting two team members together to gain efficiencies in quality. Two sets of eyes on one task allows both the right-brain and left-brain to engage simultaneously. Dual perspectives increase precision and offer a systems-thinking lens to the activity. This allows for enhanced execution and assessment of overall quality. While it may seem inefficient on the surface, studies show the reduction in rework outweighs the cost of pairing.

Consider promiscuous pairing when allocating capacity. Expand pairing beyond two team members with the same expertise. (e.g. Pairing a developer with another developer.) Cross-discipline pairing has proven to be beneficial for teams as well. It is also the perfect segue to the second recommendation.
 

Pairing for Cross-Training

There is a spectrum of specialist → generalist. High-performing, cross-functional teams are not comprised of all specialists. If they were, then swarming and task sharing would be much more difficult. Strong teams have the right level of specialty in certain disciplines and also include individuals with general knowledge and understanding useful for many activities. (Consider reading The Life of Pi blog post by Tom Wessel for more information on growing this capability.)

Prevent bottlenecks and increase the ability for team members to take on tasks outside of their traditional area of responsibility by using extra capacity for cross-training. Testing activities are a great place to start; exceptional Agile teams are efficient and effective at swarming testing activities. That means every team member should develop expertise in the discipline of quality assurance.

You may also find it useful to pair developers with skills in varying technologies and languages. This provides opportunities for professional development and mentoring while team members increase their skill-sets.
 

Refinement

Getting a Story Ready” highlights that teams should avoid pulling an item for Sprint Planning unless it is “ready” for commitment. Backlog depth and ‘readiness’ are separate topics, but it is safe to say there is always backlog refinement to do. Leveraging extra capacity for refinement is a way to pay-it-forward and ensure future sprints will come and go with fewer impediments and gotchas.
 

Refactoring

Every system has technical debt. Extreme Programming (XP) practices tell us Refactoring is key to technical excellence. Agile Principles state technical excellence is essential for agility. If technicians on the team have extra capacity, use your available time to refactor a piece of code and make it better. The effort now, will make maintainability, scalability, and agility a lot easier in the long run.

What are your ideas for using extra capacity? Please leave your thoughts below!


Task Planning

blogimage_task-planningWithin the Agile community, the use of User Stories is a very popular method of building, categorizing and prioritizing components of work. The approach follows a very simple and easy to understand structure that teams use in order to build value for their respective customers. User Stories, when written correctly, can be understood by stakeholders, customers, line of business managers and the teams that will build value. This structure, which has worked well for many organizations is a way to help bring consistency and alignment across the enterprise; up to and including actual customers. In addition to User Stories, many teams decompose their actual work lists into items called Tasks. For new and even some experienced Agile teams, tasking stories can be confusing and, at times, burdensome. The purpose of this article is to address some of the common concerns around tasks from two viewpoints (theoretical and practical application). The intent is to provide you, the practitioner, with information that can help you in your Agile journey at the individual, team and even organization level.

Task Planning Top Five

Davisbase strives to develop teams that deliver value. Organizationally, task planning is a value based activity that provides teams with a tremendous amount of visibility. This visibility provides the team and organization with a high degree of transparency in regards to the actual activities that are needed in order to create valuable applications. As you move forward in your respective task planning activities, we’d like to share our top five reminders:

  1. Task Planning is done by the team
  2. Task Planning activities are for the team
  3. Create a task planning approach as part of the team’s working agreement
  4. Wherever possible, tasks should be broken down into units of work that can be accomplished in a day
  5. Tasks should be specific enough to be understood by multiple team members

Who are tasks for?

When teams begin to discuss and determine the best way to complete User Stories, they are already creating a sequence of events (initially verbally) that they will follow in order to accomplish the intent and desire of the User Story. For many team members, the process of writing their approach down via “tasks” is a very logical process to follow. Creating tasks and assigning them to a User Story will give the entire team the visual representation that they deserve in order to complete the work. As such, organizations should always encourage that tasks be written by the team, given the fact that tasks are for the team. It is natural and common that individuals outside of the team may understand the tasks (i.e. ScrumMaster, Product Owner, DBA, Architect, etc.), yet it’s always important to know who the tasks are for. Tasks are for the team.

Anti-pattern: As coaches, we’ve seen examples where tasks are written by the “leads” for the team. This should be considered an anti-pattern in that teams deserve the chance to self-organize and create their own work approach. “Leads” are important to teams, yet these members should write their own tasks and encourage others to do the same. Of course, there will always be exceptions to this statement, but make sure that the team has the opportunity to have the discussion.

What are the right kinds of tasks?

Teams have the freedom and responsibility to determine the best way to complete their work. As such, the right kinds of tasks will be depicted by the team on a story by story basis. Ideally, tasks should be specific enough to allow the team to recognize that a specific increment of the story has been completed. In some aspects, tasks may be tied back to the acceptance criteria that was written for the story itself. In addition, many teams will create a task structure as part of their team working agreement. An example of a task structure could include items like:

1. Development tasks
2. Peer Review tasks
3. Code Review tasks
4. Development unit test tasks
5. Quality tasks
6. Quality test tasks (manual, automated, etc.)
7. Review and acceptance tasks

Anti-pattern: For those of us coming from a project management viewpoint, we’re always looking for structure and consistency. It’s natural for us to want to create process, but we should always remember that the team’s own the tasks, just like they own the commitment. Encourage teams to create their own working agreements and task structures, but realize that each team is different and not all User Stories will have the exact same task structure.

What is too generic?

Tasks, as defined and written by the team, should be specific to the individuals working on the task and/or the team at large. Writing tasks is repetitive on a story by story basis and is an activity that will continually take place for the teams. While many teams create tasks and assign those tasks to team members, some teams write tasks that are specific enough to be picked up and work on by one or multiple people. Making tasks specific should be considered a best practice because the specificity will provide the team with necessary information in order to execute the work. Avoid writing generic tasks like this real life example below wherever possible:

1. Code story
2. QA task
3. DEV only task
4. QA only task

Anti-pattern: Agile teams strive to have all work visible, including tasks. While the tasks are certainly for the team, generic tasks can provide a false sense of security to both the team and anyone else who looks at the tasks. The false sense that can be derived is that not enough discussion has taken place by the team in order to determine the best approach for completing the story. Writing specific tasks can and will alleviate this concern.

What is a well-written task?

Well written tasks can be understood by multiple people on the team. As coaches, we believe that tasks have value and that the value is recognized incrementally as the User Story moves through various states (eg. defined, ready, in process, completed, released, etc.). An excellent best practice is encouraging task review (where applicable) as part of the Sprint/Iteration Planning process. Many teams may begin their work by writing standard tasks together and then splitting off into different areas to write additional tasks. Yet, those same teams will always come back together in order to review the tasks that have been written.

Anti-pattern: Don’t rely on team leads or SME’s to write tasks for the upcoming Sprint/Iteration. Active participation should be anticipated and encouraged by anyone who will be doing actual work on the User Stories.

Should they be estimated in hours? If yes, how many?

paperclipsFor teams that are new to an Agile mindset, many coaches will recommend that tasks be estimated in hours. The primary reason for this approach is to allow the team the ability to compare their tasked hours against their available hours for the upcoming Sprint/Iteration. This is an important activity that will help the team make a determination if they can commit to the body of work that has been provided by the Product Owner.

In addition, many coaches believe that tasks should be broken down into units of work that can be completed in less than a day. This is an excellent approach for new teams, yet we’d like to offer another viewpoint by saying, “Encourage teams to break down tasks into the smallest unit possible that provides value”. In our experiences, we’ve found that tasks are still items that can be completed in less than a day; yet understanding and thinking about value helps many people take their understanding and appreciation for the work completed to higher and higher levels.

Finally, some organizations have gotten to the point where they no longer estimate tasks in hours. These are usually found with very mature teams that have worked together within a very specific organizational culture. For those, the concentration is truly centered around value creation and value recognition throughout both the organizational hierarchy and via the customer community.

Anti-pattern: Avoid forcing teams to write tasks that must be completed in a work day. This will stifle the team on many different front. Encourage task creation that provides a solid understand of how the problem will be addressed. Encourage team members to determine the “best way” to solve the User Story. And finally, encourage team members to write tasks into specific items that have incremental value towards the successful completion of the User Story.

Are they just for one person?

As mentioned above tasks are not always just for one person. Teams that use both pairing and peering approaches will structure their work in such as way that more than one person will work on a task at a specific point in time. In addition, some teams don’t assign each and every task to a person prior to making a commitment and then executing against the commitment. Therefore, some tasks may not have one owner…they may have multiple owners. It is important to note that many of the tools in the open market don’t allow tasks to be assigned to multiple people at the same time. Some organizations have circumvented this issue by creating general users within their systems that represent two or more people.

In addition, it’s very important to understand the team member skill composition mix (generalists, specialists, generalized specialists). An awareness of this structure will be very beneficial in understanding which tasks should be assigned to a specific person versus those that may be assigned to multiple people. For some, this may seem like an intermediate to advanced concept. If you’re new to “tasking,” see how many of those tasks can be assigned to just one person. That will definitely get the conversation started in the right direction. You will find that many of our experiences will assign tasks to just one person. At the same time, the exceptions to the rule help to better understand the dynamics of the team and will help skills develop and organizations mature.

Keep push your own Agile limits and remember, “championship teams are not created when it’s perfect outside”.


15 Questions – Markers of Quality Sprint Planning Sessions

15 Questions – Markers of Quality Sprint Planning Sessions

Curious how to put a coaching point-of-view on evaluating a Sprint Planning session? Our team uses the following set of 15 questions to gather observations and assess trends over time.

  1. What Sprint is it?
  2. Were All Team members present?
  3. How long was the session planned for?
  4. How long did the session take?
  5. Were ALL team members engaged and committed to the outcome?
  6. Was the Product Owner available, engaged, and committed to the team’s success?
  7. Were backlog items refined and ready for Sprint Planning?
  8. Did the team define a sprint goal (or theme)?
  9. Did the team define capacity in hours?
  10. Did team members break down each backlog item into a detailed task plan?
  11. Were tasks right-sized to start and finish in a day?
  12. Did the team rationalize capacity against detailed task estimates?
  13. Did the team commit to their Sprint Plan?
  14. Did the team proactively identify dependencies among tasks?
  15. Did the team proactively identify potential impediments that may occur during the sprint?

A little commentary about each question…

What Sprint is it?
e.g. Sprint 4 This is important to track so that you can associate these observations to other metrics and information.

Were All Team members present?
When considering this, think about not only attendance of team members, but the appropriate co-location. The commitment made during Sprint Planning should be made collectively by all team members.

How long was the session planned for?
This is most likely tracked in hours, rounded to the nearest quarter hour. More mature teams will not need as long for a Sprint Planning session, however, new team may take as many as 4-6 hours to complete the session. Keep in mind, if you are planning for the session to last 5-6 hours, be sure to allow for a break.

Teams that have well-refined backlogs do not generally take more than 1-2 hours for Sprint Planning. When sessions run longer, that is an indication that backlog items are not ‘ready.’

How long did the session take?
Again, track this in hours, rounded to the nearest quarter hour. Look for trends such as consistently running over, or not taking up all the time allotted. Just because a session is planned for 4 hours, doesn’t mean you have to use all 4 hours. It’s finished with the objectives have been achieved. And don’t forget, its OK for the session to be longer than expected. The entire team needs to agree to extending the duration.

Were ALL team members engaged and committed to the outcome?
Each team member should participate in this session equally. Here we are interested in understanding if team members are committed to the desired outcome from the Sprint Planning session.

Was the Product Owner available, engaged, and committed to the team’s success?
Sprint Planning is essentially the moment a backlog item’s scope is locked down. As team members identify tasks it is inevitable that final questions will come up in relation to acceptance criteria and what is in-scope for the story. As a result, the Product Owner should be available and engaged in the session to ensure the team is constructing a plan for the right product increment.

Were backlog items refined and ready for Sprint Planning?
“Ready” for Sprint Planning can mean a lot of things. e.g. Backlog Items: are written in good form; have Acceptance Criteria that define the Product Owner’s needs; are discussed and understood by the Team; are decomposed from Epics into small Stories that can be delivered in one Sprint; are estimated by the Team in Story Points; are prioritized in rank-order by the Product Owner; have needed supporting documentation.

bookCheck-out this previous blog post on what ‘ready’ means: Getting a Story “Ready”

 

Did the team define a sprint goal (or theme)?
e.g. Complete the registration feature. A sprint flows well when the work is synergistic. If all backlog items are somewhat related then the tasks will naturally coordinate and the team will encounter less context switching as the sprint progresses.

Did the team define capacity in hours?
Before the session starts, team members should have thought through their individual capacity to commit to work. The determination should take into account planned vacation, non-team meetings and events, team collaboration and planning sessions as well as natural inefficiencies in work (about 20%). The facilitator (likely ScrumMaster) can then sum the numbers to determine the total team capacity.

Check-out the Capacity Planning worksheet within our Agile Tool-Kit to help team members think through their individual capacity in advance of the Sprint Planning session.

Did team members break down each backlog item into a detailed task plan?
Backlog items are historically decomposed into individual tasks. Ensure that enough tasks are planned to cover all items called for by the team’s Definition of Done. While backlog items are sized relatively using points, tasks should be estimated in hours in order to enable a team to make authentic commitments. This list of backlog items, tasks, and hour-estimates becomes the team’s Sprint Backlog or Sprint Plan.

Were tasks right-sized to start and finish in a day?
Humans are naturally inefficient creatures. So its safe to say that an 8-hour task will take more than 1-day to complete. Shoot for breaking down tasks to a 4-6 hour increment so that team members can commit and complete each day during the Daily Stand-Up. At most, use a 12-hour task (2-days of work).

Did the team rationalize capacity against detailed task estimates?
Consider responses like: On Target, Over-committed, and Under-committed. Sprint Planning is not magical, and teams should not waste time trying to make capacity and task estimates match up exactly. The goal is to best utilize the capacity available and avoid overcommitment as much as possible. Try to always come within 5-8% of the team’s capacity.

book

Look for an upcoming Agile Q&A Post about what to do with extra capacity.

 

Did the team commit to their Sprint Plan?
The ultimate objective of a Sprint Planning session is a commitment to deliver an increment of work. At the end of the session Team Members should look at the holistic plan and make an official commitment to deliver.

There are 2 aspects of the commitment. 1) Team Members committing to one another that they are going to band together to get the work done. 2) Team Members committing to the Product Owner that they will have something ready to demonstrate at the end of the iteration.

Did the team proactively identify dependencies among tasks?
Whether they are dependencies between tasks or external dependencies with other groups and teams, the identification and tracking of dependencies associated with the sprint is critical to success. In fact, looking at the critical path of tasks for each backlog item and analyzing dependencies will help a team further assess whether or not they are making a realistic commitment.

Here is a quick tip: For critical tasks, assign a “Must Start By” date. This will help know if stories with dependencies are on-track for closing out the backlog item.

 

Did the team proactively identify potential impediments that may occur during the sprint?
Teams that think ahead about impediments are less likely to encounter them. Experience tells us that task planning naturally uncovers potential impediments. It’s best to go ahead and capture that list so that you can work to resolve them before they even occur.