Where Do Product Owners Come From?

People

A common challenge that we run into when working with organizations adopting Disciplined Agile strategies is helping them to identify and then coach people for the Product Owner (PO) role. This is often easier said than done due to the dearth of people with the required sill and mindset. In this blog we explore several strategies to address this challenge.

What Are You Looking for in a Product Owner?

Let’s begin with a review of the requirements for a good product owner:

  1. Analysis skills. POs need to be able to elicit requirements, explore them with stakeholders, negotiate priorities, facilitate modeling sessions, and in some cases document requirements.
  2. Decision-making authority. POs need to be empowered to prioritize the work of the team AND need to be comfortable with doing so.
  3. Good stakeholder contacts. POs need to know who to work with in the entire range of stakeholders, including both business and technical stakeholders.
  4. Full-time availability. This is a full time job, and at scale often proves to require more than a single person in the role (more on this in future blog postings). They’re available to the team on a daily basis.
  5. You want them in the position for several years. It takes time to grow an effective PO, depending on the background of the person we’ve seen people take between six and eighteen months to truly become comfortable in the role. This is a fairly large investment for your organization, so once you’ve made that investment its reasonable to want someone to stay in the role for at least a few years.
  6. They understand both your business domain and IT infrastructure. When taking a Disciplined Agile approach to product ownership the PO is responsible for representing all stakeholders, including both technical and business stakeholders. An implication of that is that POs should have a good understanding of the business domain and direction as well as your existing IT infrastructure and the direction that it’s going in. These understandings will be very important for prioritizing the work effectively.

Given the skill requirements it shouldn’t be surprising to anyone that there is a shortage of candidates for the PO role in most organizations. Let’s explore your options.

Potential Sources

There are several potential sources of new product owners. The following table compares and contrasts these options. As you can see there is no ideal option available to you, and the reality is that you will likely need to obtain PO candidates from whatever source you can find.

Potential Source Advantages Disadvantages
Business analyst
  • Strong analysis skills
  • May have a very good understanding of the overall business
  • Likely to have good stakeholder contacts
  • Likely available full time
  • May not have decision making authority nor be comfortable with it
  • May not have an understanding of the technical infrastructure
Business executive
  • Has decision making authority and experience
  • Likely has a good understanding of the business
  • Unlikely to have the time to be a product owner
  • Many only be focused on a single line of business (LoB)
  • Unlikely to have a sufficient understanding of the technical infrastructure
  • Unlikely to have good analysis skills
New hire
  • You can potentially hire someone with the requisite skills
  • Available full time
  • They are unlikely to have the stakeholder contacts, or understanding of your organization, required to be effective (in the short term)
Project manager
  • Has decision making authority and experience
  • Might have decent analysis skills
  • Likely available full time

 

  • May not have a sufficient understanding of the technical infrastructure
  • May not have full range of stakeholder contacts
  • May not have good relationship with delivery team
Senior business person
  • Likely strong at a single LoB
  • May have decision making authority and experience
  • Likely to have very strong connections in the business
  • Rarely available full-time
  • May not have an understanding of the full range of business
  • Unlikely to have an understanding of the technical infrastructure nor connections with technical stakeholders
  • May not have analysis skills
System analyst
  • Strong analysis skills
  • Likely to have an understanding of the technical infrastructure and the overall business
  • Available full time
  • May not have strong connections with business stakeholders

An interesting strategy that we’ve found fruitful, albeit one that borders on ageism, is to look for potential candidates whom have been with your organization for a long time and who are five to ten years away from retirement. These are experienced people who therefore are likely to have a good understanding of your organization and where it’s headed, they very likely have a good contacts throughout your organization, and they’re very likely looking for an interesting and stable position that will last until they’re ready to retire.

Have a Clear Career Path

A critical success factor for attracting people to the role of PO is to have a clear and viable career path for them. If it isn’t obvious to people where they would go next after becoming a PO, or worse yet if becoming a PO is seen as a career dead end, then why would anyone choose to step into this role? One option for POs is to become product managers, if a product management function exists in your organization. Another career path is for POs to move into a senior business or IT leadership position. Being a PO gives people a deeper understanding of how IT fits into the larger organization and how it works in practice – key skills for anyone in senior management these days.

 

