agile methodologies

by

The Agile Buffet Rule

Take all you want, but eat all you take. – Jay Packlick

I learned about the Agile Buffet Rule from the ever loquacious @jpacklick. This is not to be confused with the Warren Buffett Rule or even the Jimmy Buffett Rule. The concept, as it applies to Agile, is simple: Take as many stories as you want from the backlog, but make sure you have the available capacity to complete the work you take. I’ve noticed a trend at some companies where teams are not completing all of the work they have committed to, but calling the sprint successful. Often they are close to completing all their work; however I was taught to finish everything on my plate. Maybe it was the way I was taught Scrum in the old days, but I still feel if you don’t complete all the work you commit to, your sprint was not successful. It is very empowering for a team to be able to use velocity and capacity to plan their work, and have the costumer’s confidence that you will be able to finish what was committed.  For Agile to be successful, you need to to win the trust of the business. You do that by delivering what you promise.  It should be uncommon when you don’t finish all the work you signed up for. To be clear, I don’t have any problem with teams adding stretch goals to the sprint, so long as everyone understands they are stretch goals, and not part of the sprint commitment. You have a ten pound sack of potatoes and that’s all that will fit. Don’t try to put fifteen pounds in a ten pound sack. When I’ve observed teams committing to more work than they have in the past, the common question I ask is: what is different about this sprint versus the last one? In other words, what has changed since the last sprint that enables you to commit to a higher velocity?

So that begs the question: how do we ensure that we complete all the work we commit too? We can break the answer into two parts: Planning and Executing the Sprint.

Planning

The obvious answers are to make sure  you are not going over your velocity or capacity thresholds (velocity in points and capacity in ideal hours). Your velocity is an average of your points over time (sprints), which should be relatively stable. So do not take more story points than your velocity. Likewise, if you are doing your planning via WIP, Cycle Time, etc. the same rule applies: Don’t take more than your WIP allows, unless something has changed.

Your capacity takes into account the number of hours available for this sprint. So make sure you are accounting for any changes in team personnel, holidays, vacations, etc. One way to achieve this is to create a capacity sheet which takes into account a simple formula for each team member: number days in the sprint x number of ideal hours per days x % dedicated = available capacity. Here’s a quick explanation of the variables:

  • Number of days in the sprint: This is the total number of days, less any holidays, training, conferences, vacation days, etc.
  • Number of ideal hours per day: This is the amount of hands-to-keyboard-time you actually do on project work each day. It could be based on an 8 hour work day, less meetings, breaks, lunch, phone calls, responding to emails, etc. I’ve seen teams use as little as 2 and as high as 6. Never more than 8 unless they plan to work 12 hours days. To give you some relevant data, from a study we did at Nokia, the average team only spends a 1/3 of their day on actual project work.
  • % dedicated: It’s unfortunate, but many organizations continue to loan team members across teams. As a result, you may have team members dedicated less than 100% to the team. Thus, you must adjust their capacity accordingly. I don’t condone this, but it is reality.  For those that are interested in  why this is a bad idea, you can find it here in Kenny Rubin’s most excellent presentation on Economically Sensible Scrum.

The end result is the total number of hours, each team member has available to commit to the sprint. During Sprint planning, when tasks are created and assigned, the Scrum Master (or other team member) can reduce the number of hours available, per team member, each time a task is assigned.  You are free to sign up for tasks until your total reaches 0. Here’s and example of a capacity worksheet I typically use:

Capacity Planning Chart

Capacity Planning Worksheet

Sprint Execution (aka How to Finish what’s on your plate)

On what he thought of his team’s execution: “I’m in favor of it.” – The late Tampa Bay Buccaneer’s Football Coach John McKay

