Disciplined Agile

Let’s start with some definitions:

• Asset.  An artifact that is retained after its initial purpose is fulfilled.  For example, working source code is an asset because it is retained and potentially updated in the future to address new stakeholder needs.  A user story that is discarded once the functionality it describes is implemented is not considered an asset.
• Robust asset.  An asset that is appropriately documented, generalized beyond the needs of a single team, thoroughly tested, is of high quality, and ideally has several examples to show how to work with it. Robust assets are much more likely to be reused than items without these characteristics.
• Reusable asset.  A robust asset that has been used at least three separate times by at least three separate teams. You can claim that something is reusable, but it isn’t truly reusable until it’s actually been reused; reusability is in the eye of the reuser, not in the eye of the creator.
• Ad-hoc reuse.  An informal approach to reuse where individuals or teams reuse whatever they can find on their own.  Ad-hoc reuse is often a good start.
• Engineered reuse.  A formalized approach to reuse where an organization actively supports a reuse engineering strategy.
• Reuse engineering.   The purposeful creation (or rescue), management, support, and governance of reusable assets.

Why Do We Need Reuse Engineering?

The vast majority of developers, agile or otherwise, take an ad-hoc approach to reuse.  Although this is a good start, we have the opportunity to do much better.  There are several reasons why your organization should consider investing in explicit reuse engineering:

1. Quicker time to market.  The more reusable assets that a team has at its disposal then the less the team will have to build, thereby enabling them to release quicker.
2. Improved return on investment (ROI).  Reuse engineering enables IT delivery teams to avoid building something that your organization already has.  This leads to greater ROI for your IT investment which in turn leads to greater value being delivered to your stakeholders.
3. Improved consistency.  When all of your systems use the same implementation of a service, or component, or function, or framework then that functionality by definition is implemented consistently across those systems.  This makes them more predictable and easier to understand.
4. Easier updates to common functionality.  When functionality is implemented in one place and then reused where needed it is very easy to update that functionality and then deploy the updated version.

Why Reuse Engineering is Difficult

Unfortunately reuse is a lot easier to talk about than it is to implement in practice, at least beyond the ad-hoc level.  There are several reasons why reuse engineering is difficult to achieve:

1. There is a greater impact when reusable assets break.  When an asset is used in only one place and it breaks, then the impact of that breakage is limited to that one place.  When an asset is reused in dozens or hundreds of places, and it breaks, then the impact is significantly larger.  This is reusable assets need to be of high quality.
2. Teams must go beyond the reuse of source code.  Reuse is often described as not “reinventing the wheel,” and an important step for succeeding at reuse is to understand that you have more than one option at your disposal.  For example, in addition to source code you can reuse components, services, patterns, and templates to name a few.  More on this in a future post.
3. Reuse requires enterprise awareness on IT delivery teams.  For reuse to succeed IT delivery teams must understand that reusable assets exist, how these assets fit into your overall IT ecosystem, and what the benefits of reusing them are for your organization.  In Disciplined Agile we promote the philosophy that IT delivery teams should work closely with enterprise architects and reuse engineers, if any exist, so that they will better understand and appreciate these issues.
4. Reuse requires investment.  To get beyond ad-hoc reuse your organization will need to invest in a reuse program.  This may include investment in a reuse engineering team, in a reuse repository, in the development/rescue of potentially reusable assets, and the long-term maintenance and support of those assets.  More on these topics in future postings.
5. Your approach to funding will make or break reuse.  Many organizations will institute chargeback schemes to pay for reuse.  The basic strategy is that just like you would pay for commercial software, you should pay for internally developed or purchased assets within your organization.  That way the cost of those assets is shared fairly across the teams that are actually reusing them.  Unfortunately, in practice, chargeback schemes are guaranteed to kill your reuse engineering efforts because you are in effect punishing teams when they reuse things.  A better strategy is to purposefully fund your reuse engineering efforts and then track, often via automated metrics, the impact those efforts have on your organization (so as to justify the investment).

In future blog postings we will explore a goal-driven approach to reuse engineering as well as the workflows associated with reuse engineering.  It is possible, and highly desirable, for organizations to succeed at reuse engineering.  The Disciplined Agile Reuse Engineering process blade provides the guidance you need to do so.

In this blog posting, the latest in our ongoing disciplined agile release management series,  we overview the external workflows that release management is likely to be involved with.

Workflow With Other IT Teams

The following diagram overviews the major workflows that people performing the Release Management activity will have with others.  One interesting aspect of this diagram is that it shows that many IT delivery teams, which may be following different lifecycles or even tailored versions of one of the disciplined agile lifecycles, potentially feed production ready releases into the release management process.  In some organizations you may have a separate release management team doing this work.  Other organizations, particularly those that are well on the way to adopting a disciplined DevOps strategy, will often choose to have the delivery teams themselves do the release management work via a “you build it, you release it, you run it” mindset.  For now our focus is on the activities surrounding release management, not on the potential organizational structures to support it.

The following table summarizes the workflows depicted in the diagram.

This posting, the latest in a series focused on a disciplined agile approach to release management, overviews the activities associated with release management. 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 Release Management process blade and overview its process factors.

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

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