Stable Teams Over Project Teams

One of the interesting trends that we’re seeing within organizations taking a disciplined agile approach to solution delivery is the preference for stable teams. Stable teams, also called stable product teams, are exactly as they sound – they remain stable over time, lasting longer than the life of a single project. This blog explores the differences between project teams and stable teams and then overviews the advantages and disadvantages of the stable team approach.

Stable Teams

As you can see in the following diagram, with a project team approach we say that we bring the team to the work. What we mean by that is that we first identify the need to run a project, perhaps to build the new release of an existing solution or to build the initial release of a new solution, we build a team to do the work.   Once the work is done, in this case the solution is successfully released into production, the team is disbanded and its team members move on to other things.

Stable teams vs project teams

The stable team approach is a bit different. In this case we first build an effective team then we continuously bring valuable work to the team to accomplish. In this situation the work never really ends, but instead we replenish the team’s work item list (or work item pool depending on the lifecycle being followed) regularly. The team stays together and continues to produce value for your organization over time.

Of course the term “stable team” is a bit of a misnomer as they do evolve over time. For example, many people like to stay on a team for a couple of years and then move on to another team to gain new skills and perspectives. This is good for them and good for your organization as it helps to keep your teams fresh. Sometimes you will want to grow or shrink a team. Sometimes you will discover that two people aren’t working well together and you need to split them up. The point is that there are very good reasons for your stable teams to evolve over time.

We wouldn’t be disciplined if we didn’t explore the trade-offs involved with stable teams.

The Advantages of Stable Teams

There are several advantages to stable teams:

  1. Lower management overhead. There is clearly less “resource management” to be done because you’re not constantly forming and disbanding project teams. In fact, this lower need for resource management activities is one of several factors why agile IT organizations need managers than non-agile IT organizations.
  2. Easier team budgeting. The annual budget for a stable team is incredibly straightforward to calculate: Multiply the number of people on the team by the fully burdened cost of an IT person for your organization. Once again, less management work required for this.
  3. You build better teams. When you build project teams you tend to take the people who are currently available (often referred to as sitting on the bench). With a stable team approach you’re motivated to build your teams with the right people, and very often its best for the team to build itself by inviting others who they believe will fit in well.
  4. There is less overhead from team formation. You’re forming teams far less often with a stable approach compared to a project team approach, hence there is less overhead in total for your organization.
  5. You have more efficient utilization of staff. With this approach it is far less likely that someone will be “sitting on the bench” because they will instead be an active member of a team. When someone is hired it is directly into a team. Throughout their career they will move from team to team as appropriate. The only time that they might not be utilized is when their on vacation, sabbatical, or if you purposefully disband a team. The first two reasons are something you still have with the project team approach, and the last reason should happen a lot less often.
  6. Your teams are more likely to improve. When a team knows that they will be working together for a long time, and particularly when they are responsible for the entire delivery lifecycle from beginning to end, they are more likely to streamline their work so as to make things better for themselves.

 

The Disadvantages of Stable Teams

There are several disadvantages to stable teams:

  1. Teams can become too stable. A real danger of stable teams is the potential for groupthink – everyone on the team starts to think and work in a common way, thereby being in danger to common blindspots. Luckily people still want to move to other teams for career management reasons, offering the opportunity to bring new viewpoints into other teams. In the Disciplined Agile (DA) framework we have the continuous improvement process blade which supports sharing of ideas across teams so that can also lessen the chance of groupthink. And, as mentioned earlier, some people may need to be motivated to move on to another team for interpersonal reasons.
  2. You still may need to do projects. Sometimes your business team makes promises to their customers. For example, in a software company a sales person makes a big sale and promises that by a certain date your solution will have additional features that the customer needs (in immature organizations they’ll even make such promises without first negotiating this with the delivery team). Another example would be a financial institution that needs to fulfill new industry regulations that require changes to existing solutions. In both of these cases there is a large amount of work to be done that needs to be delivered before a certain date, and this may motivate you to treat this work as a project. You would still bring this work to the appropriate stable team(s) to accomplish as you normally would. However, you would also track the performance of the work to ensure that it is delivered in its entirety as appropriate. The implication is that projects may not completely go away

 