Using the information radiators in Scrum is paramount. Use of the burndown chart and other information radiators (Cumulative Flow Diagrams, Cycle Time, WIP, etc.) to make timely decisions is critical. If it becomes clear that you are not going to be able to complete everything on your sprint backlog, when should notify your customer/product owner? The answer is immediately. The more time the PO has, the better the options become. Don’t make the mistake of waiting, thinking things will improve, when the data is telling you otherwise. As pilots, we are taught to trust our instruments and not our gut. Why? Because wishing the situation was different won’t help. The data is telling you that failure is on the horizon, it is better to admit it and come clean. Doing anything else erodes trust. Be decisive and be proactive. What strategies can we employ to make sure we finish the sprint? Here are some suggestions (in no specific order):

  • Remove impediments – This strategy should be obvious, and hopefully, is being done on a daily basis.
  • Swarm – Can we gang up on unfinished work?
  • Add people/experts – perhaps we are struggling with a difficult story and the expertise exists outside of the team. With this strategy, you are essentially trying to increase your velocity.
  • Move the stories to different owners – It could be that the person working on the story, isn’t the best one suited for the work.
  • Work overtime – Not ideal, but can work as long as it doesn’t happen very often.
  • Move into a team/war room – Sometime getting together in a crisis can help bring ideas out faster.
  • Out of ideas? – Ask for help. This is not the time to be shy. Ask the team, ask your manager, ask your coach, the Internet, etc.

The key of course, to making use of these (or other) strategies, is early detection. None of these will work if you procrastinate.

 

by

You can depend on me – Planning and Managing Dependencies and Risks in Agile

In preparing for battle I have always found that plans are useless, but planning is indispensable. – Dwight D. Eisenhower

There is a common misconception in Agile that we don’t do much planning. Agile is supposed to be all about cowboy coding and flying by the seat of your pants, or so I keep hearing. Rubbish! Those of us that have been practicing Agile for a number of years, know that nothing could be further from the truth. We know that it is a myth to believe that Agile methodologies cannot operate in a hard date-driven environment. We know that having a plan, is incredibly helpful when trying to manage  risks and dependencies. We also know, understand, and embrace that these plans are subject to change. However one of the most difficult aspects of Agile (or any other) project planning, is managing risks and external dependencies. These issues can cause delays and expensive interruptions in your project. In this post, I am going to focus on a few methods I’ve used to help plan and manage risks and dependencies in an Agile project.

Roadmap/Delivery Plan:

The Roadmap (or Delivery Plan) is an artifact, which deconstructs the Vision into a long-range plan by releases. This is usually created during Sprint 0 (or project start) and updated, at a minimum, at Release Planning. Ideally it is updated at the end of each Sprint. The Roadmap consists of themes and/or high-level stories (epics). The objective is to figure out, at a Release level, when these stories are being delivered or when they need to be delivered. Part of the exercise of building the Roadmap involves identifying and evaluating risks, as well as dependencies during upcoming releases. See the example artifact below.

roadmap

Release Plan:

The Release Plan is an artifact, which deconstructs the Roadmap into a high-level plan for each release, by Iterations. You only need to capture the high-level stories at this point. However, if you have a groomed backlog and know your team’s velocity, you can replace the epics or themes with actual stories and list the velocity per sprint. It is a quick information radiator to determine if you will be able to meet your sprint and release goals. You place the risks and dependencies you identified in the Roadmap into the Iterations you expect them to occur (if known). This gives the team a sufficient amount of time to prepare for upcoming risks and external dependencies. Generally, due to all the changes that occur during a Release, you only need to plan out enough Sprints to satisfy a single Release. The release plan is also created at Sprint 0, updated at the end of each sprint, and created at each release planning session.

releaseplan

Give To/Get From and Risk Stories:

Risk Stories

Thus far I’ve described planning and managing dependencies and risks at the Release level. At the Sprint level, managing external dependencies and risks is relatively straightforward. If you understand the risk, and it is both impactful and probable, you can often write stories to take action to mitigate the risk. Obviously you don’t want to write a story for every risk, so only pick the ones that are likely to happen and have a impact and probability greater than 3. So, you wouldn’t want to write a story to deal with a potential meteor strike, however you may want to put a story in the backlog to deal with a risky architecture issue.

risk risk2

Dependency Stories