1. Plan IT release schedule.  Your organization’s overall release schedule needs to be planned and communicated.  Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near the Christmas holidays).  There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
2. Schedule solution release.  The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
3. Manage infrastructure configuration.  The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment.  To safely deploy into production you must know what is currently in production and how those hardware and software elements depend on each other.  The more complex your operational infrastructure, and the more IT delivery teams you have, the more important this process factor becomes.
4. Determine production readiness.  Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them.  The bigger and more infrequent your releases, the more this becomes an issue.
5. Support delivery teams.  The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully.  This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments.  The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
6. Govern releases.  Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible.  This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics.

Release Management and DevOps

Release management is an important part of your Disciplined DevOps strategy. Having said that, many IT departments are still in their early days of adopting a DevOps approach yet still effective release management.  The implication is that the way that you approach release management will vary depending on how far down the DevOps adoption path you are.  For example, with no DevOps in place at all your release management activities are likely to be performed by a team that is completely separate from your IT delivery teams.  When you are in the process of adopting a DevOps mindset release management is likely to be a collaborative effort between the IT delivery teams and the release management team.  When you have fully adopted DevOps strategies release management is mostly performed by the delivery teams themselves.

Related Postings

• The Disciplined Agile Release Management process blade
• Why do we need release management?
• DevOps: Strategies for Organizing Release Management
• DevOps: Release Management Part 1
• DevOps: Release Management Part 2
• Release Management: External Workflow

In IT, release management encompasses planning, coordinating, and verifying the deployment of IT solutions into production.  Release management requires collaboration by the IT delivery team(s) producing the solutions and the people responsible for your organization’s operational IT infrastructure.  In the case of organizations with a “you build it, you run it” DevOps mindset these people may be one in the same, although even in these situations you will often find a group of people responsible for governing the overall release management effort.

There are several reasons why enterprises adopt release management strategies:

1. They have a complex operational infrastructure.  The greater the complexity of your operational infrastructure the greater the risk that the release of new functionality into production will break something, hence the greater need for release management.  Operational infrastructures become complex when there are many technologies in place, when there are different versions or configurations of those technologies, and when solutions are highly coupled to one another.  Ideally you should strive to pay down this technical debt.
2. There are many delivery teams working in parallel.  Your operational infrastructure is a shared environment, or more accurately a collection of shared environments, that your IT delivery teams deploy into.  As the number of delivery teams rises, the greater the chance that their release efforts will conflict with one another.
3. IT delivery teams need help to release their solutions into production.  Your IT delivery teams, particularly new ones, may not have much experience deploying solutions into your operational environment.  Your release management team can coach your IT delivery teams in effective release strategies, can guide them in ensuring that their solutions are production ready, and can help in the planning and coordination of their release efforts.

Related Postings

• The Disciplined Agile Release Management process blade
• DevOps: Strategies for Organizing Release Management
• DevOps: Release Management Part 1
• DevOps: Release Management Part 2
• Release Management: A Goal-Driven Approach
• Release Management: External Workflow

In this blog posting, the latest in our ongoing disciplined agile program management series, overviews the workflow internal to program management.

Workflow Within a Program

The workflow within a disciplined agile program is depicted in the following diagram.

As you can see in the workflow diagram, someone in the role of Program Manager coordinates the three leadership teams (described in greater detail in Large Agile Teams):

1. Product Delivery Team.  This team is responsible for dealing with cross-team “management issues” such as moving people between teams, resolving disputes that cross team boundaries, and any coordination issue that doesn’t fall under the purview of the other two leadership teams.  The Program Manager often leads the Product Delivery team, which is made up of the Team Leads from the delivery sub-teams, and may even be a Team Lead of one of the delivery teams as well.
2. Product Owner Team.  This team is responsible for requirements management, prioritizing the work, and assigning work items to the various sub-teams. This team is led by a Chief Product Owner (CPO), not shown, who is often a Product Owner for one more more sub-teams.
3. Architecture Owner Team. The AO team is responsible for facilitating the overall architectural direction of the program, for evolving that vision over time, and for negotiating technical dependencies within the architecture.  This team is led by a Chief Architecture Owner (CAO), also not shown, who is often an Architecture Owner on one or more delivery sub-teams.

The Program Lifecycle

DAD includes a Program lifecycle for a team of teams.  The diagram for this lifecycle is shown below. An important difference between the Disciplined Agile approach and SAFe or LeSS is that the delivery sub-teams may be following different lifecycles.

Disciplined Agile Delivery (DAD) supports several delivery lifecycles, including the Scrum-based agile/basic lifecycle, the Kanban-based lean lifecycle, a continuous delivery lifecycle, and the Lean Startup-based exploratory lifecycle.  Even when the sub teams are following the same lifecycle they may be working to different cadences (or not) – in the Program Management goal diagram we explicitly show that there are several strategies for sub team cadences.

Both diagrams show that some programs may include a parallel independent testing effort in addition to the whole team testing efforts of the sub-teams.  The delivery sub-teams will make their working builds available to the testers on a regular basis, who will integrate all of the builds into their testing environment.  This independent testing effort often addresses end-to-end system integration testing as well as other forms of testing that make better economic sense when done in a centralized manner.  Independent testing is common for large programs that are tackling complex domains or complex technologies or that find themselves in a regulatory environment that requires independent testing.  The SAFe equivalent to a parallel independent test team would be called a system team, in this case one doing system integration plus independent testing.  Same basic concept, slightly different wording.

Related Postings

• Large Agile Teams
• Why do we need agile programs?
• Disciplined Agile Program Management 101
• Disciplined Agile Program Management: A Goal- Driven Approach
• Discplined Agile Program Management: External Workflow