Our Recommendation

Start experimenting with stable teams if you’re not already doing so. For most organizations the advantages clearly outweigh the disadvantages. In fact, you can see this in the Longevity decision point of the Form Initial Team goal diagram below.

Form the Initial Team

When Should You Assign Points to Defects?

A common question that we get from teams who are new to agile is whether you should assign points (sizes) to defects.  From a Disciplined Agile point of view we know that the answer will vary depending on the context of the situation, or in other words “it depends.”   The really disciplined answer though is to say on what it depends, which is what we explore in this blog.

Rod Bray, a senior agile coach at Scott Ambler + Associates, suggests this principle:

Don’t reward people for shoddy work

An implication of this is that if a team is injecting defects, they’re producing shoddy work, then it makes sense that their velocity suffers when they have to spend time fixing those defects.  The decrease in velocity is a visible trigger to investigate, and address, the cause of the productivity loss.  But what if the “shoddy work” wasn’t caused by your team?  What if the “shoddy work” was previously acceptable to your stakeholders?  Hmmm… sounds like the context of the situation counts in this case.  The following flowchart works through common thinking around when to size a defect.  Note that this is just our suggestion, your team could choose to do something different.  Let’s work through common scenarios to understand whether defects should be sized or not.  These scenarios are:

  1. Is it existing technical debt?
  2. The defect is injected and found by the team
  3. The defect is found by independent testing
  4. The defect is found after the solution is released

 

When do you size defects

 

Do you size the repair of existing technical debt?

The quick answer is sometimes.  For the sake of discussion we’ll assume that this technical debt has existed for a long time, potentially years.  From a purist point of view technical debt may be injected at any time (this is obviously true) and as a result may only be seconds old.  In the case of technical debt that is very new, refer to the logic below.

The key issue is whether fixing the defect is going to be a substantial effort. This of course is subjective.  Is the work substantial if it’s less than an hour of effort?  Several hours?  Several days?  Several weeks?  This is a bar that your team will need to set.  Something that will impact your schedule is likely to be substantial (and something your Product Owner is likely going to want to prioritize so that it can be planned for appropriately).  Clearly a defect that takes several days or more to fix is substantial and one that takes less than an hour is likely not.  Something that takes several hours or a day or so is likely something you need to think about.

 

Do you size defects injected and by found by the team?

No, the exception being technical debt (see above).  This falls under the principle of not rewarding the team for shoddy work.

 

Do you size defects found by independent testing?

Some teams, particularly those working in regulatory environments or working in complex environments, may be supported by an independent test team.  An overview of the independent testing strategy is presented below.  With the exception of the defect being found in existing technical debt (see above), the defect should not be sized.  Once again, the principle described earlier holds.  Of course if you don’t have an independent test team supporting your team then obviously you can ignore this question.

Independent agile testing

 

Do you size defects found in production?

The answer is sometimes.  As you can see in the high-level lifecycle diagram below, the DA framework explicitly recognizes that change requests are often identified by end users of an existing solution.  These change requests are effectively new requirements that should be prioritized and worked on appropriately.  Many organizations will choose to distinguish between two types of change requests, defects and enhancements, so that they may be treated differently.  The issue is that defects are often tracked and, if the team is smart, they are analyzed to determine how they got past the team in the first place.  Additionally you may find that defects and enhancement requests are charged for differently (a topic for a future blog).

Disciplined Agile Lifecycle - High Level System

If you don’t distinguish between defects and enhancement requests then there’s nothing to do, you simply treat the change request as a new requirement and size it like you normally would.  But if you do distinguish between types then you need to think about it a bit.  If the defect is found during a warranty period then it shouldn’t be charged for. Sometimes, particularly when work is being outsourced, there is a warranty period of several weeks or even months after something is released where the development team is expected to fix defects for free.  In this case you likely wouldn’t size the work in line with the principle described earlier.  Once you’re out of the warranty period then it’s likely you want to assign points to it: The functionality in question passed testing and was accepted by your stakeholders, so they in effect have taken responsibility for it.