A Give To or Get From story is an external dependency management story. You are expecting to receive something from another team, vendor, etc. (Get From), or you are expected to deliver something to another team, vendor, etc. (Give To). In general, a Give To/Get From story is the same as any other user story with the following exceptions:

  • There should be emphasis that the Story Point estimates and tasks are only for the work your team will do; since you cannot control work that is external to your team, it is not factored in. As a result, this will often be a low Story Point estimate. For example, this Get From story could be part of a larger epic on front-end website performance:
    • As a Systems Engineer, I want to get a performance report from Vendors A,B, and C, so that I can determine if their software’s UI response time will meet our .5 second threshold.
  • You will identify whom you have the dependency on (Get From) or who has the dependency on you (Give To).
  • There is a specific date of when you expect to receive or give the dependency resolution. This is used to give you plenty of time to prepare for the delivery (or if necessary, delay).
  • There is a clear description of the dependency and the expected resolution (Acceptance Criteria).
  • You NEVER write a Give To/Get From story for your own team (internal dependencies). Since you can control that work, the scheduling of the story and any potential impacts will be handled by the Product Owner and Scrum team.

Conclusion:

It is important to understand that the previous items are simply describing tools, processes and artifacts. They are NOT replacements for the values of Agile, the first of which is: We value individuals and iterations over process and tools.

In conclusion, don’t use these processes and artifacts as an excuse to not have a conversation about risks and external dependencies. Instead, use these tools, processes and artifacts to enhance the conversations you are already having .

by

What’s a Product Owner To Do?

When I coach companies on Scrum and Agile Methodologies, I’m used to having dedicated, co-located Product Owners and teams. Lately it seems, especially with large corporations involved in an Agile transition, Product Owners and Scrum Masters are leading multiple project teams; often they are not co-located. It can be challenging when trying to coach teams on Agile Manifesto values, such as: Individuals and Interactions over Processes and Tools. Often during these transitions, companies expect a PO to be a part-time Product Owner: doing PO work in addition to his/her day (or real) job. Many times I have had Product Owners ask me to help justify their full-time involvement so that their supervisors understand the extent of the time commitment involved with the role. I have done this by describing what a typical Product Owner does each day. So in this post, I am going to jot down a  (by no means exhaustive) list of what a Product Owner does on a daily basis (in no specific order):

  • Attends the team’s daily planning meeting (aka standup) to understand the team’s progress and issues towards the sprint goals.
  • Captures customer requirements (and wish lists) by writing (or helping others write) User Stories.
  • Accepts/rejects completed User Stories.
  • Prioritize and update the backlog.
  • Is available to the team each day to answer questions and clarify stories.
  • Verifies that stories are in the proper format, contain valid confirmation (aka Acceptance Criteria), and  are in-line with the product vision and scope. This includes any necessary design details, business rules, etc.
  • Makes sure that project/product vision and goals are clearly defined and communicated to everyone.
  • Works with the team to ensure stories meet the agreed upon “Definition of Ready” before pulling them into the sprints.
  • Helps remove obstacles that the team and Scrum Master cannot remove.
  • Makes sure that the Scrum Team has a direct connection with end users through story development and the Sprint Review.
  • Keeps stakeholders informed on project status and how much value has been generated for money spent.

In addition to that, on a bi-weekly or as needed basis:

  • Participate in the demo and retrospective meetings.
  • Work with the team to groom the Release backlog.
  • Work with the team to plan the iterations.
  • Meets with customers and stakeholders on a regular basis to field questions and inform them of project/product updates and changes.
  • Conducts the Sprint demo with the team to present the incremental functionality to users and stakeholders.

Feel free (or compelled) to add your own. My thanks to Bob Schatz @Agileinfusion for his sage advice and input.

by

Better Daily Planning Meetings: Asking the Right Questions

When coaching teams and observing their daily planning (aka standup) meetings I often hear the following questions asked:

  • What did you work on yesterday?
  • What will you work on today?
  • What is impeding your work?

