Agile development Methodology and Planning 2018
If you’re a project manager, you probably do the bulk of your planning at the beginning of a project. You may have heard the phrase, “Plan the work, then work the plan,” which sums up non-agile project management approaches. Agile projects, in contrast, involve planning upfront and throughout the entire project.
By planning at the last responsible moment, right before an activity starts, you know the most about that activity. This type of planning, called just-in-time planning or a situationally informed strategy, is a key to agile project success. Agile teams plan as much as, if not more than, traditional project teams.
However, agile planning is more evenly distributed throughout the project and is done by the entire team that will be working on the project. In this blog, we explain the complete Agile Development Methodology 2019
Planning happens at a number of points in an agile project. A great way to look at the planning activities in agile projects is with the Roadmap to Value.
The Roadmap to Value has seven stages:
The product owner identifies the product vision. The product vision is your project’s destination or end goal. The product vision includes the outer boundary of what your product will be, how the product is different from the competition, how the product will support your company or organization’s strategy, who will use the product, and why people will use the product. On longer projects, revisit the product vision at least once a year.
The product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a general time frame for when you will develop those requirements. It also gives context to the vision by showing the tangible features that will be produced during the project.
Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. The product owner, with support from the development team, should revise the product roadmap at least biannually.
the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working functionality to the customer. The release serves as a mid-term boundary against which the scrum team can mobilize. An agile project will have many releases, with the highest-priority features appearing first. You create a release plan at the beginning of each release, which is usually at least quarterly.
the product owner, the development team, and the scrum master will plan iterations, also called sprints, and start creating the product functionality in those sprints. Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, which establishes the immediate boundary of work that the team forecasts to accomplish during the sprint, with requirements that support the goal and can be completed in the sprint. The scrum team also outlines how to complete those requirements.
the development team has daily scrum meetings during each sprint to coordinate the day’s priorities. In the daily scrum meeting, you discuss what you completed yesterday, what you will work on today, and any roadblocks you have so that you can address issues immediately.
the scrum team holds a sprint review at the end of every sprint. In the sprint review, you demonstrate the working functionality to the product stakeholders.
the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses the completed sprint with regard to their processes and environment and makes plans for process improvements in the next sprint. Like the sprint review for inspecting and adapting the product, a sprint retrospective is held at the end of every sprint to inspect and adapt your processes and environment.
Each stage in the Roadmap to Value is repeatable, and each stage contains planning activities. Agile planning, like agile development, is iterative. Progressive Elaboration. During each stage of an agile project, you plan only as much as you need to plan. In the early stages of your project, you plan widely and holistically to create a broad outline of how the product will shape up over time.
In later stages, you narrow your planning and add more details to ensure success in the immediate development effort. This process is called a progressive elaboration of requirements.
Planning broadly at first and in detail later, when necessary, prevents you from wasting time on planning lower-priority product requirements that may never be implemented. This model also lets you add high-value requirements during the project without disrupting the development flow. The more just-in-time your detailed planning is, the more efficient your planning process becomes.
Some studies show customers rarely or never use 64 percent of the features in an application. In the first few development cycles of an agile project, you complete features that have the highest priority and that people will use.
Typically, you release those groups of features as early as possible to gain market share through first-mover advantage; receive customer feedback for viability; monetize functionality early to optimize return on investment (ROI), and avoid internal and external obsolescence.
Inspect and adapt
Just-in-time planning brings into play two fundamental tenets of agile techniques: inspect and adapt. At each stage of a project, you need to look at the product and the process (inspect) and make changes as necessary (adapt).
Agile planning is a rhythmic cycle of inspecting and adapting. Consider the following:
Each day during the sprint, the product owner provides feedback to help improve the product as the development team creates the product.
At the end of each sprint, in the sprint review, stakeholders provide feedback to further improve the product.
Also at the end of each sprint, in the sprint retrospective, the scrum team discusses the lessons it learned during the past sprint to improve the development process.
After a release, the customers can provide feedback for improvement. Feedback might be direct, when a customer contacts the company about the product, or indirect when potential customers either do or don’t purchase the product.
Inspect and adapt, together, are fantastic tools for delivering the right product in the most efficient manner. At the beginning of a project, you know the least about the product you’re creating, so trying to plan fine details at that time just doesn’t work. Being agile means you do the detailed planning when you need it, and immediately develop the specific requirements you defined with that planning.
Now that you know a little more about how agile planning works, it’s time to complete the first step in an agile project: defining the product vision.
Defining the Product Vision
The first stage in an agile project is defining your product vision. The product vision statement is an elevator pitch, or a quick summary, to communicate how your product supports the company’s or organization’s strategies. The vision statement must articulate the end state for the product.
The product might be a commercial product for release to the marketplace or an internal solution that will support your organization’s day-to-day functions. For example, say your company is XYZ Bank and your product is a mobile banking application. What company strategies does a mobile banking application support? How does the application support the company’s strategies? Your vision statement clearly and concisely links the product to your business strategy.
The product owner is responsible for knowing about the product, its goals, and its requirements throughout the project. For those reasons, the product owner creates the vision statement, although other people may have input. After the vision statement is complete, it becomes a guiding light, the “what we are trying to achieve” statement that the development team, scrum master, and stakeholders refer to throughout the project.
When creating a product vision statement, follow these four steps:
Develop the product objectively.
Create a draft vision statement.
Validate the vision statement with product and project stakeholders and revise it based on feedback.
Finalize the vision statement.
The look of a vision statement follows no hard-and-fast rules. However, anyone involved with the project, from the development team to the CEO, should be able to understand the statement. The vision statement should be internally focused, clear, nontechnical, and as brief as possible. The vision statement should also be explicit and avoid marketing fluff.
Step 1 Developing the product objectively
To write your vision statement, you must understand and be able to communicate the product’s objective. You need to identify the following:
Customer: Who will use the product? This question might have more than one answer.
Key product goals: How will the product benefit the company that is creating it? The goals may include benefits for a specific department in your company, such as customer service or the marketing department, as well as the company as a whole. What does specific company strategies the product support?
Need: Why does the customer need the product? What features are critical to the customer?
Competition: How does the product compare with similar products?
Primary differentiation: What makes this product different from the status quo or the competition or both?
After you have a good grasp of the product’s objective, create a first draft of your vision statement.
You can find many templates for a product vision statement. For an excellent guide to defining the overall product vision, see Crossing the Chasm, by Geoffrey Moore (published by HarperCollins), which focuses on how to bridge the gap (chasm) between early adopters of new technologies and the majority who follow.
The adoption of any new product is a gamble. Will users like the product? Will the market take to the product? Will there be an adequate return on investment for developing the product? In Crossing the Chasm, Moore describes how early adopters are driven by vision, whereas the majority are skeptical of visionaries and interested in down-to-earth issues of quality, product maintenance, and longevity.
Return on investment, or ROI, is the benefit or value a company gets from paying for something. ROI can be quantitative, such as the additional money ABC Products makes from selling widgets online after investing in a new website.
ROI can also be something intangible, such as better customer satisfaction for XYZ Bank customers who use the bank’s new mobile banking application. By creating your vision statement, you help convey your product’s quality, maintenance needs, and longevity. we construct a template based on Moore’s approach to more explicitly connect the product to the company’s strategies. If you use this template for your product vision statement, it will stand the test of time as your product goes from early adoption to mainstream usage.
One way to make your product vision statement more compelling is to write it in the present tense as if the product already exists. Using the present tense helps readers imagine the product in use. As you can see, a vision statement identifies a future state for the product when the product reaches completion. The vision focuses on the conditions that should exist when the product is complete.
Step 3 Validating and revising the vision statement
After you draft your vision statement, review it against the following quality checklist:
Is this vision statement clear, focused, and written for an internal audience?
Does the state provide a compelling description of how the product meets customer needs?
Does the vision describe the best possible outcome?
Is the business objective specific enough that the goal is achievable?
Does the statement deliver value that is consistent with corporate strategies and goals?
Is the product vision statement compelling?
Is the vision concise?
These yes-or-no questions will help you determine whether your vision statement is thorough and clear. If any answers are no, revise the vision statement. When all answers are yes, move on to reviewing the statement with others, including the following:
Project stakeholders: The stakeholders will be able to identify that the vision statement includes everything the product should accomplish.
Your development team: The team, because it will create the product, must understand what the product needs to accomplish.
Scrum master: A strong understanding of the product will help the scrum master remove roadblocks and ensure that the development team is on the right path later in the project.
Agile mentor: Share the vision statement with your agile mentor, if you have one. The agile mentor is independent of the organization and can provide an external perspective, qualities that can make for a great objective voice.
See whether others think the vision statement is clear and delivers the message you want to convey. Review and revise the vision statement until the project stakeholders, the development team, and the scrum masterfully understands the statement. At this stage of your project, you might not have a development team or scrum master. After you form a scrum team, be sure to review the vision statement with it.
Step 4 Finalizing the vision statement
After you finish revising the vision statement, make sure your development team, scrum master, and stakeholders have the final copy. You might even put a copy on the wall in the scrum team’s work area, where you can see it every day. You will refer to the vision statement throughout the life of the project.
If your project is more than a year long, you may want to revisit the vision statement. We like to review the product vision statement at least once a year to make sure the product reflects the marketplace and supports any changes in the company's needs. Because the vision statement is the long-term boundary of the project, the project should end when the vision is no longer viable.
The product owner owns the product vision statement and is responsible for its preparation and communication across the organization. The product vision sets expectations for stakeholders and helps the development team stay focused on the goal. Congratulations. You’ve just completed the first stage in your agile project. Now it’s time to create a product roadmap.
Creating a Product Roadmap
The product roadmap, stage 2 in the Roadmap to Value, is an overall view of the product’s requirements and a valuable tool for planning and organizing the journey of product development. Use the product roadmap to categorize requirements, prioritize them, identify gaps and dependencies, and determine a timetable for releasing to the customer.
As he or she does with the product vision statement, the product owner creates the product roadmap, with help from the development team and stakeholders. The development team participates to a greater degree than it did during the creation of the vision statement.
Keep in mind that you will refine requirements and effort estimates throughout the project. In the product roadmap phase, it’s okay for your requirements, estimates, and time frames to be at a very high level. To create your product roadmap, you do the following:
1. Identify stakeholders.
2. Establish product requirements and add them to the roadmap.
3. Arrange product requirements based on values, risks, and dependencies.
4. Estimate the development effort at a high level and prioritize the product’s requirements.
5. Determine high-level time frames for releasing groups of functionality to the customer.
Because priorities can change, expect to update your product roadmap throughout the project. We like to update the product roadmap at least twice a year. Your product roadmap can be as simple as sticky notes arranged on a whiteboard, which makes updates as easy as moving a sticky note from one section of the whiteboard to another.
You use the product roadmap to plan releases — stage 3 in the Roadmap to Value. Releases are groups of usable product functionality that you release to customers to gather real-world feedback and to generate a return on investment.
The following section details the steps to create a product roadmap.
When initially establishing the product vision, it’s likely you will have identified only a few key stakeholders who are available to provide high-level feedback. At the product roadmap stage, you put more context to the product vision and identify how you achieve the vision, which gives more insight into who will have a stake in your project.
This is the time to engage with existing and newly identified stakeholders to gather feedback on the functionality you want to implement to achieve the vision, you’ll want to engage more than just the scrum team, project sponsor, and obvious users. Consider including the following people:
Your customers need to know about your product, and that’s what the marketing department provides. They need to understand your plans, and may have input into the order in which you release functionality to the market, based on their experience and research.
Customer service department:
Once your product is in the market, how will it be supported? Specific roadmap items might identify the person you’ll need to prepare for support. For instance, a product owner may not see much value in plugging in a live online chat feature, but a customer service manager may see it differently because his or her representatives can handle simultaneously only one phone call but as many as six chat sessions.
Make sure that the sales team members see the product so that they start selling the same thing you are building. Like the marketing department, the sales department will have first-hand knowledge about what your customers are looking for.
Especially if you’re in a highly regulated industry, review your roadmap with legal counsel as early as possible to make sure you haven’t missed anything that could put your project at risk if discovered later in the project.
While identifying features on your roadmap, you may discover additional people who will find value in what you will create. Give them a chance to review your roadmap to validate your assumptions.
Step 2 Establishing product requirements
The second step in creating a product roadmap is to identify or define, the different requirements for your product. When you first create your product roadmap, you typically start with large, high-level requirements. The requirements on your product roadmap will most likely be at two different levels: themes and features.
Themes are logical groups of features and requirements at their highest levels. Features are parts of the product at a very high level and describe a new capability the customer will have once the feature is complete.
Step 3 Arranging product features
After you identify your product features, you work with the stakeholders to group them into themes — common, logical groups of features. A stakeholder meeting works well for grouping features, just like it works for creating requirements. You can group features by usage flow, technical similarity, or business need.
Visualizing themes and features on your roadmap allows you to assign business value and risks associated with each feature relative to others. The product owner, along with the development team and stakeholders, can also identify dependencies between features, locate any gaps, and prioritize the order in which each feature should be developed based on each of these factors.
Here are questions to consider when grouping and ordering your requirements:
How would customers use our product?
If we offered this proposed feature, what else would customers need to do?
What else might they want to do?
Can the development team identify technical affinities or dependencies?
Step 4 Estimating efforts and ordering requirements
You’ve identified your product requirements and arranged those requirements into logical groups. Next, you estimate and prioritize the requirements. Here are a few terms you need to be familiar with: Effort is the ease or difficulty of creating functionality from a particular requirement.
An estimate, as a noun, can be the number or description you use to express the estimated effort of a requirement.
Estimating a requirement, as a verb, means to come up with an approximate idea of how easy or hard (how much effort) that requirement will be to create.
Ordering, or prioritizing, a requirement means to determine that requirement’s value and risk in relation to other requirements, and in what order you will implement them. Value means how beneficial a product requirement might be to the organization creating that product. Risk refers to the negative effect a requirement can have on the project. You can estimate and prioritize requirements at any level, from themes and features down to single user stories.
Prioritizing requirements is really about ordering them. You can find various methods — many of them complicated — for determining the priority of product backlog items. We keep things simple by creating an ordered to-do list of product backlog items, based on business value, risk, and effort, listed in the order in which you will implement them. Forcing an order requires making a priority decision for every requirement relative to every other requirement.
A scrum team can work on one thing at a time, so it is important to format your product roadmap accordingly. To score your requirements, you work with two different groups of people: The development team determines the effort to implement the functionality for each requirement. The product owner, with support from the stakeholders, determines the value and risk of the requirement to the customer and the business.
To order requirements, the development team must first estimate the effort for each requirement relative to all other requirements. we show you relative estimation techniques that agile teams use to accurately estimate effort. Traditional estimation methods aim for precision by using absolute time estimates at every level of the project schedule, whether the team is working on the work items today or two years from now.
This practice gives non-agile teams a false sense of precision and isn’t accurate in reality (as thousands of failed projects prove). How could you possibly know what each team member will be working on six months from now, and how long it will take to do that work when you are just starting to learn about the project at the beginning?
Relative estimating is a self-correcting mechanism that allows agile teams to be more accurate because it’s much easier to be right when comparing one requirement against another and determining whether one is bigger than another, and by roughly how much.
To order your requirements, you also want to know any dependencies. Dependencies mean that one requirement is a predecessor for another requirement. For example, if you were to have an application that needs someone to log in with a username and password, the requirement for creating the username would be a dependency for the requirement for creating the password, because you generally need a username to set up a password.
Assessing business value and risk
Together with stakeholders, the product owner identifies the highest business value items (either high potential ROI or other perceived value to the end customer), as well as those items with high negative impact on the project if unresolved. Similar to effort estimates, values or risks can be assigned to each product road-map item.
For example, you might assign a value using monetary ROI amounts or, for an internally used product, assign value or risk by using high, medium, or low.
The effort, business value, and risk estimates inform the product owner’s prioritization decisions for each requirement. The highest value and risk items should be at the top of the product roadmap. High-risk items should be explored and implemented first to avoid rear-loading the project’s risk.
If a high-risk item will cause a project to fail (an issue that cannot be resolved), agile teams learn about it early. If a project is going to fail, you want to fail early, fail cheap, and move on to a new project that has value. In that sense, a failure is a form of success for an agile team.
After you have your value, risk, and effort estimates, you can determine the relative priority, or order, of each requirement. A requirement with high value or high risk (or both) and low effort will have a high relative priority. The product owner might order this item at the top of the roadmap. A requirement with low value or low risk (or both) and high effort will have a lower relative priority.
This item will likely end up toward the bottom of the roadmap. Relative priority is only a tool to help the product owner make decisions and prioritize requirements. It isn’t a mathematical universe that you must follow. Make sure your tools help rather than hinder.
To determine the overall priority for your requirements, answer the following questions.
What is the relative priority of the requirement?
What are the prerequisites for any requirement?
What set of requirements belong together and will constitute a solid set of functionality you can release to the customer?
Using the answers to these questions, you can place the highest-priority requirements first in the product roadmap. When you’ve finished prioritizing your requirements, Your prioritized list of requirements is called a product backlog. Your product backlog is an important agile document, or artifact. You use this backlog throughout your entire project. With a product backlog in hand, you can start adding target releases to your product roadmap.
Step 5 Determining high-level time frames
When you create your product roadmap, your time frames for releasing product requirements are at a very high level. For the initial roadmap, choose a logical time increment for your projects, such as a certain number of days, weeks, months, quarters (three-month periods), or even larger increments. Using both the requirement and the priority, you can add requirements to each increment of time.
Creating a product roadmap might seem like a lot of work, but after you get the hang of it, you can create one in a short time. Some scrum teams can create a product vision, a product roadmap, and a release plan and be ready to start their sprint in as little as one day! To begin developing the product, you need only enough requirements for your first sprint. You can determine the rest as the project progresses.
Saving your work
Up until now, you could do all your roadmap planning with whiteboards and sticky notes. After your first full draft is complete, however, save the product roadmap, especially if you need to share the roadmap with remote stakeholders or development team members. You could take a photo of your sticky notes and whiteboard, or you could type the information into a document and save it electronically.
You update the product roadmap throughout the project, as priorities change. For now, the contents of the first release should be clear — and that’s all you need to worry about at this stage.
Completing the Product Backlog
The product roadmap contains high-level features and some tentative release timelines. The requirements on your product roadmap are the first version of your product backlog.
The product backlog is the list of all requirements associated with the project. The product owner is responsible for creating and maintaining the product backlog by adding and prioritizing requirements. The scrum team uses the prioritized product backlog throughout the project to plan its work — like a streamlined project plan.
We also like to include the type of backlog item as well as the status. Scrum teams will work mainly on developing features as described in the words of the user (user stories). But there may be need for other types of product backlog items, such as overhead items (things the scrum team determines are needed but don’t contribute to the functionality), maintenance items (design improvements that need to be done to the product or system but don’t directly increase value to the customer), or improvement items (action items for process improvements identified in the sprint retrospective).
Start Your Agile Project Right
Projects need direction, too. Project teams—for all projects—need to know where they are headed and when they are done. This business of selecting the direction for a project and knowing when the project is done is part of starting the project right.
Let’s talk about products for a minute. Every product has an introduction, several releases, and an end of life, when you retire the product. Every single one of those major events for a product is a project. When you introduce a product as “1.0,” that’s the introduction. You might have 1.5 as a minor release project and 2.0 as a major release project. Notice that I called them both projects.
Because the team can deliver value all the way through the project, sometimes people don’t think they have projects in agile approaches. They do. Here’s the key: when teams use agile approaches, you don’t have to wait until the end of the release to see the value in the project. Your team might be able to release every day, or every couple of weeks, or every month. Those releases allow the customers to receive interim value for the project.
Also, notice that I spoke about major and minor releases and our ability to release value. I am using the same word, release, in two different ways. That’s part of the problem. Agile approaches allow us to release interim value as often as possible to our customers. And you still have projects you might call “Release 1.0,” which is the project name for a product.
Thinking about projects can be especially important if you have a product with hardware. You might have production stages at the end of the project. And you can still have an agile project with hardware and mechanical parts or products.
In this blog, I’ll discuss how you can start your project right, including understanding your context and risks. First, we’ll examine why chartering a project is an important first step in starting a project right.
Charter Your Project
Every project needs a charter. Charters tell the team members why they are delivering this set of features (the vision) and how they know they are done with the project (the release criteria).
To start a project right, charter the project.
A project charter creates boundaries for the project and answers these questions: Why are we doing this project? When will we be done? The project charter provides the team with a minimum set of data with which to start.
You might be accustomed to projecting charters that also address the risks, the test plan, the communication needs, and even more information. If you realize you need any of that information in your charter, add it. My question is this: Do you need that information to start?
I like to start a project with the project vision, the release criteria, and the first backlog. That’s all. I have a question I ask of all parts of an agile project:
How little can we do to satisfy our needs?
Notice that I do want to meet the organizational desires, and especially the customer needs. However, I want to make sure we are not delivering more than we need to for this project.
I apply this “how little” thinking to everything: the backlog, the feature sets, and especially any up-front work. I want to see the product evolve rather than plan for how the product will evolve.
I often ask the team to help write the charter, and I generally timebox this chartering effort to one hour. The team has a chance to coalesce around the project and learn a little about what it’s like to work together.
The two parts I start with are the project vision and the release criteria.
Write the Project Vision
The project vision is a one-to-three-line statement of what the product manager wants the project to fulfill with this release. The vision guides the team and the product owner when they need to make decisions about what goes into this project and what doesn’t.
I’ve certainly used project visions like this:
Release 4.1 improves performance in these three scenarios by a minimum of 10%.
Release 2.0 adds email functionality.
Release 6.0 changes the UI across the product to our new standard.
Those visions are useful. They are not compelling. Here is another way to think about the project vision:
Who is the main recipient of the project’s outcome?
What can the main recipient do with that outcome?
What is the value to the main recipient?
When you think about the vision in this way, you might discover a compelling reason for the project.
I’d never thought about our users before. Oh, I thought about them during the project when we worked on the features, but I hadn’t thought of them when it came time to create a project vision.
We had a project that was mandated by the government. Customers with retirement accounts over a certain age had to move to a new account by the end of the year. If they didn’t, we would have regulatory problems. Our customers might lose some of their money, too.
When we wrote the vision first, it was something like, “Move from this kind of retirement accounts to that kind of accounts by October 15.” Big yawn. Then, we thought it might be, “Help all the retired people move their money by Sept. 30” or some such. It was fine, but not compelling. Then one of the junior people on the team piped up and said, “Hey, what we’re really doing is saving all the retired people’s money from the tax man.”
You should have seen the energy in the room. All of a sudden, we had a bunch of energized people. We had found our compelling vision: Save retired people’s money. It wasn’t about the bank. It was about our customers. We couldn’t wait to start.
Thinking about the vision this way makes sense for customers outside the product-development team. What if you have a project for the product-development team? It’s the same idea.
It’s possible you’re working on a legacy product. That product does not have enough test automation or the build is quite slow. Before you used agile approaches, it didn’t matter, because you didn’t build and test multiple times a day. Now it does. You have a project to address that problem.
Your vision might be something like this:
Increase our test automation so we can run unit tests in seconds after a build and system tests in minutes after a build. or Decrease the time for each build to no more than five minutes. This will save each of us at least 10 hours a week.
When you think about what your customers will be able to do with the outcome of your project, you may discover a quite compelling vision.
Develop the Release Criteria
Release criteria tell you what “done” means for the entire project. They tell you if you have met the project goals. Agile projects release value during the project. Release criteria tell you not when you can release value, but when you can complete the project.
You might say, “We can end when there is no more value in the backlog.” That might be correct. However, you don’t need to “finish” this product in this project. Product managers and product owners often find that the customers receive more value when the customers can use the product and then provide more feedback to the organization.
Instead of focusing on having no more value in the backlog, define several criteria so you know when you have met the vision. The following table outlines examples of release criteria.
I have used preset or preloadable databases and other automation approaches to be able to verify the release criteria as the team works through the project. Sometimes the team achieves the release criteria earlier than you expected. You have enough functionality to stop this project and start another.
If you are accustomed to making decisions based on the “goodness” of the product, consider using release criteria instead. You may discover you can release earlier than you thought.
Charter the Project as a Team
You might have created a project charter or project plans or architecture frameworks working alone in previous projects. Don’t do that when you start an agile project. The team needs to own the project charter or plan and any experiments to understand the design and architecture.
You may have heard of “Iteration Zero” in your agile reading. That is supposed to be an iteration of project definition and product exploration. Don’t do that either. Otherwise, you’ll fall into the Trap: Iteration Zero.
Instead, workshop the project charter with the team. If you’re creating the vision and release criteria, timebox that workshop to one hour. Yes, I called it a workshop, not a meeting. You are creating value, and not leaving any action items for the future, so it’s a workshop. If you need to explore the architecture before you start the project, ask the team to swarm around several features. That helps the team learn to work together and provides you with completed features. Sure, you might have to refactor them later, and that’s fine.
Identify Your Product Type
Projects allow you to organize a team of people around managing the risks to create and release the product. I am using the word product purposefully here. You may be accustomed to using the words release or system or application.
Those words describe how the customers will use the product. However, if you have customers and you want to use an agile approach, consider thinking about products. That word will help you think in an agile way about everything.
Products have customers. Products are the result of a product-development team’s work. You will release products. You can decide if there is more value in releasing a product now or waiting until later based on what the company wants and the customers need.
The product is a useful word, especially in the context of agile approaches. Thinking about “product” helps you focus on who will use your product and how you will help those customers receive the product.
How often could you release your product? Thinking about how the organization releases the product helps the team start with the end in mind.
Every decision would be easier if there were just two kinds of products: those that released continuously, as in software as a service, and those that released infrequently, as in hardware. However, you might be in an organization where —for any number of reasons—it’s difficult and/or costly to release often.
If your product is totally digital or software as a service, you could release continuously because the cost of a release is low—or could be low. That’s because if you can get to frictionless releasing, you only have to worry if there is a business decision for releasing.
If your product has hardware or mechanical components for the product, the cost of a release is high. You would not release as often as several times a day. I doubt you would release the entire product even monthly. You might release internally often—and use release criteria to know when the cost of a release is worth it to the organization.
You might find that you have a better idea of the overall project risks when you consider how the product could release, not necessarily how it releases now. Our customers are in a regulated industry. They need to do their checks on our product. Sometimes they integrate our product with other vendors in their environment.
They only want the product once a year. Of course, they want fixes to problems ASAP. For the product, it feels like “hurry up and wait.” For the fixes, I get a call from my CEO and their CEO and other people if we don’t release a fix in a day or so.
We use agile so we can release whenever we want. That includes fixes.
It took us a while—about eight months—to get to the point where we could release a fix in a day. The team—whichever team it is—swarms on the problem. We have enough test automation and our builds are fast enough that the team can iterate on possibilities and test them to know they will satisfy our customers. Or the team can involve the customer with up to three potential fixes.
I made the deliberate decision to invest in our capabilities, the build, and test automation, so we could release what we want, whenever we want. We now have frictionless releasing. We release the product once a year, down from 18 months. I suspect we’ll get down to six months in the next year. And we release fixes whenever we want.
Assess Your Project’s Risks
Projects have risks. That’s because you cannot manage the work with a checklist. Your project is more complex than a checklist. Your project will have risks with how the team thinks about the domain and solves the problems: technical risks. In addition, your team might have other risks, especially in the areas of scope, cost, people, and schedule.
Every project, including agile projects, has risks. I use the following pyramid to consider the risks for my project. I find that there are inside-the-project risks and outside-the-project risks.
When projects start, management often wants to fix the outside of the pyramid: the project cost, the project environment, and the people and their capabilities. Inside those constraints, the project can deliver some number of features, with some expected defect levels in some time.
In reality, the project team can change almost any of these. I bet you’ve seen projects where management decided it was okay to spend more money to deliver more features. I bet you’ve also seen projects where you started with not quite enough people and you managed to get more people on the project.
Since we expect to change the feature set with agile approaches, you may have more flexibility than you realize with the feature set and the date. I’ve seen agile projects end much earlier than anyone expected because they had completed enough features for now and had no WIP.
You might have risks from Avoid Management Mayhem. One way to assess your potential risks is to conduct a retrospective for work or a project these team members just completed. Their experiences (and yours) will help the team think about the risks they want to review and manage.
Consider asking the team how it wants to manage risks. Sometimes creating a board of the top 10 risks and managing those risks during problem-solving meetings or planning meetings might be enough. Consider a board of risks, impediments, and concerns that the team evaluates on a regular cadence. See Visualize Problems with a Board.
Start Architecture Thinking
You and your team might be accustomed to defining the architecture at the beginning of a project. In fact, there’s an acronym for that: BDUF, Big Design Up Front.
In agile approaches, we expect to evolve the architecture as the product proceeds. The team will add features, iterating over the feature set. The team builds, increments, and refactors the code and tests as it proceeds. Those activities help the team evolve the architecture. However, your team—and any architects your team might want to consult—can and should start thinking about the architecture.
There are several reasons to avoid having an architect hand down architecture for a project:
Architects need to be part of the collaborative team. Just as we still need project management for agile projects, we still need architectural thinking. Agile projects do not need an architect who is not part of the team. If the architect is not part of the team, the project will evolve and the architect will not understand the changes should the team require architectural assistance in the future.
I have yet to see a project where the architecture didn’t change as the team finished features.
Having architectural expertise on your team helps a team finish work faster. Architects can be servant leaders, coaching people to think about the effects of decisions. Architects can pair or mob with a team to show how to think about architectural qualities such as performance and reliability. I particularly like architectural spikes (not longer than one day) to experiment, scout, or may find in the problem domain.
When I work with people who are accustomed to starting with architecture, I ask them to draw a low-fidelity picture of the architecture they think will work. I ask them to update the image of the architecture as the team progresses.
If I work with an architect who needs to define the architecture at the beginning, I ask that person to explain three things that might go wrong with the architecture. I have found that architects who cannot think of three (or more) things that can go wrong don’t understand the entire problem well enough. They are not sufficient for my team.
I have been able to remove those insufficient architects from my teams. If you have a manager who wants to impose an architect on your team, remind that manager that Teams Manage Their Own Membership.
Recognize Project-Startup Traps
As a leader, you have direct control over avoiding these traps:
The team starts with Iteration Zero to define the project.
The organization wants detailed planning for the entire project before it starts.
As the team starts the project, be aware of these traps and avoid them.
Trap: Iteration Zero
Some teams learned or thought they needed an entire iteration of planning or architecture or estimation for the entire project. I’ve actually seen teams fall into “Iteration Minus One,” “Iteration Minus Two,” “Iteration Minus Three,” and so on.
For example, one team had trouble starting because it had always defined the architecture at the beginning. The team was faced with a new product and management wanted an estimate. The team spent Iteration Zero developing an architecture, and Iteration Minus One developing an estimate. That changed the architecture so the team spent Iteration Minus Two redoing the original architecture. The team was ready to estimate again.
A manager familiar with agile approaches stopped by and asked to see the team’s walking skeleton. When she realized the team had been planning and estimating, she asked it to create one specific feature for her to see the next day.
The team did and was surprised by three things: it needed to change the architecture again, it could complete a feature in one day, and the estimates it had prepared had no relationship to reality.
The manager helped the team realize it had fallen into Big Design Up Front and a phased approach to the project. The team continued to work on one feature at a time at the start of the project to see what the team could deliver and to have some idea of the accuracy of the team’s estimate.
Instead, consider these possibilities:
Spend up to half a day creating a list of experiments so the team knows where to explore. Determine the hardware or other resources the team requires and start that effort. Ask the team if it can start on anything without those resources.
If the team wants to use iterations and has no idea how to estimate together, consider a one-week timebox so the team can learn to work together. Use that week to define several small stories and see how the team jells. If the team has no stories ready, consider a one-day workshop to generate stories small enough that the team can work on them and the product owner can generate more stories.
Ask yourself the “how little” question applied to start: How little can we do as a team to get ready so we start delivering value?
Trap: Your Organization Wants Detailed Project Plans
In waterfall (and some other kinds of projects), organizations try to optimize everyone’s “efficiency.” (See Managers Move from Resource-Efficiency to Flow-Efficiency Thinking.) To organize the project and to utilize everyone, “efficient” projects need detailed plans: communication plans and often Gantt charts.
You don’t need those plans when you use agile approaches. When organizations use agile and lean thinking, the project has a fully formed cross-functional, collaborative team able to deliver value on a regular basis. That team doesn’t need a communication plan.
The team might have to provide status in some way to others in the organization. I have suggestions for that in blog 14, Report Your Project State. However, you don’t need any other plans.
The team doesn’t need Gantt charts. Gantts mean nothing to an agile team. What people need to see is the initial product roadmap and the rolling-wave deliverables as the team completes the work. If your organization wants detailed project plans, ask about the value it receives for these deliverables. Instead of writing plans, show demos of the product. If your organization wants detailed plans for milestones, show the product roadmap.
If managers in your organization send you mixed messages, such as “Give us all the old measures and work in an agile way,” you have major impediments to a successful agile transformation. Consider how you will help people see the new measurements that provide value. You might have to meet people where they are.
Agile Estimation: The Good, The Bad, and The Ugly
Estimation is about setting expectations. When I drive somewhere, I want to know how long I should expect that drive to take. You might say, “It will take me about 30 minutes to get from Point A to Point B.” That’s because you know from experience that it should only take you 20 minutes. And depending on road and weather conditions, it might take you closer to 40 minutes. You split the difference and call it 30 minutes.
That’s a gross estimate, an order-of-magnitude estimate. That’s the kind of estimate your managers want when they ask you for an estimate. Those estimates are accurate, but not necessarily precise.
The team might need estimates, too. If people work alone, not pairing, swarming, or mobbing on the work, the project team needs to understand when this part of the work will be done so that each team member knows when to expect the work. That’s a more precise estimate.
Every team estimates differently from every other team. There are good reasons for that. Sometimes the team members are not stable, so the team has no idea who will work on the story. The team doesn’t know if it will have the necessary expertise to fly through the story or if it will be a slow slog.
Sometimes the team timeboxes an experiment (an MVE or a spike) and after that experiment, the team will know more about the feature set so it can assess the complexity of it. Sometimes the team doesn’t know about the complexity of the code base. While the feature seems straightforward, the last time someone touched this code was years ago and that person has since moved to Fiji and is enjoying an umbrella drink on the beach.
Teams can provide an accurate estimate if they understand their current reality (what the code looks like), their typical speed (velocity and/or cycle time), and how much work they think this feature will take. If anyone of those things is unknown, their estimates will not be accurate. In addition, if the team members are supposed to multitask on features or projects, their estimates cannot be accurate.
In this blog, I’ll discuss using velocity as a way to guide relative estimation, using cycle time to create rule-of-thumb estimates, and what a team could do if it chose not to estimate at all, the #NoEstimates movement.
First, understand the definition of velocity in agile approaches. Velocity is a rate of change coupled with a direction. Velocity is not acceleration.
Imagine you’re driving to an appointment 10 miles away. You drive the posted speed on the side streets, one velocity. As you enter a highway, you accelerate to achieve highway speed. As you continue to drive, you achieve a stable state: You get into a lane and maintain a constant speed, with any luck.
You stay stable with respect to the road and your direction. Your velocity stays the same—especially if you use your cruise control. The more steady the traffic and the more you use your cruise control, the more your velocity stays the same. You arrive at your destination at the time you expect to.
Now imagine these scenarios: the highway is gridlocked. You are not going to achieve your expected highway velocity. You will be late. Or imagine that it has just snowed three feet and it takes you more than twice the time you estimated just to get to the highway. You will not make your appointment on time.
That’s the problem with using velocity as a way to estimate. A team’s velocity depends on achieving a stable rate of completion, which often depends on a stable relative size of the story and the context in which the team works on that story. If the team is trying to estimate something inside the crufty code, even if the story is straightforward, the work will take the team longer. The team will have to create enough tests and possibly try some experiments before it can say it has solved the problem.
You can use velocity as a basis for estimation. Some teams are successful using velocity as a way to estimate, once they have achieved a stable rate of completion. That stable rate often takes six or seven iterations to achieve. Think of velocity as capacity. Your team can, on average, deliver some number of stories, some number of fixes, maybe something else. Velocity is not acceleration.
Learn to Estimate with Relative Sizing
If you have a new team or a team new to agile approaches, no one has any data about what they can do as a team. You may have been in this position before as a leader in your organization. Your managers may have asked you to estimate on behalf of the team.
Don’t estimate for the team or even think about committing it to any deliverables in an agile environment. The team is in charge of its own work. The team manages its work. The team manages its estimation.
However, there is something you can do. You can help the team estimate its work with relative sizing, even if the team members have never worked together and have no historical data.
Relative sizing uses two ideas to improve estimates: the team compares story sizes (points) against what it’s accomplished in the past (the relative part), and it estimates using the wisdom of the team as a form of Wideband Delphi estimation. As everyone comments on the story and as people suggest a relative size, the team gathers better data and can, therefore, develop a better estimate.
To effectively use relative sizing, first ask the product owner to create stories that are as small as the product owner can create. Make sure these stories are real user stories so the team can understand who will see the value in each story.
Ask the team to group the stories by size, from the smallest to the largest. Keep similar-size stories together. The entire team decides how large the stories are.
Assess the story sizes. Using the Fibonacci sequence (1, 2, 3, 5, 8, 13, and so on), assign all the smallest stories to the size 1 bucket. The next-sized stories are a 2 and the next area 3. Continue until the team agrees on the relative sizes of the stories.
Once the team agrees on the relative size, take the stories estimated as 2. Do all the 2 stories look like they’re about the same size? If so, now estimate the duration for the 2 stories.
If the team thinks all the 2 stories will take about 10 person-hours, you now know how long the 1 stories will take. Divide the duration for the 2 stories by 2 to derive the duration for the 1 stories. In this example, our 1 stories would take five hours. Ask yourself whether that makes sense. If so, you now have the factor to use to multiply against all the other relative sizings.
If you see you have stories larger than an 8, size up to 13 and then use 20, or 40 for very large efforts. (The reality is that no one understands the size of anything past 13, but we can use these numbers in a different way later.)
If you have stories larger than say, 8, the team has plenty of unknowns or thinks those stories are highly complex. Consider a spike first to break the task into smaller pieces.
Here are some guidelines that have helped teams in the past:
If a “1” is larger than a team-day, see if the team either has too-large stories or the team isn’t a feature team.
If the team regularly sizes stories as larger than 5, there could be several problems: the stories are too large; the team doesn’t understand the stories; there is no defined MVP, or the code is in terrible shape. Ask the team to discuss and address the root cause of larger stories. Ask the entire team to workshop the stories with the product owner and to see what it takes to get to a size of 1.
When teams create stories of size 1 (where 1 is a team-day or less time), the team knows several things:
The team can count the stories for the next estimation period and have confidence in what it can deliver.
The team can deliver at least one story every day.
The team has more confidence in its estimate, which reduces overall project risk.
The larger the number for the story, the greater the uncertainty the team has for the estimate.
Use Relative Estimation for Iteration-Based Estimates
If you use an iteration-based agile approach, your team will want to estimate what it can deliver for the next iteration. It can commit to what it can fit into an iteration.
To use relative estimation for iteration-based estimates, the product owner first creates the ranked backlog as described in Plan the Backlog. The team then estimates each story as a team. Some teams use planning poker cards. Those cards have the Fibonacci series of 1, 2, 3, 5, 8, 13, and whatever larger numbers the team needs to estimate its work.
Here’s the problem with relative estimation and deciding what a team can pull into an iteration: the larger the stories are (larger than a 1), the more uncertainty the team has about the work it can commit to for an iteration. Instead of more discussion around estimation, consider a workshop to create smaller stories or an additional backlog refinement meeting. See Create or Refine the Stories as Preparation for Future Work.
Large relative story sizes provide qualitative data: it’s possible the story is complex; the code might be craft or this story might be an entire feature set. The team might need to explore if it can create a more accurate estimate. See what you can do to help the product owner create stories of size 1 before the team has to estimate the story.
Count Stories Instead of Points
If you use an iteration-based agile approach, you will need some idea of how much work the team can commit to for an iteration. Some teams count story points and estimate the number of points they can deliver in an iteration.
Here’s a wild and crazy idea: instead of spending time estimating larger work, consider breaking apart those large stories into small, one-day stories. Here’s why: your customers buy and use features or feature sets. Your team releases features or feature sets. Why not estimate by feature?
One of the problems with large stories is that a team creates tasks to break apart the story. Too often, the team says, “We need a front end of this many points, a back end of this many points, and testing of that many points.”
That kind of estimation is a task-based estimation. Agile allows us to deliver features, which allows us to perform a deliverable-based estimation, a different kind of estimation.
When we estimate deliverables, we often realize that what we are thinking about—the deliverable—is too large. We have a one-, two- or even a three-week deliverable. In Predicting the Unpredictable, I said that the estimate can be off by the unit of estimation. That is, if you have a one-week estimate, you might be off by one week. That’s because you are not estimating the deliverable; you’re estimating work that gets you to the deliverable.
Story points can help a team learn what it can do in a certain amount of time. And I have seen teams try to convert story points to hours or days, and then fill in the tasks. Instead of deliverable-based estimation (the story), the team uses task-based estimation, interim work that might or might not be useful.
Instead of counting story points, count features or stories. Workshop the stories to be one-day stories, or decide to pair, swarm, or mob on large stories so the team maintains a high throughput and can count its stories. If your stories are larger than one day, use your cycle time for a feature to see how large the stories are.
Consider Cycle Time to Create More Accurate Estimates
I recommend that teams in transition to agile approaches measure their cycle time as described in Cycle Time Shows How Long Work Takes. Here’s why:
Cycle time helps a team see how large its stories really are.
Cycle time provides a team with a rough rule of thumb for quickly estimating a large number of stories.
Cycle time helps people see whether they tend to be optimistic or pessimistic estimators.
Here’s how you use cycle time for estimation:
1. Decide on a time period for your measurement. I recommend you consider two to four weeks for your initial measurement period. That time might provide you with enough information for your average cycle time.
2. As the team completes stories in this period, count the number of stories and measure how long each story took. You will have something like the following table.
The average cycle time helps you know the average duration of a story. Some of the stories will take longer and some will take less time. You can count the stories, multiply by the average cycle time, and have a reasonable estimate.
What if you see a cycle-time variance as shown in the table?
The average cycle time is 3.6 days, but the maximum is 8 days. Can you use cycle time for estimation? You can, but your confidence will be lower if you do.
Know the Purpose of Your Estimation
In agile approaches, we can use the team’s wisdom to create accurate estimates, up to a point. For me, the question is this: Who wants what kind of an estimate?
Your managers might need gross estimates to understand roughly when they could plan on having a feature set available, or when the project might end.
Your team might want to predict its capacity to understand how much it can bring into an iteration. If you use flow, you might not need to estimate anything. You might have to work with the product owner to explain how large you think a specific story is so the product owner can understand if the team’s historical cycle time is valid for this story.
If your team is willing to create stories of roughly the same size, you don’t need to estimate anything at all. You count the stories. Counting works even better when you have one-day stories.
I’m not talking about tasks. I’m talking about stories, value to a user of the product. In my experience, when a team starts counting stories, it realizes several beneficial side effects:
The team creates and accepts stories of roughly the same size.
The team creates stories that tend to become smaller over time, approaching one day or even less.
The entire team understands stories across the product.
Consider counting stories for your estimates.
Create Approximate Estimates for Management
Many managers are accustomed to thinking about when “all” the features will be done. That’s because they could not see the value from the project before the end. In agile projects, we can deliver value before the end of the project. As a project leader, consider how you can help your management see value before the end of the project. And ask what kind of an estimate your managers need.
If your managers want to know when it will “all” be done, check to see if they mean when they can start to release value to the customers. They might want to know when they can capitalize on the software. They might want to know when they can recognize revenue from sales or support. Show them the roadmap and explain how often the product owner will update the roadmap and when the team will know better.
If they still want to know when it will “all” be done, use the information you have to create an estimate with a percent confidence.
Here’s how to estimate “all” the features:
1. Ask the team to take all the details they know about the features in the roadmap.
2. Use whatever relative sizing approach you prefer.
3. Walk through the roadmap, estimating as you proceed. In addition, count the larger features. The larger the features, the more uncertainty you have in your estimate.
4. Add up your relative estimate (either points or cycle time). Add up the large features so you understand your confidence level.
Here’s how one team did this. It had three feature sets for which it had good detail on the stories. The team had two more feature sets for which it had almost no detail on the stories. Management wanted the team’s best estimate in two days. The table shows how it estimated.
This team had about a day for a one-point story, so it thought it might be 354 team-days. The team had an uncertainty of “Medium.” Here’s how it framed that to its managers:
“If we do ‘all’ of this work and nothing horrible happens, we think it will take us roughly 70 weeks and we only have about 50% confidence in that number. However, we can deliver interim value starting in the next two weeks. We will be able to update the estimate and the uncertainty at least as often as every couple of weeks. When would you like to know more?”
Estimate Support Work
Many teams provide support work for the product they’re working on now, or even for other products they worked on in the past. That means they have to manage interruptions. And if they work in iterations, they need to somehow estimate or leave room for support work.
Here’s one way to estimate support work:
For the next three iterations, measure the amount of support work the team does. Track the cycle time for the support work, regardless of what kind of a board you use.
At the end of three iterations, see if the cycle time clusters around some average or mean. You might have two different means: the relatively easy support items and the much more difficult items.
Now, leave room in the iteration for the number and type of support items you see from your history.
You might discover that support takes close to half the time in your iteration. If so, do some root-cause analysis. Does the team need to fix cruft in the code as it proceeds? Does the team need to add tests because it has insufficient tests due to having taken shortcuts?
One question I like to ask is: Do we need to fix this problem now or is it possible to package up several fixes and do them all at one time? Sometimes the answer is yes. If so, gather the problems and spend some team time fixing those areas of the code and tests so the team has more confidence in those areas.
Use Previous Data to Inform Your Next Estimate
All the way through this blog, I’ve suggested the team create and refine stories so each story is a team-day or less. When the team can manage that, it discovers that its throughput is high, and estimating the work is as simple as counting stories. However, your team might be learning how to create smaller stories or learning how to avoid multitasking. Your team’s stories take longer than one day.
If your team has stories larger than one team-day in duration, consider using previous data to inform your next estimates.
Here’s how to use the team’s current velocity to feed that information forward to your next estimate: Measure velocity for several iterations. Teams new to agile approaches often need six or seven iterations to discover their true capacity, their velocity.
Does your team have an upper and lower bound? If your team measures in story points, it may discover that it can do 37 points in one iteration, 54 points in the next, and 24 in the third. That team’s velocity is not stable. It might need to count feature story points separately from defect points, separately from changes. See Iteration Contents Show What the T
Once the team’s velocity settles down to +/- 10% in either features or story points, the team can check its current estimate against what it “typically” can do. In addition, if the team needs to estimate past the next iteration, it can use its average velocity to create a gross estimate. In the same way, a team can use velocity as a check against a future estimate, the team can use cycle time.
Aside from multitasking, avoid estimating too far into the future. Instead of estimation, agile approaches allow a team to provide a demonstration and ask if the project is done enough.
Consider the Value of No Estimates in Your Organization
It’s not clear that estimation is very helpful to many teams. Too often, the product owner wants to change the stories to provide more value. Or the team realizes that the story it thought was small is not small. Or the team gets into the code and realizes the code is a mess.
The consequence is that all the estimation the team did is useless. The team will work in a different order, or the estimates are off.
What if you worked without estimating, and instead worked by value? That’s the promise of the #NoEstimates philosophy.
Sometimes there’s value in estimates. You can provide a ballpark, an order of magnitude about how long this project or feature set will take. However, if you are working in an agile way and you have a team that is able to maintain a steady throughput of value, you might not need to estimate at all.
Imagine this scenario: the product owner creates stories either alone or with the team that takes one day or less for the team to complete. The team swarms or mobs on the stories, so everyone knows what they need to do and when. The team has no or very little WIP because it releases stories as they are finished.
In that case, what is the value of estimation? You might need to count the stories and see how many remain so you can see how many days are left in that feature set.
In a serial lifecycle, the team only releases value at the end of the project. With any luck, your team releases value at least every two weeks. The value of estimation changes when the team releases value that often.
You might no longer need estimates to provide the same service to your management.
Recognize Estimation Traps
Watch for these schedule games or estimation traps:
The team thinks experts who “sign up” for their own stories will help the team’s throughput.
Managers misunderstand the idea of velocity and use it as a target for the team to achieve.
Sometimes the team thinks it can do more—with no data behind that thinking.
Your organization wants your team to estimate the entire project before it starts delivering value.
You have options for managing these traps.
Trap: Experts Take Their Own Stories
Especially when teams start with agile approaches, they realize that they have specific expertise. Janet knows about the database schema; Dan knows about the middleware; Sharon knows the UI, and Steve can test anything you throw at him. The team finds it tempting to estimate as individuals and then to assign stories based on expertise.
When experts work alone, the team creates WIP, often substantial WIP. Instead of the team collaborating, swarming around one story at a time, each person tries to make progress alone. However, the people on the team need each other to make progress.
The problem is that the team can’t release features unless people collaborate. At the very least, a developer and a tester need to collaborate to finish a feature. Many teams have barely enough testers, so when experts take their own story, the team creates queues of work, delaying all the stories.
Consider these options:
Ask the team to estimate as a team, not only for each individual’s part. Possibly show the team the difference between resource efficiency and flow efficiency, as described in Managers Move from Resource-
Efficiency to Flow-Efficiency Thinking.
Ask the team to work as a team, as discussed in Swarm on the Work, or Mob on the Work. If it’s possible for the team to work (swarming or mobbing) for a two-week timebox without an estimate, it will have a better idea about how the team works together for the next estimate.
If the team members insist on reinforcing their expertise, make any delays visible, as discussed in Visualize Your Project’s Delays. Make sure to raise your concern at a retrospective.
When experts take their own story, they optimize for a single person and busyness. When team members take stories together, they optimize for working as a team and delivering results.
Trap: Double Your Velocity
This trap arises when someone—often a manager or project manager who doesn’t understand agile—wants to improve the team’s output. This is a classic misuse of velocity as a measurement.
Velocity is a way for teams to use their historical information to predict what they might be able to do for the next iteration. This is a way for teams to avoid a total SWAG (scientific wild tush guess) for their prediction.
Velocity is not a productivity metric for the team—or worse—for the individual. See Velocity Is a Capacity Measurement.
Here’s cynical answer #1: If you want to increase your velocity, the fastest and easiest way is to double the number of points you assign to your stories; that will double your velocity. It doesn’t change how many stories you actually finish in an iteration, but it will look like you’ve doubled your velocity.
Cynical answer #2: If you want to alleviate the pressure from someone, you can play this game, too. You can divide the stories into two parts: Story Part 1 and Story Part 2. With any luck, you are dividing your stories along reasonable lines so that you see business value from each part. If not, well, the stories are still small enough that you finish them quickly. You can also double the points for each part. You can recurse on this trick almost indefinitely.
Of course, when you randomly split stories like this you’re not splitting your stories so they help you deliver business value more often, which is what you really want to do when you split stories. But you are playing schedule games.
Now, here’s the real answer: To break this trap, ask your manager this question: “What result do you want? Is there something you are looking for aside from completing the project as quickly as possible?”
Explain that in agile approaches, you ask the team to work at a sustainable pace, providing business value frequently to stakeholders and asking for feedback. The team works at the best place for it. The team doesn’t move slowly by design—the team works hard. The team might encounter spaghetti code, or code and tests that haven’t been refactored, or code that appears to have side effects with no supporting tests. The team isn’t going slowly on purpose—it’s working at a pace that allows it to proceed without making big mistakes. What is the manager looking for?
In addition, remind the manager that team velocity is personal to a team, as hair color or eye color is to a person. As soon as you change team members, the velocity is likely to change. If you change the product domain, the velocity could change. It’s a measure of past behavior that is likely to predict future behavior. It’s not a guarantee.
Trap: We Can Do More
The team has created a stable velocity of 35 points per iteration. In some iterations, it can finish 37 points. In other iterations, it finishes 32 points. But as an average over the past six months, it finishes 35 points.
Someone thinks the team can and should do more. The team needs a “stretch” goal or some such nonsense. Stretch goals don’t belong in estimates. They don’t belong on agile teams, because the team’s velocity is based on a sustainable pace.
When teams create accurate estimates and meet those estimates, they understand how to work together and maintain their sustainable pace. Such teams maintain focus and code quality. They have the flexibility to refactor the code and tests as they proceed, to create the best product possible. These teams are not under stress to do “more” when that “more” is an unreasonable request.
If anyone on the team wants to try more points per iteration, help that person see his or her data now. Consider asking how this person will create an experiment. See what happens. Maybe this team member can do more if the stories are smaller.
On the other hand, if someone outside the team wants the team to do more, explain that velocity is not acceleration. If this person wants the team to do more, the only way is to reduce the story size (not create tasks, but reduce the story size) so the team increases its throughput.
Trap: We Need Detailed Estimates for “All” of It
Sometimes the product owner thinks the team must estimate the entire feature set even though the feature set is large and the team will deliver the features incrementally. (This is related to, but is the estimation side of, Trap: We Can’t Release
The larger the feature set, the more difficult it is to estimate all of it. Combine that with the ideas that the stories might change, and your team has a recipe for potential estimation disaster.
Consider these options:
As a leader, have a conversation with the product owner and ask that person what she or he needs. Is the product owner under pressure to provide a detailed or specific delivery date for that entire feature set? If so, ask if the team can work on only that feature set until it’s complete. Consider asking the team to swarm or mob on the first several features in the feature set so the team can learn as it proceeds.
Measure the cycle time for each feature as the team proceeds. It’s possible the later stories will take less time, but I have not always seen that.
Remind the people pressuring the team for the large estimate that the larger the thing the team estimates and the farther out that work is, the less accurate the estimate will be. Ask what these people want. They might want delivery as fast as possible. In that case, work with the product owner to make the stories as small as possible, and ask the product owner to rank all the stories in this feature set higher than any other story.
Create smaller deliverables, and demo them to the people who want the estimate for “all” of it. This shows the team and the person who wants the estimate of how the team is proceeding.
Consider using the graph Expected Value Over Time, here, to help the product owner (or the people pressuring the product owner) to assess value over the entire feature set. It’s possible the customers want the first few features now but could wait longer for other features.
Know What “Done” Means
What does “done” mean to your project? Here are some possibilities:
The project met its date or scope commitments (or, if you’re lucky, both), and there aren’t too many problems, so the organization ships the product. The project is done.
The project met its release criteria. The project is done and the organization ships the product. The project team is done. Someone else or another team packages the product in some way and releases the product later.
You might be accustomed to some rituals many nonagile projects use, such as “defect triage,” to decide on showstoppers. Or product managers or some other managers took a day and played the rapid-descoping-of-“mandatory”-requirements game because of the time. Or, one of my favorites, someone played the defect-promotion/demotion game at the end of the project. All of these games helped us feel better about the work, even if we didn’t make the work perfect.
With nonagile approaches, sometimes either a product manager or a senior manager will see a demo only the week before the project is supposed to end. That person may not like the way a feature works or looks. Or the team has so many defects, the managers say they can’t release. The project goes on and on and on….
Agile approaches provide us much more flexibility with seeing the value and releasing over the course of the project. I already talked about release criteria as being the definition of “done” for the project. (See Develop the Release Criteria.) But how does a team know the features are done? How does a team know that the interim value is ready for the customers to see and use?
Teams need to know what “done” means at the release level, for a feature set, and for a given story. That way, the team can always work toward being done at every level.
In this blog, I’ll talk about the different levels of what done might mean for your team. I’ll also discuss the problems when your team is not the final stop before the customer can see the finished work.
See the Different Levels of Done
You may have heard about “done,” “done-done,” and “done-done-done.” Let’s unpack those phrases.
People talk about “done” for a story being done. They use “done-done” for an iteration. They use “done-done-done” for a release. I don’t find that differentiation helpful. I want the product to be releasable at any time. I want no friction for releasing.
But what about when the product owner accepts the story? Is that some other form of doing? It depends on your board. If your board ends before the product owner accepts the story, you might call stories that the team thinks are done “done.” Once the product owner accepts the story, you might call those stories “done-done.” And if a story is accepted for a release, you might call that “done-done-done.”
I think all these “done”s are a bit overdone. One way to manage the done problem is to define the Done column of your board as follows:
The story meets the story-acceptance criteria. Consider adding acceptance criteria that discuss the larger environment for the story.
The story meets the team’s agreements for technical excellence.
The product owner has accepted the story.
If the story meets all these criteria, the story is really done.
Define Acceptance Criteria for Each Story
Let’s start at the micro level: how do you know when a team finishes a story? I want to know that the team met the acceptance criteria on the story and that the team met the working agreement on how it completes work.
For acceptance criteria, I like the Given-When-Then approach from behavior-driven development:
(Given) some context
(When) some action is carried out
(Then) you should see some set of observable consequences
This approach creates scenarios for a story. You might even use the number of scenarios as a guideline for how large the story is. For me, a guideline is four scenarios. Once I see more than four scenarios, I worry that the story isn’t small enough. (You might prefer a different number than my four.)
Define What “Done” Means as a Working Agreement
I have found it useful to address what “done” means for a story as a working agreement. Here are some possibilities your team might consider:
All the code is checked in.
There are automated unit tests.
There are automated system tests at the API level.
All the automated tests are checked in.
All the tests pass.
The documentation for the feature is complete.
There has been some sort of pairing or other eyes on the code and automated tests to prevent shortcuts.
Your team doesn’t have to like these. It may want something different. I find it helpful to specify what “done” means as a working agreement so no one takes shortcuts. If people think they need to take a shortcut, they can discuss the problem that requires them to take a shortcut.
Consider When You Can Release to Customers
Sometimes new-to-agile product owners wonder about releasing something that’s minimum. My opinion: when in doubt, release. Don’t release nonsense. Make sure the story is an entire story, an MVP or an MVE, but release as early as possible. You will see several benefits:
The more often you release, the more the team practices releasing safely.
The team will build tests so it doesn’t break anything.
The earlier the team releases, the faster it’s likely to receive feedback.
The team has less WIP in the form of partially complete feature sets.
Back in the Potential for Release Frequency graphics here, I suggested you locate your product on a continuum ranging from a totally digital product where the cost to release is quite low to a product with hardware where the cost to release is quite high. As a leader, can you move your product down toward the lower-cost-to-release part of the continuum? What would you have to do to the product to make that happen?
Understand When Customers Can Take Your Releases
As teams become more accustomed to agile approaches and they increase their throughput, some of their customers say, “We don’t want new software every day or week. We want new releases only once every six months.”
Customers might feel this way for any number of reasons:
They want to “certify” or run the new product through some quality checks before they roll it out to their customers or organization.
They have local changes that they have to integrate into your changes.
They want to reduce any potential disruption from any changes you made.
They might have more reasons. Regardless of what you think, they prefer to manage their integration of your product.
Consider thinking about releasing in several ways:
Internal releases, which we use internally to understand the product direction and for demonstrations.
Incrementally grown releases, which we use when we bring new customers onboard.
“Real” releases, which all customers take.
I like internal releases as often as we can make them reliable. I like to aim for at least one day. That might not be possible for your team to do yet, so ask them what they want to aim for.
You might have an incremental release once a month and a “real” release once a quarter or every six months, depending on when your customers will actually install it.
We had a difficult time demonstrating new features and fixes and releasing those features and fixes. Some customers wanted everything. Some customers we had to push and prod into taking new functionality every six months. But we want to onboard new customers more often than every six months. And we don’t want to have to fix problems in older code bases, either.
We came up with a scheme to manage our releasing. We demonstrate new features to whoever wants to see those features. We release every month and roll over existing customers every April and October. We coordinate with our customers to make sure they are ready for the rollovers. We maintain a list of fixes and incremental value in the “current” release so customers can see if it’s time for them to take it.
Oh, we didn’t get here all at once. We had to learn how to release often and how not to make mistakes. I coordinate the releases to our different customers and I am starting to help some of them update once a quarter. We had to work to become as close to mistake-free as possible. And our customers now see our quality is far superior to what it was.
Building a Product Toward “Real” Doneness
One of the problems of “done” is ensuring the product acts in a way that satisfies the customer. These are often called “nonfunctional” requirements. The product needs usability, some form of reliability, and possibly some forms of security and performance before the product is really done.
How do you move from acceptance criteria in the small (for a story or feature) and move toward the release? Here are several ways to do so:
Possible Scenarios for Release Criteria. Any error from the test will trigger the team to determine what occurred. If the team thinks the release criteria are at risk, maybe it can do some architectural exploration with automated tests to verify the performance.
Build the performance criteria as the product owner scales the story. If a story only has to work for 10 users, maybe the story doesn’t need performance criteria. Once the product owner scales the story to 100 or 1000 users, it’s time to add performance-acceptance criteria to that story.
Your team might have other ideas.
One team realized it needed to improve its search algorithm speed. The product owner and the team defined six common search scenarios. The testers created several automated tests for each scenario. The developers generated and coded several algorithms. They ran the tests against the algorithms on various datasets.
It took the team a week to gain enough information to know which algorithm to select and what the team might have to do to the database schema. The team experimented longer and finally improved the algorithm by 50%. It codified those tests into automated tests to run against each build. The team now knows if a build degrades its product.
Build those nonfunctional requirements into acceptance criteria for every story and into release criteria.
Recognize “Done” Traps
Teams might not realize they encounter “done” traps. Here are three I’ve seen too often in teams:
The team has no “done” criteria.
It “all” has to be done before any of it can be released.
The team requires “hardening” iterations or effort.
I’ve seen teams where these “done” traps prevent the team from releasing anything. Consider enlisting your leadership and your allies to help the team see what “done” means and how to release intermittent value.
Trap: The Team Has No Criteria for “Done”
In my experience, teams want to deliver value. Also in my experience, teams need to know what “done” means at various levels: for the story, for the iteration if the team works in iterations, for release, and for the project. If the team does not have working agreements or criteria for what “done” means, it will done-done-done everyone to death. “Oh, you meant done-done?”
Help the team create working agreements for what “done” means. Let’s abolish this notion of done-done-done once and for all.
Trap: We Can’t Release Anything Until It’s “All” Done
I’ve seen product owners and teams create double-binds for themselves: they can’t get feedback until they release something. And they can’t release anything until it’s “all” done. Their agile project has very few deliverables. The deliverables they have are quite large.
And the larger the deliverable, the more likely the team is to make mistakes or not quite deliver what the product owner or customer wants. The team becomes frustrated because it worked for a long time on this product. The customer or product owner is frustrated because that person isn’t getting any value until too late. It’s a mess.
As a leader, you can help the product owner create small stories. See Write Small Stories, for more details. Encourage the team to build a culture of experimentation so the team can try an MVE or an MVP to gain feedback as early as possible.
Trap: We Need to “Harden” the Product
Sometimes teams don’t realize that they have insufficient story-acceptance criteria. Or the team realizes at the end of an iteration or after some number of stories inflow that it didn’t really finish its work.
Teams that are new to agile approaches might not realize this not-doneness for a while. Some teams use the idea of a “hardening iteration” (this seems to occur more often in iterations than it does inflow) to finish the work they didn’t complete before.
Encourage the team to fix problems as soon as someone discovers them, especially if the work is not yet done. I don’t recommend a regular practice of hardening iterations.
If your team realizes it didn’t quite finish work it had previously marked as done, consider these options:
Conduct a retrospective to understand what happened. Make sure not to blame anyone. Do unearth the data that led to people making what they thought was the best possible decision at the time.
Watch any estimation efforts. Do people think they should forego or reduce testing to make a particular date or squeeze “more” into an iteration? This is another instance of “how much” thinking, which causes the team problems later. See if you can help everyone move to “how little” thinking instead.
Revisit the idea of what “done” means for working agreements, for stories, for releases. Does the team need to refine any criteria to achieve technical excellence in its work?
If a team has trouble achieving its done criteria, reduce the work: the size of the stories and the work in progress. If the team encounters the need to “harden” its work infrequently, maybe you can ignore it. But I see teams that use hardening iterations or hardening activities every few weeks. That defeats the idea of finishing work so you never have to touch it again. Be wary of any “finish later” activities.
Create or Refine the Stories as Preparation for Future Work
Teams that use flow might refine stories just in time to work on them.
There are several issues with planning the next set of stories for the team: the team often discovers valuable learning with its current set of stories; the product owner might hear from the product manager or support or customers about the stories the team released earlier, and the product owner might want to take advantage of more market knowledge.
Because the team finishes stories on a regular basis, the product owner continually plans and refines stories for the team. Sometimes the product owner can refine the stories alone, and sometimes not.
One way to refine stories so the entire team understands them is to use the Three Amigos approach. When teams use the Three Amigos, they split into triads of one developer, one tester, and one product owner or business analyst. The idea is that each person has a unique perspective on the possible story:
The developer thinks about how to implement the story.
The tester thinks about what can go wrong.
The product owner or business analyst thinks about what the customer or business wants to accomplish with this story.
The nice thing about all of these perspectives is that the three people discuss the story in its entirety. The more they discuss the story, the more they can clarify it. If they add acceptance criteria, especially in the form of Given-When-Then, the team is much more likely to understand the story.
Organize the Team’s Meetings
Sometimes people spend too much time in meetings. Remember that none of these meetings are serial status meetings, so each meeting should provide value to the product owner and the team.
Here is an approach to managing the time people spend in meetings:
If the team uses iterations, consider a standup during the day. I like just before lunch. Other people select 9 or 9:30 a.m. Avoid first thing in the morning because people’s commute time can vary every day. If the team swarms or mobs, the team might not need a standup.
Consider timeboxing the backlog planning meeting to one hour for a two-week timebox. If the team can’t get through everything in that meeting, consider retrospecting on what the product owner and the team bring to that meeting. It’s possible the team needs to workshop the stories with the product owner and limit what the product owner brings to a planning meeting.
Consider timeboxing any backlog-refinement work to one hour to prepare for the next set of backlog items.
Here’s how I recommend a team manage an iteration-based agile approach and meetings:
1. Start the iteration on a Wednesday after lunch.
2. Conduct the one-hour timeboxed planning meeting right after lunch. Start the iteration.
3. Consider standups every day just before lunch.
4. On the middle Wednesday, conduct a one-hour timeboxed refinement meeting in the morning.
5. On the last morning of the iteration, that next Wednesday, start a demo at 9 a.m.
6. Conduct a two-hour retrospective from 10 a.m. to noon. Break for lunch.
7. Start the next iteration after lunch.
I prefer starting and ending iterations in the middle of the week. I prefer Wednesday. Tuesday or Thursday can also work. The reason I prefer the middle of the week is so that people don’t work over the weekend to hurry up and finish their work for Monday. That prevents the team members from realizing what their real velocity or cycle time is.
A flow-based team might decide to
1. Walk the board as a team if the team doesn’t mob or swarm every day just before lunch.
2. Create a cadence for its backlog-refinement activities.
3. Create a cadence for its retrospective activities.
4. Decide on demos as part of its working agreements. For example, the team might demo every story as it’s completed. The team might demo the product to sponsors or customers on a cadence.
Consider timeboxing any planning or refinement meetings. If people don’t know exactly how long something will take or what it involves, it’s time for a spike. Learning can be just as valuable as delivering functionality, especially if you learn you don’t need to do any more work in this area for a while.
In agile approaches, we tend to have more meetings, touch points, about the work. These meetings are not serial status meetings. They are not for one person’s benefit—they are for the entire team. If your meetings become too long, timebox them and see what happens.
Measure the Value from Meetings
You, your team, and even your management might be worried about the number of meetings the team has. Part of the problem is that agile is a collaborative approach to product development. It’s possible no one has seen this kind of collaboration before. However, it might be worth seeing how much value your team gets from its meetings. In that case, consider measuring the return on time invested (ROTI).
Using a five-point scale similar to one shown in the following figure, ask people to report how much value they received for the time they invested in the meeting.
Post the ratings on a flip chart, and poll the group. Create a histogram that shows the results, as in the next figure.
Then ask for information about what made the meeting worthwhile or not worthwhile.
Ask the people who rated the meeting 2 or above what specifically they received for investing their time in the meeting.
Ask people who voted 1 or 0 what they wanted but didn’t receive for their investment.
Ask what to keep, drop, and add for the next similar meeting.
If a majority of the participants rate the meeting an even return for their time invested, a 2, the meeting is valuable.
If a majority of the participants rate the meeting below 2, ask more questions. Was there a match between the people and the purpose of the meeting? Was the meeting run well enough? Was there something else that prevented people from gaining enough value from the meeting?
Agile approaches do require more meetings than people might expect initially.
Make those meetings valuable.
Create Learning Opportunities
So far, we’ve discussed work-based meetings and opportunities to learn about the work. But that’s not enough for any team.
In addition to the work-based meetings, people need time to learn about the product domain, their craft, and how other people work across the organization. Here are some possibilities to create learning opportunities for the team.
Learn About the Organization and Customers
In my experience, it’s easy to learn who does what and learn about the customers and their challenges in a smaller organization. As the organization grows, people tend not to know who is in Marketing or Support or Sales. Yet the people in those departments might have great insight on the problems the customers want to be solved. They often know how little the team must do to solve those problems.
I happen to like lunch-and-learns, which help people learn about what’s happening in the rest of the organization and with the customers. I like a regular cadence of these meetings, where someone provides a brief informal talk and encourage questions and answers. Consider a cadence of once every two to four weeks for some informal learning.
Learn About Other Ways to Work
When I visit teams, I often discover they barely know the agile approach they’ve been trying to practice. Or that they never really learned it—they picked up terms from their friends and colleagues.
It’s possible your team could learn by osmosis, but one of the cheapest and fastest ways to learn is from a blog club. Ask the team what it wants to study —or offer suggestions—and create a ranked backlog of subjects. Then buy everyone on the team a copy of a blog that you think is useful for the team to study. Consider a blog a week as a regular cadence. Your team might get through three or four blogs a year together, at one blog a week.
Consider asking the team how it wants to learn. Maybe it prefers podcasts or some other medium.
Learn from Others Across the Organization in Communities of Practice
In one assessment, several technical people had the same concern: “Now that I work as a member of a cross-functional team, I don’t learn what my other developer/tester/writer colleagues are doing and how they are solving problems.”
Communities of practice help solve that problem. Architects, product owners, developers, testers, coaches—anyone involved in the cross-functional teams —need a community of practice to surface issues in teams and learn how others solved or approached those problems. Communities of practice also provide mentoring and coaching in a particular function and help people consider options for their work.
Recognize Meeting Traps
Meetings can fail in spectacular ways. However, in agile approaches I’ve most often seen these traps:
The standup becomes a serial status meeting.
The team meets instead of delivering finished work.
Team members don’t have enough time in retrospectives to identify possible solutions or experiments.
You have options for managing these traps.
Trap: Standups Become Serial Status Meetings
For years, project managers and other managers asked team members about their status on projects. However, agile approaches move from individual work to team-based work. That change can challenge everyone: team members, project managers, and other managers. In addition, if the team falls prey to Trap: Everyone Takes His or Her Own Story, or Trap: Experts Take Their Own Stories, or if the stories are too large, the standups will feel like serial status meetings.
If you ever hear (or if you’re tempted to ask), “Where are you with this story?” you know that the story is too large and people are not collaborating as a team.
You might say, “I’m nervous about the state of this story” and then explain why you are nervous. You can ask people for ideas to help you manage your nervousness.
Don’t ask people about their individual work. Your team might also create a working agreement about how long any one person can be stuck.
Trap: The Team Meets Rather than Delivers
Some agile teams have a difficult time delivering value. Their stories are too large. They have too much WIP. And they spend forever in meetings.
One way to manage those problems is to ask the product owner to create one story that the team will work on, all together. If the product owner can make that story small, that’s great. Even if not, ask the product owner to make the story as small as possible.
Next, have the team use Three Amigos—even if they all do it in parallel—to understand the story. Then it’s time to estimate. The team estimates the story, then swarms or mobs on the story until it’s done and meets the acceptance criteria the team defined in the Three Amigos activity.
Now the team has succeeded on one story. It might choose to retrospect on this work. Ask the team to do one more story in the same way: use Three Amigos, estimate, and deliver.
Once the team gets a few stories done (maybe just three), ask it to do a retrospective and see what was different about these stories.
Too many or too-long meetings are a sign that the team or the product owner is asking the team to take on too much ill-defined and too-large work. Once the team understands what is too large or insufficiently defined, it will be able to change what it does.
Trap: Insufficient Time in a Retrospective to Solve Problems
Retrospectives are terrific for identifying problems. Sometimes the team can solve the problems in a retrospective just by seeing the data. And sometimes the problem is buried deep in the team’s assumptions or work process. The retrospective time was sufficient to identify the problem. The team needs more time to solve the problem.
If you see your team struggling to solve a problem, consider suggesting a problem-solving meeting outside of the retrospective. You, as a leader, might facilitate this meeting. Or you might help by suggesting data the team can gather. Or you might not have a specific role except to make sure the meeting occurs with all the right people.
Some problems challenge the organization’s culture, some challenge the team’s data gathering, some require more time for root-cause analysis. Help your team see the problem and then create time to solve it.
Report Your Project State
For any project, people outside the project—often managers—want to know when we think it might be done. They might want to know how much it will cost so they can manage expenses. Sometimes managers want to know other things, such as several measures around the project pyramid, as illustrated earlier, here.
In this blog, we’ll work up from the team measures in the previous blog. I’ll explain what you can and might show your managers as project status as opposed to team measurements.
Your team has many ways to show its progress. Here are some possibilities:
Show a working product.
Provide feature charts to show what’s done, what’s added, and what remains.
Show the number of requests the team has received (and maybe what they are) in addition to work on its board.
Show what’s working but not yet released to customers.
Show different project measures that relate to the project’s progress.
Let’s start with showing the working product.
Show Working Product
The best way to show progress is to see the working product. That’s because your customers buy and use features. They don’t buy architectural progress or UI progress or any other kind of progress. They buy features and feature sets. If the team shows them finished features, the team and the managers/sponsors/customers build trust with each other.
Back in Create a Walking Skeleton, I suggested the product owner define and the team implement small vertical slices that help people see the minimum skeleton of the product. As the product owner decides what’s most important in the remainder of that feature set, the team implements it.
That process—implement small vertical slices around the product so people can see the intent—helps the managers (or sponsors or customers) see the team’s progress. The more these people can see progress, the easier it is for them to understand and trust that the project is progressing well.
How Managers Help Agile Teams
Your organization might have technical leaders, managers, directors, vice presidents, and so on. All those people are organizational leaders. They have titles and some sort of organizational power. I’m going to call those people “managers” as shorthand.
Regardless of your team’s project approach, you’ve seen managers who helped or hurt the team’s momentum. And many people who try to use agile approaches say, “We don’t need any managers in agile approaches.” Those people are mistaken.
Managers hold the key to creating an agile culture. Managers remove impediments that teams can’t remove. Managers make choices about removing or reinforcing these impediments all the time. Their choices create the culture for the organization. If you can help the managers see value in agile approaches, they’ll work to create a more agile culture. If no one can help the managers see the value in agile approaches, the teams won’t be able to sustain an agile culture.
Let’s see some possibilities for managers to help your cross-functional team thrive in its chosen agile approach.
Here are the primary areas in which managers can help the team become more effective with their agile approach:
Removing impediments the team cannot remove on its own.
Helping the team find or create its own workspace so the team can collaborate more easily.
Managing the project portfolio with flow-efficiency thinking so people work on one project as part of one team.
Helping HR understands how to transition to a team-based recognition and reward structure.
There are plenty of other actions managers might take to support agile approaches. For example, managers might help remove hierarchy by seeing if some people prefer to be technical leaders on teams instead of being managers removed from teams. Every organization I’ve consulted with has not enough product owners. Managers can offer people the role of product owner instead of the project manager or manager. With the creation of communities of practice, people might be interested in technical work.
Let’s start with looking at what managers might be able to do about four typical impediments:
Resolve problems the team can’t, especially systemic organizational problems.
Create team workspaces.
Manage the project portfolio.
Start the transition to a team-based recognition and reward structure.
Managers Resolve Impediments the Team Escalates
In Visualize Problems with a Board, there’s a column on the board called Waiting for External Decision. The team escalates to the team’s manager the problems it cannot resolve itself. (Yes, I am assuming every team has only one manager.)
Problems outside the team’s control are often systemic problems. If your organization requires either change-control requests or a deployment team, the project team cannot release its product when it is done. Sometimes the annual budgeting process eliminates the possibility of making product advances in the marketplace because this project was not supposed to do that. Sometimes the team doesn’t know enough about interpersonal skills or technical skills, so the manager can arrange for training.
Great managers start with this question: “What do I need to do to see a flow of value from this team?” If the manager optimizes for value flow, the manager will see what his or her role could be.
Managers Help Create the Workspace Your Team Needs
I mentioned the idea of a team room in Does the Team Needs a Team Room?. Ideally, every collocated team would have a physical location where the team can work together. That work might be swarming, walking the board, and creating and updating the team’s data.
When people work together, such as in pairs or mobs, they may find that being with other people all day exhausts them. Those people also need a private space where they can think quietly and recharge.
Managers have the title-based power in the organization to create the different spaces the team needs. Ask the team what kind of a space it would like to experiment with, and for how long it would like that space. Different teams need different kinds of spaces.
Seeing an Agile Team Work Convinced Me to Try Team Workspaces
My middle managers came to me with what I thought was a crazy request. They wanted the ability to collocate the team in one workspace. Oh, and yes, they wanted enough private spaces that people could go hide in a “cave”— that’s what they called it—for a while.
I’ve spent my entire career doing and managing software. I’d never seen this team workspace nonsense before. One of the managers, Sarah, asked me to spend an hour walking around, seeing what the team did.
First, I saw a standup at a board. Okay, I have to admit I was impressed when people stepped up and said they could help each other finish work. But they’re a team. What else would I expect?
Then I saw a pair—a developer/tester pair—working together to solve a problem. That was a bit of a surprise. What was even more surprising was the fact that they had to squish into his cube because she didn’t have enough room. Sarah and I spoke with them and that’s when the tester told me she liked to work from home because she had enough room there. I guess she told me.
I walked around and saw more people working in triads and even one quartet. I had been impressed with the team’s throughput. When I realized I could run interference with Facilities, I was all in. Especially if they keep this throughput up.
Not all teams need a large physical room. For example, if your team is geographically distributed—not collocated—the team might only need a board with a camera pointed at it. Teams that are not collocated might need personal cameras so people can see each other to know who’s interruptible. They might also need a variety of communication tools that help with immediate and not-immediate communication.
Managers Move from Resource-Efficiency to Flow-Efficiency Thinking
Too many managers were trained to think of “resources” as a term they can apply to people. They use terms such as “FTE,” which is a full-time equivalent. They think of productivity as if knowledge-work productivity can be measured with any kind of certainty. They think of percent utilization, which doesn’t make sense for collaboration.
Great managers knew the words and measures were wrong. And they often saw no alternatives. Agile culture provides many alternatives.
When managers think of people as “resources,” managers think they or the teams can split work to make people more efficient. We split this work by work type, creating experts.
When managers think they can ask a team to work on several projects at once, or see 100% utilization, or reinforce narrow expertise, managers are victims of resource-efficiency thinking. High utilization makes no sense for knowledge work. People need time to think and to innovate. One way to help people see the problems with resource efficiency is to Visualize Your Project’s Delays.
Instead of resource-efficiency thinking, explain to your management about flow efficiency, as illustrated in the figure. When we flow work through teams, we see the highest throughput. It doesn’t matter if we talk about features or projects. Flow efficiency allows us to finish work faster.
This kind of thinking has several implications for managers:
Managers need to manage the project portfolio to eliminate multitasking among projects.
Managers need to staff and retain stable cross-functional teams.
Managers need to look for throughput measures instead of utilization measures.
When managers don’t think about optimizing up for the team, the product, and the organization, they create management mayhem, as described in Avoid Management Mayhem. In management’s defense, too often the organization creates rewards that optimize for the individual, not the team, the product, or the organization.
One way to see if your organization is optimizing up is to see how many people try to control or direct the team’s work. In agile approaches, the product owner is the single person who directs and controls what the team does. If managers try to control “their” developers, testers, writers, whatever, the team can’t manage its work.
Those teams struggle to manage all their work because they are multitasking by a person instead of working as a team. Teams can’t depend on each other because managers move people around. Managers don’t realize what they are or are not measuring because they don’t understand agile measurement is different. Remember, Work as a Whole Team to Create the Product.
Agile is a human-centered approach to work. Retraining your management will take time. Ask your managers to consider what they want: surrogate measures that create an individual approach to work, or measurements that encourage collaboration and delivery?
If you can help your managers change one idea about their thinking, ask them to consider flow efficiency instead of resource efficiency. Help your managers see the delays and the cost of those delays with Visualize Your Project’s Delays.
Managers Help with Team-Based Recognition
One byproduct of moving from resource-efficiency thinking to flow-efficiency thinking is realizing that managers can change how the organization recognizes and rewards people. Instead of recognizing and rewarding individual performance, an agile culture recognizes and rewards team performance.
That’s a huge change.
Think about the agile team you are creating and working with. Can you tell the difference between people on the team? Is your team becoming a team of specializing generalists who help wherever the team needs them? If so, it’s time to rethink the recognition and reward system.
For years, I had a job that I hated. I was supposed to rank everyone in my organization. If I ranked everyone as a 5, HR would push back and tell me I couldn’t possibly have that many stars. I did, but they didn’t buy it. If I ranked everyone as a 3, I couldn’t get the money I wanted for raises. I felt stuck between a rock and a hard place.
Then we moved to agile in the form of flow. I gotta say, I was blown away when every team’s throughput increased because they now had WIP limits and they worked as teams. Blown away. What was I going to do about the compensation?
I brought HR around on what I called “a walking tour” so they could see how the teams worked. Sure, people were still developers and testers, but they gave each other feedback and coaching. They found and fixed problems before any of the managers could help.
And my managers? Wow, now they were coaching and giving feedback about the really difficult problems. We’d been doing flow for about 14 months, and everyone had stepped up their game. It was time to bring HR into the mix.
HR decided we could try giving teams a rank. I explained that ranking a team didn’t make sense either. Each team worked on different work. We had to stop with ranking people against each other and talk with them about their careers and what they wanted to do. You should have heard the “Oooh.” We’re experimenting with results-based approaches. We’re trying to create double-loop learning as an organization.
I wouldn’t say we have rewards and compensation totally knocked. Each manager sits with a person to create that person’s personal results in terms of her or his career. In addition, teams are responsible for results. We stopped ranking people last year, which makes everyone feel happy. We’re on a path to reasonableness, which is what anyone, including me, wants.
Agile is a team-based approach to work. Consider a team-based approach to recognition and rewards.
Avoid Management Mayhem
Managers have power in the organization. That means that managers can create mayhem without even realizing it.
Here are some common management-created problems for agile teams:
When managers yank people off or onto a team in the expectation that the team needs expertise
When managers don’t limit the work in progress for the organization by managing the project portfolio
When managers don’t realize that a team needs to be cross-functional, with all the capabilities and skills required to finish work
When managers blame people for work—done or not done
I had always worked in a culture of blame. I could swear all my managers came from the school of: “You do it, you own it. I don’t like it? I blame you.” I did the same thing with my managers and their teams.
I wanted to use agile approaches. I needed the features done and released. I kept managing the same way I had always managed. One day, four of my managers asked for a meeting. They said they were all going to leave if I didn’t change. What did I need to change? My blaming.
I talked to the first manager and she explained she was tired of working around me and trying to smooth things over when I had a screaming and blaming outburst in a meeting. She told me I never had “little” outbursts. She gave me feedback, as I now see.
The other managers gave me other examples. They were sick and tired of me. Me. Not the company. Me. My blaming had gotten out of hand and had changed my effectiveness as a manager. I didn’t think I could make things work without them. I told them that. They all smiled. That first manager told me she was happy I felt that way. They loved the product and their teams. I was the problem.
They taught me about feedback that day. I see now that they coached me. I am still a work in progress, but I’m working on my growth and agile mindsets. They haven’t quit and the teams started to really rock and roll after I started to learn how to manage. It’s as if all they needed was a little reasonableness at the top.
This blog is just the introduction to the idea of agile management. Even if your managers can do all of these things, that might not be enough to create and sustain your agile culture.
Recognize How Managers Can Help Agile Teams
In other blogs, I highlighted traps. I’m not highlighting traps here because it’s difficult enough being a manager. Instead, I’m suggesting three things managers can do to help agile teams:
Encourage collaborative work.
Help the team consider “how little” instead of “how much.” Optimize up wherever possible. These kinds of ideas help a manager continue to create an agile environment. Unless the entire organization is already steeped in the agile mindset, managers have an ongoing responsibility to support teams in their agile approaches.
How Managers Can Encourage Collaborative Work
Agile is not just a project approach, but a cultural shift. One major shift is to teamwork from individual work. An agile culture creates the ability for the manager to flow work through the team. And the manager can provide team-based recognition and rewards. Encourage your manager to manage the project portfolio, and flow just one project through a team. Encourage your manager to consider eliminating individual bonuses and work toward some form of team-based rewards.
How Managers Can Encourage “How Little” Thinking
In more traditional organizations, managers are accustomed to directing work. Sometimes they are accustomed to controlling what people do and how. Instead of saying, “Don’t do that,” consider asking the manager this question: “How little controlling or directing is it possible for you to do?”
Many managers are concerned with the effect of bad decisions and nonworking deliverables. You, as a servant leader, can help build trust first with your manager by helping the team deliver visible value, as often as possible. When managers see the team deliver value on a regular and sustained basis, they often start to think about other “how little” possibilities. Build trust with your manager by delivering value on a regular basis.
How Managers Can Help Optimize Up
Sometimes team members pull their hair out. They don’t have the opportunity to solve problems where the problems are. Instead, the problem goes up the hierarchy, over to another function, and down where the people can solve the problem. Then the solution traverses the hierarchy again.
One way managers can help the team succeed is to help everyone think “up” a level. If you can help a manager think in a “lean” way, starting with The Two Pillars of Lean, the manager will think about how to optimize the work for more value. Seeing the whole, eliminating waste, delivering as fast as possible—those ideas resonate with managers. You can help your manager see the whole by discussing how to optimize what the team delivers, not each individual person. Then, discuss what the department or product line delivers, not the teams.
You might wonder if agile approaches have jumped the shark—whether agile is past its prime.
Or maybe you or your managers thought agile approaches were merely a different project life cycle. Someone thought agile approaches were for teams only. No one thought the managers and the entire organization would need to change the culture. The transparency agile approaches bring is not what you had in mind.
You might have other concerns, such as no product owners for your teams. Or you might have too many managers who want to control what the teams do, threatening the teams’ move toward self-management.
Use this blog for ideas about what you can do. You might not be able to transform your team into an agile team, but here are two basic ideas that will help you deliver value faster: limiting work in progress and asking people to work as a cross-functional team. Try these ideas only if the team wants to do so. Do not impose agile approaches on any team. If you aren’t sure where to start, consider beginning with your work.
Limit the Work in Progress
One of the most powerful ideas in agile approaches is to limit what a team works on for now. Iteration-based agile approaches limit WIP by timeboxing the work. Flow-based agile approaches create explicit WIP limits.
When the team limits its work in some way, the team is more likely to finish the work it does. The team is more likely to use technical excellence as it completes work.
Consider creating a Kanban board so the team can see its flow. On that board, create WIP limits. Make sure the WIP limits are no higher than the number of people on the team, divided by two. That will force people to collaborate on a limited amount of work.
Ask People to Work as a Cross-Functional Team
Agile approaches create change across the organization. One of the biggest changes is that of cross-functional teams who have allegiance to their team and their product, not their manager. That can be scary for the team members and for management.
Managers might fear their loss of organizational power when agile approaches change the reporting structure. Managers often “lose” people who formerly reported to them. Managers might fear to be unable to pluck people from one project and push them onto another project to respond to an emergency.
Sometimes people don’t want to leave their functional silos. The architects enjoy a certain status and they don’t want to give it up. The developers or UX people or testers understand how to work now. How can they work as a cross-functional team?
My advice is to not reorganize first and change who people report to. Instead, leave the reporting structure alone and ask people to work as cross-functional teams. Help the team learn how to deliver value on a regular basis. The more the team can deliver value, the easier it will be for agile ideas to take hold.
Start with Yourself
Regardless of how your organization or team started with agile approaches, you can begin to create an agile culture by using the agile mindset yourself. Consider how you can use agile approaches in your work:
How can you be transparent about your work? Consider a personal kanban board with WIP limits.
How can you collaborate with the team and others? Consider when to bring other people into your work. Instead of writing a project charter alone, write it with the team, timeboxing the effort. Instead of having people ask you about the project’s status, create a transparent way to report status on a daily basis. Instead of removing project impediments alone, consider enlisting other project leaders across the organization to see if you can all collaborate.
How can you exhibit the growth mindset? Instead of being discouraged at setbacks, can you consider this an opportunity to learn early and create a better result?
People look up to their leadership. In your context, what can you do to use agile approaches as a person and as a team