To summarize, the answer to the question “Should we assign points to a defect?” is “it depends.”  In this blog we explored in detail why this is the case and described when and when you wouldn’t want to assign points.

I’d like to thank Kristen Morton, Rod Bray, and Glen Little for their insights which they contributed to this blog.

Rolling Wave Planning in Disciplined Agile

Wave

The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

Rolling wave planning is implemented in several places of the DA framework. First, as you can see in Figure 1 below, it is an option of the Level of Detail decision point of the Develop Initial Release Plan process goal. A rolling wave approach to release planning has the advantages of more accurate and flexible planning although can be a bit disconcerting to traditional managers who are used to annual planning strategies.

Figure 1. The Develop Initial Release Plan goal diagram.

Develop Initial Release Plan

 

The Portfolio Management process blade supports rolling wave budgeting as an option for its Manage the Budget decision point. This is depicted in Figure 2. The advantages are greater flexibility and greater likelihood of investing your IT funding more effectively, albeit at the loss of the false predictability provided by an annual budgeting strategy.

Figure 2. The goal diagram for the Portfolio Management process blade.

Disciplined Agile Portfolio Management

 

The Program Management process blade supports rolling wave planning of a program itself, as you seen in Figure 3. Planning and coordination are critical on a large program, and rolling wave planning offers the advantages greater flexibility, the ability to think important cross-team issues through, and the ability to react to changing stakeholder needs. The primary disadvantage is that it can be disconcerting for traditionalists who are used to thinking every thing through from the beginning.

Figure 3. The goal diagram for the Program Management process blade.

Disciplined Agile Program Management

 

As you can see in Figure 4, rolling wave strategies can be applied in Product Management to evolve the business vision/roadmap. A continuous, rolling wave approach is critical to your success because the market place changes so quickly – these days, few organizations can tolerate an annual approach to business planning and in the case of companies with external customers an ad-hoc approach can prove to be too unpredictable for them.

Figure 4. The goal diagram for the Product Management process blade.

Disciplined Agile Product Management

 

Previously we saw that rolling wave strategies can be applied to evolve your technology roadmap, as indicated in the goal diagram for Enterprise Architecture in Figure 5. The advantages of this approach are that your roadmap evolved in sync with both changes in technology and with your organization’s rate of experimentation and learning. The main disadvantage is that your technology roadmap is effectively a moving target.

Figure 5. The goal diagram for the Enterprise Architecture process blade.

Disciplined Agile Enterprise Architecture

As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) framework. In fact, in most situations they prove to be the most effective and flexible strategies available to you. The advantages of rolling wave planning tend to greatly outweigh the disadvantages. More on this next time.

Rolling Wave Planning for Technology Roadmaps

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This article explores how to apply rolling wave planning in a pragmatic manner to technology roadmaps.

An important aspect of your enterprise architecture efforts is to provide architectural guidance, both business and technical guidance, to your organization. One of the key artifacts that enterprise architects will create is a technology roadmap that, as the name suggests, provides guidance as to the proper application of technologies within your organization. This roadmap will often supplement any “as is” and “to be” models that the enterprise architects create.

Technology roadmaps are often evolved following a rolling wave planning approach. Figure 1 depicts an example of a technology roadmap, the goal of which is to  give technical direction to solution delivery teams so as to provide safety rails around technical experimentation.

Figure 1. A technology roadmap in September 2016.

Rolling wave technology roadmap

 

