Disciplined Agile

This posting, the latest in our series focused on a disciplined agile approach to product management, overviews the activities associated with it. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy.  The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Product Management process blade and overview its process factors.

The following process goal diagram overviews the potential activities associated with disciplined agile product management.

The process factors that you need to consider for product management are:

1. Evolve business vision.  Product managers will work closely with stakeholders, and in the case of new products/solutions potential stakeholders, to understand their needs.  The goal is to develop roadmaps for individual products, product lines, and for the business itself.  These roadmaps describe the current vision for the near term, intermediate term (3-12 months), and long term (one year or more) with less detail the further out in time the roadmap goes.  These roadmaps help the product managers to guide their prioritization decisions and provides input into the planning activities of other efforts (such as the Enterprise Architecture and Portfolio Management activities).
2. Explore potential products.  Product managers want to identify potential products that will provide significant value to your organization.  They may do this via a variety of means, including the more traditional approaches of building a business case to more agile/lean strategies such running a small experiment.
3. Prioritize potential products.  There will be many potential products that your organization would like to invest in, but a limited budget to do so.  The implication is that only the highest priority products will be developed, and therefore need to be prioritized appropriately.
4. Evolve business roadmap.  The business and/or product roadmap is developed and evolved by your product management activities.  Traditional strategies tend to take either an annual or ad-hoc approach whereas more disciplined agile strategies take more of a rolling wave approach.
5. Allocate features.  Features – which could be captured in the form of epics, stories, feature statements, or other forms – will need to be allocated to delivery teams so that they may be implemented.  These features will need to be prioritized by the product managers (who are often in the role of Product Owner on the delivery teams) so that the teams know the order in which to implement the functionality.
6. Manage functional dependencies.  Functional dependencies often exist between products, due to the usage of common platforms and the need for integrated solutions, and these functional dependencies need to be managed.  The product managers will want to manage these dependencies so as to optimize when functionality is implemented and released into production.  For more information on dependency management strategies, please see Managing Dependencies Between Agile Teams, Managing Dependencies Between Agile and Lean Teams, and Managing Dependencies Between Agile/Lean Teams and Traditional Teams.
7. Market products.  Product managers will market their products to their potential customer base to increase the usage of the products.  The need for such marketing is clear in the case of commercial products and other types of solutions intended for public use.  Marketing is also needed for solutions developed for internal usage to increase the chance that the potential user base knows about the existence of the (upcoming) release of the product.

Future blog postings in this series will explore the workflow between product management and other process blades as well as the internal workflow of a product management team.

Product management includes the acts of identifying and evolving your organization’s business vision; of identifying and prioritizing potential products/solutions to support that vision; of identifying, prioritizing, and allocating features to products under development; of managing functional dependencies between products; and of marketing those products to their potential customers.  Disciplined agile product management is product management performed in a collaborative and evolutionary manner that reflects the context of your organization.

Why Product Management?

You need an effective approach to product management because you want:

1. To build the right product(s).  You will always have many more ideas for products than you can possibly fund.  Your product management team will need to prioritize the ideas for potential products so that they can focus on the ones that will provide the most value to your organization.
2. To stop building the wrong product(s).  Product managers will monitor the work of development teams, ongoing experiments, and even existing solutions running in production to determine their effectiveness.  Products that aren’t effective must either be evolved or cancelled to enable you to focus on high-value products.
3. The right product features at the right time.  When there are many delivery teams working in parallel there will be functional dependencies between the solutions/products being worked on.  These functional dependencies need to be taken into account when the work is being prioritized so that the right functionality is available when it is needed.
4. To ensure that people use the product.  Part of product management is marketing to potential end users/customers.  If people don’t know that functionality is available to them then they are unlikely to use/buy it.

In future blog postings in this series we will explore in detail the activities of Product Management, how it fits into your overall IT effort, and the workflow that potentially occurs within a Product Management team.

Reuse isn’t free.  Without funding, either implicit or explicit, meaningful reuse simply doesn’t happen.  In short, your approach to funding is a critical success factor for your reuse engineering strategy.

In this blog posting we explore several strategies for funding reuse within your organization.  The funding strategies, from most to least desirable, are:

1. Funded reuse-engineering team.  A team of one or more people in the role of reuse engineer is provided explicit funding to support and enhance the reuse efforts within your IT department.
2. Asset-level funding.  Funding for a specific reusable asset, such as a security framework or collection of micro services, is explicitly budgeted for.  This funding should cover the development, enhancement, and long-term support of the asset.
3. Development team-based funding.  Funding for the use, development, and enhancement of reusable assets is included in the budget for development teams.  Such funding is often accompanied by mandates along the lines of “The team will achieve X% levels of reuse” (although teams are rarely measured against these mandates in practice).
4. No explicit funding. With this approach reuse occurs on an ad-hoc basis within delivery teams, often driven by tactical decisions at the team level as opposed to strategic decisions at the organizational level.
5. Chargeback funding.  Delivery teams are charged for usage of an asset.  In some extreme cases development teams are charged to download an asset from the reuse repository, typically because that’s easier to charge them at this point in time over charging for actual usage.

Table 1 compares and contrasts these funding strategies.

Table 1. Comparing the reuse funding strategies.

Combinations of these strategies can of course be implemented.

Related Reading

• Process Blade: Reuse Engineering
• Disciplined Agile Reuse: Harvesting Potentially Reusable Assets:
• Reuse Engineering: A Goal-Driven Approach
• What can you reuse on agile software teams?
• Reuse Engineering 101

