Disciplined Agile

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.

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 getting close to 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.  Given that the investment required to create a Product Owner is rather steep so therefore you want someone willing to stay in the position for at least several years, and given that these are experienced people looking for a position that will last several years, it’s a very good alignment that you should consider taking advantage of.

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.

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 or simply long-term teams, are exactly as they sound – they remain (reasonably) 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.  We also explore the issue of how stable teams evolve over time.

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.

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 greater opportunities to build trust within the team.  It takes time to build trust within a team.  Greater trust leads to greater willingness to work together in a more streamlined manner.  As Stephen Covey insightfully points out, trust enables speed.
5. There’s a greater opportunity for safety.  It takes time to build an environment where people feel safe. In safe environments there is a much greater chance that they will share ideas and be willing to try new things because they don’t fear being thought less of or even punished.
6. 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.
7. Better team performance.  Consider the analogy of a train.  Just like it takes time to bring the train up to cruising speed it takes time for the team to jell.  Bringing work to a seasoned team that works together well is like jumping onto a train going at full speed: it’s faster in both cases because you don’t have to get going from a full stop.
8. 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.
9. 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) toolkit 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

Evolving Stable Teams Over Time

Stable doesn’t mean stagnant.  Of course you still have basic people management issues such as people wanting to expand their skill set by working on something new by rotating to another team, people leaving the organization, and new people joining the organization.  So the team itself may go on for many years even though the membership of the team evolves over time.  Ideally these membership changes are not too disruptive: It’s not too bad adding a new person every month or so, or losing people at a similar rate, but gaining or losing several people in a short period of time can be painful.

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.

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 and Disciplined Agile instructor, 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

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.

Do you size defects found in production?

The answer is sometimes.  As you can see in the high-level lifecycle diagram below, the DA toolkit 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).

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.

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 toolkit. 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.

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.

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.

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.

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.

As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) toolkit. 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.

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) toolkit, 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.

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 5^th. 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.