Notice how this roadmap addresses several categories of technical issues:

  1. Planned upgrades. Development teams need to know what aspects of your infrastructure will be evolving and when. Upgrades that are soon to occur have been assigned dates as these changes are very likely going to impact several development teams.
  2. Experiments. From an agile point of view the most interesting thing is the list of experiments that the enterprise architects are overseeing. These experiments usually occur within one or more of the development teams underway in this company. In this case the EAs are coordinating and guiding the experiments, ensuring that the teams focus on experiments that reflect the overall direction of the organization. In some cases you may choose to have an explicit proof of concept (PoC) project to validate a new technology, a common approach for major infrastructure components or expensive packages. Either way, by planning for explicit experimentation you bring greater discipline to your learning and architectural evolution efforts.
  3. Reusable infrastructure. This company has a reuse engineering effort underway where common architectural components, in this case microservices, are built and then made available to development teams. Once again, the closer to being released the reusable components are the more likely it is to have a target date for their release.
  4. Retirements. An aspect of technology roadmaps that are often forgotten are the plan to retire existing systems and infrastructure components. An important part of paying down technical debt within organizations is the consolidation of your IT infrastructure – reducing the number of technologies that you’re using, removing redundant systems, and so on. Such retirement efforts can take months and even years. We see in Figure 1 that SQLServer is currently being retired from service, development teams are migrating to approved database technologies, and that it is slated to be completed by February 5th. In this case the enterprise license for SQLServer ends in April 2017 so they’re hoping to be completely off of it two months before that.

 

What Should the Planning Horizon Be?

Technology roadmapping tends to have between a six month and three year planning horizon depending on what is being planned for. For example, experiments are typically planned out a few months in advance as they are often driven by the needs of development teams. Major upgrades are typically planned on a horizon of six months to a year as this reflects the rate of change of many technologies. Retirements might typically planned for years in advance, particularly when the retirement could impact multiple systems.

 

How to Capture Technology Roadmaps

Technology roadmaps are typically captured in text format as you see in Figure 1 above, although a timeline format (as we say with product roadmaps) are often used for executive presentations.

This sort of planning is only one of several things that your enterprise architecture team will do of course. In addition to actively guiding development teams and working with senior stakeholders, the enterprise architects are also maintaining current and to-be models and are hopefully producing code examples for how to work with new architectural components.

Rolling Wave Planning for Product Roadmaps

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This article explores how to apply rolling wave planning in a pragmatic manner to product roadmaps.

An important aspect of product management is to develop and evolve an overall business vision, an important part of which is your organization’s product roadmap. This is sometimes called a “multiple product roadmap” or “product offerings roadmap” although more commonly just a “product roadmap.” This roadmap indicates upcoming product releases (or application releases for non-product companies), potential product ideas, and the retirement of any products. The goal is to manage customer expectations regarding your product portfolio.

An example of a product roadmap for a fictitious company is depicted in Figure 1 below. For product planning this company’s very near term (green) is a three month, rolling period. In this case we’re seeing the roadmap as of September 2016. For the very near-term the expected release dates of each product are indicated. This company has chosen to also do this for some, but not all, of the products being release din the near term (yellow) – In some cases it isn’t yet clear exactly when a release will occur so the company doesn’t want to set unrealistic expectations by giving an exact date yet. In the case of Katana 12.1 they are committing to a date whereas with Webshooter 1 they are committing to sometime during quarter 2 (April through June). The other product releases do not have published dates yet.

Figure 1. A product roadmap (text approach) from September 2016.

Product roadmap - text-based version

It’s interesting to note that for upcoming (red) they are choosing to just indicate new products they hope to release during that period but not releases of existing products. This is because this period is nine months or more into the future so promising exact dates to people becomes a questionable proposition, far better to indicate ranges for now. For the distant future (gray) the product roadmap shows potential ideas for new products but these are only vague “wish list” items at best right now, not all of which will be invested in.

Figure 2 depicts a timeline version of a product roadmap. It focuses on currently planned product releases and so it does not depict the future product ideas that we saw in Figure 5.   These product ideas would be captured elsewhere, perhaps as a list on a whiteboard some where.

Figure 2. A timeline version of a product roadmap.

Product roadmap - Timeline version

What Should the Planning Horizon Be?

Product roadmaps tend to have a multi-year planning horizon. Figure 1 showed about two years of planning whereas Figure 2 a bit more than a year. There are several key considerations to take into account when determining your planning horizon. First is how often can your teams release? You typically want to be able to indicate several releases of your major products/solutions on your roadmap, which you can see in both examples. Second, how often do your customers want releases?   Third, how far in advance do your customers need to plan? This is a reflection of the sales cycle for your products, the longer the sales cycle the longer between releases of your product (usually) and the longer the timeframe covered by your roadmap.

 

