Disciplined Agile

This posting, the latest in our series focused on a disciplined agile approach to continuous improvement, 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 posting we present the goal diagram for the Continuous Improvement process blade and overview its process factors.

The following process goal diagram overviews the potential activities associated with disciplined agile continuous improvement. These activities are performed by, or at least supported by, a process improvement team (sometimes referred to as a Software Engineering Process Group, or SEPG).

The process factors that you need to consider for continuous improvement are:

1. Identify improvements.  There are several ways that your process improvement group can support the identify of potential improvements within your organization.  One of the more effective strategies is to help teams adopt the practice of holding regular retrospectives.  Although it is common for disciplined agile delivery teams to hold retrospectives this is often a new concept for enterprise architecture teams, IT governance teams, data management teams, and so on.  We also get very good traction with value stream mapping and brainstorming sessions, which invariably proves to be far more effective than the traditional approach of creating current and proposed (business) process models that rarely seem to result in lasting acceptance of the proposed new way of working.
2. Share improvements.  As you can see there are multiple ways that you can share improvement ideas between teams, many of them being free or at least very inexpensive to implement.  We’ve had very good experiences with internal discussion forums such as Jive or ActiveBoard, practitioner presentations (often called lunch and learns) where someone presents  their learnings to others, lean coffee sessions where people voluntarily meet at a regular time to share ideas, and communities of practice (sometimes called guilds) who purposely collaborate to educate themselves in a given topic.
3. Capture improvements.  There are various ways that identified improvements may be captured to retain them over time.  Possible strategies include describing each learning in a document and then managing that document in a documentation repository such as Sharepoint or more simply in a shared folder; capturing the learnings in a shared wiki such as Confluence; describing your evolving process using a process repository such as Stages or Rational Method Composer; or via an expert system such as Enterprise Transformation Advisor.
4. Support teams. Your process improvement team can help others to adopt process improvement techniques through training, education, and coaching.  They can also facilitate team assessments and retrospectives (a great idea is to co-facilitate a few retrospectives with someone on the team to transfer those skills to them).  A very effective strategy is to help a team run a process improvement experiment or two, particularly in situations where the team isn’t being supported by a coach.  This helps them see that they can safely try new ideas within their environment for a few iterations to determine whether it works for them or not.  Many teams, particularly those new to agile, often do not feel empowered to run such experiments and thus need help to do so.
5. Organize Communities of Practice (CoPs).  A Community of Practice (CoP) is a collection of people who share a craft or profession who have banded together to ‘learn’ from each other to develop themselves and often even the  organization.  We’ve seen CoPs for testing, architecture, agile/lean, business analysis, technical debt, and many others.  CoPs will often perform the activities called out by the Identify Improvements, Share Improvements, Capture Improvements, and Support Teams process factors.  A CoP will often start up when one or more practitioners within your organization recognize the need for it, although sometimes it may also start to support the efforts of a corresponding Center of Excellence (CoE).  Participation in a CoP is typically voluntary.
6. Organize Centers of Excellence (CoEs).  A Center of Excellence (CoE) is a group of people with specialized skills and expertise whose job is to provide leadership and purposely disseminate that knowledge within your organization.  CoEs are often created by an organization to support the adoption of a new technology or technique, and in fact  the creation of an Agile CoE is often a key component of your organization’s overall Agile transformation efforts.  Over the years we’ve seen CoEs for object technology (particularly in the 90s when it was new to most companies), solution architecture, testing automation, and of course agile/lean.  Participation as a member of a CoE will be part of, or the entire job for someone.
7. Govern improvement.  It is very common for senior management to want to know whether or not the organization is benefiting from your investment in adopting agile and lean techniques (or other potential improvements for that matter), how much things are improving, and how widespread the adoption is.  The implication is that there needs to be some way to monitor and report on, preferably in a lightweight and streamlined manner, the improvement activities.

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

The purpose of the Continuous Improvement process blade is to enable people within your organization to easily share their improvement learnings with one another in a systematic way. There are several reasons why you want to have a continuous improvement program within your organization:

1. Shorten the time from idea to implementation. Improvement ideas can come from anyone, at any time, from anywhere in your organization. As a result you want to have organizational mechanisms to identify and explore those ideas so that they get to the person(s) most suitable to implement them quickly.
2. Increase skills and knowledge sharing. The high-collaboration environments that are typical of agile teams are wonderful for sharing skills and knowledge within each team, but fellow team members aren’t the only people within your organization that you can learn from. An important goal of a continuous improvement program is to motivate and enable people to share their skills and knowledge outside of their immediate team. You can do this through strategies such as communities of practice, online discussion forums, practitioner presentations and many others.
3. Maximize your “failure ROI”. A fundamental of lean thinking is to learn from your failures, to treat each “failure” as an opportunity to improve. Having said that, every team doesn’t need to experience all of the same failures. One team, or a handful of teams in some cases, can fail in similar ways and then share those learnings with others. This way other teams can avoid that type of failure and thereby increase the value of the learnings to your organization. But we can only do that when it’s safe to fail and better yet recognize that failures should be celebrated and the learnings shared with others.
4. Increase the opportunity for radical improvements. The challenge with the Japanese concept of kaizen, which is to continuously make small incremental improvements, is that you can get on an improvement path that will never lead to a quantum leap in your process. Yes, things are getting better, but you may be missing opportunities to make things a lot better. For example a team following the Scrum-based Agile/Basic lifecycle may never identify the strategy of continuous deployment (CD) on their own because having a two-week iteration may preclude the idea of releasing several times a day into production. Yet, if people on your team were to hear about other teams in your organization working that way, they might soon choose to start experimenting with CD techniques. This in turn could lead to the “radical” process improvement of abandoning the idea of time-boxed iterations and moving to something much closer to DA’s Continuous Delivery lifecycle.

In short, your organization needs a strategy for communicating potential improvements across teams. Ideally the flow of work should be streamlined to make it as easy as possible for teams to learn from one another. There are many options for doing so available to you, the topic of a future blog posting.

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