These same questions are asked even with experienced teams. But are these the right questions to ask in a daily planning meeting? I submit that teams that ask these questions are in need of a paradigm shift. Are the answers to these questions really what we want to hear? I doubt it. What we really want to know is: How are we doing towards our goals in this iteration? So the focus should be less on the work and more on what actually got completed. Try these questions instead:

What did you get done yesterday?

What will you get done today?

What is preventing you from getting work done?

In other words, the focus should be on completing work, not just doing work. It is a somewhat subtle yet important point, that has other ramifications on how we do Scrum: We need to be breaking tasks down into small enough chunks to get accomplished in a day. If our goal is to complete user stories and get them accepted every two-three days, then tasks should be one day or less in length (in ideal time). It also means if tasks (or work) are not getting completed on a daily basis, we may have hidden impediments.

by

Blame != Accountability

I am often asked how teams are held accountable in Scrum and Agile methodologies. Many teams and Scrum Masters often confuse accountability with blame. To start, let’s make sure we understand the definitions of blame and accountable:

accountable 
— adj
1. responsible to someone or for some action; answerable
2. able to be explained
blame 
— n
1. responsibility for something that is wrong or deserving censure;culpability
2. an expression of condemnation; reproof
3. be to blame  to be at fault or culpable

Notice the difference?

Blame has a negative connotation and is often assigned to a single person. e.g. You messed up and it is your fault…

Accountability is not assigned, it is something the team, rather than the individual, owns. It is not positive or negative; it is connotation-less e.g. We did not fulfill our obligation/commitment – let’s find out why.

Blame is born of malice and ego. People who wish to assign blame are usually unhappy with anything less than a public flogging; which is why they are the first to shift the blame to someone else. It’s like watching a children’s game of Hot Potato.

Accountability is born of maturity and curiosity. People who are accountable are genuinely interested in finding cause (not fault) and improving the maturity of the team. Disciples of Edwards Deming will assert that the individual is never to blame; only the process is at fault. Blaming an individual removes focus from fixing the system.

To answer the original question: accountability occurs organically as part of the Scrum process. The team is committing to a Sprint, Release, etc. Who owns that commitment? The team does, not an individual. The team is not only making a commitment to the Sprint or Release, but also to each other. If the Sprint fails, the team will perform a retrospective to investigate why it failed. The only way accountability can happen is if the commitment is truly owned by the team. The team should care that they did not complete all of the work in the Sprint, and why the work wasn’t completed; but not to the point where blame needs to be assigned.

The team has the chance to hold itself accountable many times during the project lifecycle:

  • The team will be held accountable on a daily basis during the standup meeting. How are we doing on our Sprint goals? Do we need help? What is preventing us from getting work done?
  • The team will be held accountable during the Demo. Did we deliver what we promised? Was it of sufficient quality?
  • Finally the team will hold itself accountable during the retrospective. Did we honor our working agreements? What could we have done better? How will we improve next time? A team needs to be careful how it decides to run its retrospective, lest they start drifting back into the blame game.

In addition to the original question, newer Scrum teams often ask how tasks are assigned in Scrum (or who assigns them). This is an ancillary opportunity to discuss the concept of accountability. The answer is: tasks are not assigned, team members volunteer for tasks. Assigning tasks prevents accountability, by not allowing teams to decide how the work will get done.

To increase accountability within the team, I have found the following suggestions helpful:

  • In Backlog Grooming, only allow those that are actually doing the work, to estimate the story. Scrum Master and Product Owner do not participate (unless they are going to be working on the story).
  • In iteration planning, only allow those doing the work, to create the tasks. Furthermore, make sure you don’t assign tasks. Let the team members volunteer.
  • During standups, have the team face each other and let the team decide who and how they will report on tasks. Product Owner and Scrum Master should act as chickens unless there is an impediment to address.
  • During the Retrospective, let the team decide how they will run the retrospective. The Scrum Master can facilitate and act as scribe.

What opportunities and/or techniques have you found to increase accountability and reduce blame among your teams?