How to Capture Product Roadmaps

There are two basic strategies for depicting product roadmaps:

  1. Text lists. Figure 1 is an example of this format. The advantages are that this format is compact and easy to create with simple tooling. The main disadvantages are that it doesn’t show relationship between releases well nor is it very attractive visually.
  2. Timeline diagrams. See Figure 2 for an example. The advantages of this approach are that it is visually appealing, which is particularly important when you are showing the roadmap to customers; it depicts timing relationships well; this format is supported by several product management tools; and you can even show dependencies between product releases, in a similar manner as you would do so on a Gantt chart (we didn’t do this in Figure 6). The primary disadvantage is that this format requires more sophisticated tooling to create.

Your product roadmap is an important part of your organization’s overall business vision. Another part of that vision is your business roadmap, the topic of a future blog.

Rolling Wave Release Planning for Agile Delivery Teams

Wave

The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

In Figure 1 you see how a Disciplined Agile Delivery (DAD) team takes a rolling wave approach to release planning. This is a stable team that releases their product into production twice a year. The team has been in place for almost three years and as a result they no longer need to go through an Inception phase. The Construction phase is typically scheduled for twelve iterations. Their Transition phase still takes one week. Although they’ve automated their test and deployment scripts a long time ago they still need time for internationalization – in this case they need to finalize and acceptance test any translated work.

Figure 1. Rolling wave release planning on a solution delivery team.

Rolling wave release planning overview

 

Figure 2 overviews the level of detail that the team currently has captured in their requirements artifacts and in effect how they would show up in any sort of team work plan. The team is currently in the first construction iteration for the current release, implementing 5 user stories. There are thirteen additional user stories that have been explored in detail by the product owner which at the team’s current velocity is about one month of work. There are an additional thirty user stories identified but not yet explored, and several epics. In the middle of this current iteration the product owner is likely to run one or more look-ahead planning/modeling sessions (called backlog grooming or backlog refinement in Scrum). The goal of this effort will be to detail a few of the near term (yellow) stories to pull them into the very near term (green) category and maybe to even start breaking down an epic or two into more details stories. This effectively pulls work along in the plan. The team’s iteration/sprint planning session at the beginning of each iteration pulls work into the team at that point.

Figure 2. Solution release planning at construction iteration #1.

Rolling wave release planning iteration 1

An interesting implication of this approach is at the beginning of the iteration it isn’t clear exactly what the team will deliver. As you can see in Figure 2 only about one-and-a-half months of work has been explored in detail (eighteen stories in total), an additional two months of work (thirty stories) has been identified at a high level and the rest at a very high level. In addition, the stakeholder’s priorities could shift and different stories and epics could be prioritized higher in the team’s work item stack (backlog) later on in construction.

Now let’s work through what things look like at the beginning of iteration #8.   As you can see in Figure 3 the team is currently working on six stories and has eleven more that have been detailed out for the next month or so. There are thirty-two stories identified for the near term (yellow) category. Interestingly, Construction ends in about two months (remember, the releases are six months long with this team). At this point in time it’s fairly clear what the team will deliver, albeit with some room for change given that there is still to months of construction left.

Figure 3. Solution release planning at construction iteration #8.

Rolling wave release planning iteration 8

 

What Should the Planning Horizon Be?

In this example the planning horizon is fairly long because the team’s release cycle is fairly long at six months.   They chose to maintain about three months of details and kept everything else at a high level and that worked for them. We recently worked with a team at an e-commerce firm following the continuous delivery lifecycle where the distant future (grey) was anything more than two months away. As a result they had detailed requirements for the next two to three weeks (green), about the same number of stories that hadn’t been worked through yet for near term work (yellow), and then a collection of epics after that. The point is that you need to set your planning horizons according to the situation that you face. Context counts.

 

Capturing a Release Plan