Agile development teams build new things every day, and some of these things can be generalized into robust assets for reuse by other teams. This is particularly true for teams that are working with new technologies and techniques: for example, your first few C# teams are likely to develop useful micro services, or the first few agile teams to write personas will develop a potentially reusable template. The downside is that the first people to work with a technique or technology are most likely to make “beginner mistakes,” so their work may not be something you want to share with others. The implication is that you either need to wait to harvest a higher quality asset later or be willing to invest more effort into generalizing the asset.  We’ve found that it’s usually best to wait, giving you more time to gain experience with the technology or technique and discover if there is actually a need for the asset on other teams.

One of the key activities performed by a reuse engineering team is to harvest potentially reusable assets so that they may be generalized for reuse on other teams.  There are five steps to the harvesting process:

1. Find a potentially reusable asset.  Reuse engineers will be constantly on the look out for potentially reusable assets.  They find out about them via word of mouth, through internal online discussions, during enterprise architecture coordination meetings, and from suggestions made by members of development teams.
2. Assess the viability of the asset.  Just because someone thinks that an asset is potentially reusable doesn’t mean that it is.  The reuse engineers must determine whether there is a likely demand for the asset.  When other several other development teams have something similar, or are at least thinking about developing such an asset soon, then this is a fairly straightforward decision.  If there isn’t any immediate customers for the asset then that’s an indication that you are likely better to wait until it’s clear that other teams will be able to leverage the asset before you invest in generalizing it.
3. Generalize the asset. It takes much more effort to generalize an asset to make it reusable than it does to develop it for single-purpose usage. For example, studies showing that development of reusable code costs 111% to 480% of the development cost of single-purpose code.  Generalizing an asset requires great skill because the person doing this needs to be familiar with not only the technology or technique behind the asset but also with how it will potentially be used in practice. Part of generalization is to ensure that the asset conforms to appropriate guidance and making it easy to understand by its intended audience. You also want to validate the asset. You’ll need to unit test code-based assets and review templates and non-code artifacts with their target audiences. Concise overview documentation is important, but far more important are one or two good examples showing how to use the robust artifact properly. In the case of code, your unit tests may be sufficient. For templates, you should capture an actual example of the document for which it is a template (for example, to support a use case template, you should harvest one or two well-written use cases from a project team).
4. Reintegrate the asset into the source. The reuse engineers do this “extra” integration work so that the source team gets the advantage of working with the improved asset without taking on the cost of having to refactor their solution to do so.
5. Publish the asset.  The asset needs to be made available to the teams who could actually reuse it.  The publishing effort typically entails putting the asset into a reuse repository (which could be anything from a folder to a configuration management system to a commercial asset management product) and announcing the availability of the asset to potential customers of it.

There are four basic timing strategies for when to harvest an asset:

1. Harvest in-progress. You generalize an asset developed by a team before it has been released into production.  The reuse engineers do this by working closely with the development team, often joining them for a period of time so that they can generalize the asset and do the work to reintegrate the new version into whatever the team is building.
2. Harvest after production release. With this strategy the reuse engineers wait until the source development team has finished building the asset.   As with the first strategy they do the work to generalize reintegrate the asset.   In cases where the team isn’t working on a new release they do a “patch” release of the solution into production, but this obviously isn’t a desirable situation to be in (it’s far better to have stable development teams).
3. Harvest a legacy asset. In rare situations it is possible to harvest an existing asset currently deployed in production by encapsulating access to it. Although this strategy is often talked about it is rarely used in practice because it requires the asset being harvested to be well architected in that it must be loosely coupled and highly cohesive.  Most legacy assets tend to be the exact opposite, which is the primary reason why they’re not already being reused by other teams.
4. Harvest for a new project. You wait until a project team needs an asset previously developed by another team and then decide to either reuse the asset as-is or to generalize it.  This strategy has the advantage that you know there is a customer for the reusable asset before you invest in it.  However, the team may not be able to wait for the asset to be generalized.  Furthermore, unless the asset was developed recently people are likely to have forgotten about it, implying that this strategy has a short viability time frame.

During the first week of August we ran a mini-survey exploring whether or not teams have fixed iteration lengths.  It was motivated by a question about the results of our Agile Cadences and Technical Debt Survey we ran earlier this year.  Apparently the person was working on a team where their iteration length often shifted and he was wondering how common this was.  I responded that it wasn’t very common and that instead the common practice was to not allow the iteration length to vary.  He found this hard to believe and wondered why we didn’t have any data to back up that claim.  So we decided to run a short survey to discover what is happening in practice.  Over a one-week period we had 264 responses (thank you very much to those of you who did take the time to fill out the survey).

The following diagram summarizes the results of the third question that explored whether teams that were working with iterations kept the iteration length fixed.  As you can see, the majority of agile teams (68%) that have iterations/sprints keep their iteration lengths fixed.  Furthermore, for those teams that allow iteration lengths to vary it’s a rare occurrence (often the result of valid reasons, such as a holiday in the middle of the iteration).

The survey consisted of four questions:

1. The first asked if the respondent was working on an agile team (if not they exited the survey)
2. The second asked how long iterations are (the majority said two weeks or less).  If the team didn’t work with iterations (such as lean teams or continuous delivery teams) or if the respondent didn’t know then they exited the survey.
3. The third question asked whether the length of the iteration was fixed (see the chart above).
4. The fourth question was presented only to people who said that their iteration length could vary.  It explored the reasons why this was the case.  I will summarize these results in a future blog posting.