A deliver team can choose to capture their release plan in several different ways, and could even combine strategies for doing so. Their options include:

  1. Maintain the plan manually. Many teams will capture their requirements manually, using paper to capture the stories, acceptance criteria, and any supporting artifacts. For the current iteration the team manages their work on a whiteboard with sticky notes or corkboard with index cards. Future work is often tacked onto a corkboard or maintained in file folders or similar containers. The advantages of this approach are that the plan is easy to evolve and work with (you’re moving paper around). The disadvantages are that reporting also becomes manual (perhaps you’re asked to estimate your expected delivery date or cost using burn up or burn down charts), it doesn’t easily support geographic distribution, and that this strategy may be anathema to your governance people if they’re not experienced yet with agile development.
  2. Use an agile management tool. Many teams choose to use agile management tools such as Atlassian Jira, VersionOne, Microsoft TFS, or Rally to name a few. These tools have the advantage that they support geographically distributed teams, they often also address any plan documentation needs for teams working in regulatory situations, they are often less threatening to your governance people, and they can even be integrated into any corporate reporting technologies your company has in place (such as Microsoft Project Server for example). The disadvantages are that they are often harder to use than manual strategies (regardless of the vendors’ marketing claims), agile management tools can still be threatening to traditional-leaning governance people because of they support a more agile way of working, and of course the need to pay for and learn them.
  3. Create a Gantt chart. Your rolling wave plan can also be captured using Gantt charts (yes, Gantt charts can be used in an agile manner if you choose). The article Agile Project Planning Tips works through how a Gantt chart evolves with a rolling wave planning approach. The advantages are that Gantt charts are a familiar way to communicate your schedule to others and that your existing management tools likely support them already. The disadvantages are that Gantt charts can still be a bit clunky from an agile point of view and that many project management tools make it too easy to capture details that often prove to be of little value in practice.

A potential point of confusion is what to call this sort of plan. Up until now we’ve been using the term release plan. However, as you can see in both Figure 2 and Figure 3 the plan extends to more than a single release of this product. This is really a “multiple-release plan” or better known as a product plan (not to be mistaken with a product roadmap, something that your product management efforts will often produce). More on this in the next blog posting in this series.

Introduction to Rolling Wave Planning

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few.  This blog overviews this important practice.

The basic idea is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

In Figure 1 below you see an overview of how rolling wave planning works and in Figure 2 an example of how a Disciplined Agile Delivery (DAD) team applies it for release planning. Upcoming work is planned in detail, the planning unit “X” is one month in the case of the delivery team. In order to do their work they need detailed user stories and supporting artifacts such as acceptance criteria and supporting models such as user interface (UI) sketches or data source analysis. They have this information for the work that they are doing right now as well as about one month’s of upcoming work. They don’t yet need details for work that is several months away in time. In this case for work that is two to three months in the future they only have user stories developed and work that is four to six months away epics. Work in what the team considers to be the distant future, in this case six or more months away, is described in very high-level terms such as epics or solution capabilities.

Figure 1. Rolling wave planning overview.

Rolling wave planning overview

Figure 2. Rolling wave release planning on a solution delivery team.

Rolling wave release planning overview

Part of the work that the team is doing right now is to keep their plan up to date. For example, if they are working in two week iterations they will pull two weeks of work into the team. During the current iteration they will pull about two weeks of user stories from the near term category (the yellow box in Figure 2) into the very near term (the green box). They may also bring upcoming work into the near term category at this point too.

Rolling wave planning has its source in iterative software development such as the Rational Unified Process (RUP). It is a strategy that is commonly applied by agile software teams and the Project Management Institute (PMI)’s Project Management Book of Knowledge (PMBoK) supports it.

In future blog postings in this series we will work through examples of applying rolling wave planning in practice.

Process Tailoring Workshops Help Increase Agile Team Productivity

Tailor

I recently wrote a detailed article about process tailoring workshops.  In a process tailoring workshop a coach or team lead walks the team through important aspects of the delivery process and the team discusses how they’re going to work together. This typically includes choosing a lifecycle, walking through the process goals one at a time and addressing the decision points of each one, and discussing roles and responsibilities.

There are several reasons why you want to tailor your team’s process:

  1. Every team is unique and faces a unique situation.
  2. You want to have a common vision as to how you’re going to work together.
  3. You want to streamline how you work together.
  4. You may actually need to document your process.

The article covers the following topics in detail:

  1. Why process tailoring?
  2. When do you run process tailoring workshops?
  3. The risks associated with process tailoring workshops
  4. Planning a process tailoring workshop
  5. What should you tailor?
  6. Running a process tailoring workshop
  7. Documenting the results

I hope you find it useful.

 

Agile Teams and The Breakfast Club

The Breakfast Club

One of the iconic movies of the 1980s was The Breakfast Club, which told the story of five very different teenagers who were forced to come into school one Saturday to serve detention.  Recently I’ve been working at a large insurance company helping them to adopt the Disciplined Agile (DA) framework.  One of people whom I’m working with has a Breakfast Club poster on the wall near her work area and it got me thinking about some of the dynamics that I’ve seen watching agile teams form and eventually gel.  Here are my thoughts.

At the start of the movie the kids didn’t really like each other, they were very different from one another, they certainly didn’t want to be there, and they were each coming to the group with their own point of view and background.  Sadly, I’ve seen more than one software project team that was put together like this.  As the movie progressed they began to really talk with one another and their stories started to emerge.  They started to work together, hijinks ensued, and they bonded as a group.  As part of their punishment they were each asked to write an essay describing what they learned from their detention.  Instead they wrote a single letter, which follows, that they submitted as a team.

“Dear Mr. Vernon:

We accept the fact that we had to sacrifice a whole Saturday in detention for whatever it was we did wrong, but we think you’re crazy to make us write an essay telling you who we think we are. You see us as you want to see us… In the simplest terms and the most convenient definitions. But what we found out is that each one of us is a brain… …and an athlete… …and a basket case… …a princess… …and a criminal.

Does that answer your question? Sincerely yours, the Breakfast Club."

So how does this relate to agile teams?

  1. You often build teams from specialists.  Although we ideally recommend that you build teams from multi-disciplinary, T-skilled generalizing specialists, the reality is that many organizations are staffed with specialized people.  We like to say that you go to war with the army that you’ve got, or in other words you need to make do with what you have.  If all you have are specialized staff then that’s the people you have to form teams.  The good news is that you can help people to evolve from being specialists into generalizing specialists via building a cross-functional whole team, enabling and promote non-solo collaborative work within the team, and by training and coaching people.
  2. It takes time for a team to gel.  In the movie the “team” gelled in a single day, but it’s rarely that fast in practice.  It often takes weeks, and sometimes months, for a team to really get to the point where they’re working together effectively (yet another reason to move towards stable solution delivery teams).
  3. Co-location shortens the time it takes to gel.  When we’re co-located, everyone works together in the same room, it is much easier and much more likely that we will collaborate with one another.  Not only does this increased interaction help us to get the work done it also helps us to gel as a team faster.
  4. We’re not as different from each other as we think.  One of the lessons that the kids learned in the movie is that each one of them had a bit of an athlete, a brain, a criminal, and so on in them.  Similarly, we’re not just programmers, or architects, or analysts but instead we all have some of those skills in us and we can certainly get better at the skills that we are weak on.
  5. We are still different.  Every single person is a unique individual.  This implies that we must be flexible in the way that we collaborate with one another, that people simply aren’t “cogs in the corporate machine.”  We should also respect the fact that we each bring something of value to the team, a revelation that the kids in the movie stumbled upon when they had to work together to not get caught by Mr. Vernon (there were a few hijinks in the movie).
  6. Working together as a team produces better results than a group of individuals.  As Alistair Cockburn likes to say, software development is a team sport.  In the movie the kids all got caught doing something on their own, hence the punishment of a Saturday in detention, yet together they managed to have a fair bit of fun as a team.  Similarly, you may be the best programmer in the world, but it behooves you to work with people who can help you to understand the requirements, design the solution, validate the solution, and so on.
  7. We can all learn from each other.  Everyone has value to bring to the team and everyone has areas where they are weak on that could be improved.  By working closely together we can learn from each other and get better both as individuals and as a team.

The Breakfast Club is a great movie.  If you haven’t seen it, or haven’t seen it lately, then I highly suggest watching it again.