Disciplined Agile

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

An IT program is a large IT delivery team composed of two or more sub-teams.  The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders.  In this blog posting we examine some of the reasons why large IT delivery teams are formed and strategies to reduce or even eliminate the need for such teams.

There are several reasons why large IT delivery teams exist in the first place:

1. Some endeavours are inherently big. Sometimes an organization will decide to take on a complex effort, such as developing an operating system, an air traffic control system, a financial transaction process system at a bank, and many other examples.
2. Overly-specialized staff promote larger teams.  When IT staff are narrowly focused it requires many people to work, at least part time, on a team so that the team has sufficient skills to get the job done.  When people are generalizing specialists your teams become much smaller and collaborative.
3. Overly bureaucratic processes promote larger teams.  Sometimes the systemic bureacracy in the organization requires large numbers of people to address that bureaucracy.  I once assessed a eighty-person project team who were doing work that only required between ten and fifteen people to do the “real work” and everyone else to conform to the overhead of their traditional CMMI-compliant process.  Sadly they didn’t rework the team and failed to produce anything after three years and many millions of dollars of investment.  As an aside, it is possible to effectively combine CMMI and disciplined agile approaches, but you need to overcome the cultural dissonance of the two paradigms.
4. Working on large teams can lead to greater rewards.  Similarly, someone is “empire building” and purposefully creates a large team so that they will be rewarded for doing so.  We have worked in two organizations where before their agile transformation the pay grade of a manager was determined by the number of people the person managed.  Worse yet, in one organization the people on the larger teams tended to get better bonuses, and quicker promotions, than people on smaller teams regardless of the actual ability of the team to deliver value to the organization.

In our opinion only the first reason is a valid one for building a large agile team.  The other reasons reflect aspects of organizational cultures that need to be fixed in time.  Luckily, there are several strategies that you can employ to reduce the size of a team:

1. Reorganize the problem into a collection of smaller problems.  Disaggregation of a large problem is performed through a combination of agile envisioning and agile business analysis. This is a key responsibility of your product management efforts: to feed reasonably-sized portions of work to IT delivery teams.
2. Reduce the problem.  Sometimes a large problem can be shrunk down through pruning features out of the vision, or at least by deferring them until later.
3. Address your organization’s culture. As we discussed earlier, most of the reasons that organizations build large IT delivery teams are the result of cultural challenges.  Fix the real problem by adopting agile and lean ways of thinking and working.
4. Organize the large team into a collection of smaller teams.  In other words, create a program.

When you find yourself in a situation where you need a large IT delivery team, and those situations do exist in many organizations, and you can’t find a way to reduce the size of the team, then you will need to adopt strategies to coordinate that team.  The disciplined agile project management blade describes such strategies.

Related Postings

• Large Agile Teams
• Disciplined Agile Program Management 101
• Disciplined Agile Program Management: A Goal- Driven Approach
• Discplined Agile Program Management: External Workflow
• Disciplined Agile Program Management: Internal Workflow

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

Workflow With Other IT Teams

The following diagram overviews the major workflows that a disciplined agile program is associated with.  Note that feedback is implied in the diagram.  For example, where you see the Technology Roadmap and Guidance flow from Enterprise Architecture to Program Management there is an implied feedback loop from the program to the enterprise architects.  Also note that the workflows do not necessarily imply that artifacts exist.  For example, the data guidance workflow from Data Management could be a conversation with a data management person, it could be a concise description of data standards, or it could be detailed meta data – or combinations thereof.  A second example would be a program providing their development intelligence to the IT governance team through automated rollup of metric data via your organizations dashboard technology.

The following table summarizes the workflows depicted in the diagram.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group.  In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team.  Some organizations may choose to have a separate group for each process blade.  And of course the organizational structure will evolve over time as your various teams learn how to work with one another.  Every organization is different.

Program Management and DevOps

A common question that we’ve gotten is how program management is affected by DevOps. For example, you see in the diagram that Operations, Support, and Release Management (amongst others) are shown as things that are external to Program Management.  Remember that the focus here is on process, not on team organization.  For example, in organizations with a disciplined DevOps strategy in place it is very common to see program teams taking on the responsibilities of operating and supporting their own systems in production, and of doing the work to release their solutions into production.  In organizations without a strong DevOps mindset (yet), you are likely to find that operations, support, and release management are done by separate groups outside of your program team.  Context counts, and it’s good to have a process framework that is flexible enough to support the situation that you find yourself in.

Related Postings

• Large Agile Teams
• Why Do We Need Agile Programs?
• Disciplined Agile Program Management 101
• Disciplined Agile Program Management: A Goal- Driven Approach
• Disciplined Agile Program Management: Internal Workflow

Enterprise architecture, when performed in a disciplined agile manner, is an important enabler of agile software delivery.  This is true for several reasons:

1. Common architecture enables agile teams to focus on value creation.  A common enterprise architecture enables reuse across delivery teams.  When agile teams have high-quality assets – such as micro-services, legacy data sources, and frameworks – available to reuse they are able to focus on creating new value for their stakeholders and not on reinventing new versions of existing assets.
2. Common technical guidance enables greater consistency between teams.  When team follow effective, common conventions it results in greater quality.   This makes it easier to learn about assets that are new to them, in particular existing source code, and to evolve those assets as needed.  Greater consistency also makes it easier for people to move between teams because it will be easier for them to come up to speed on what the new team is doing and to share their skills with those team members.
3. Agile architectures enable disaggregation.  When your solutions are built from loosely coupled, highly cohesive components it is easier to spread development work across smaller teams.  This reduces overall risk and organizational complexity, which in turn reduces time-to-delivery.  It also allows agile teams to focus on what they’re building instead of coordinating with other teams or mocking out the (undelivered) work of other teams.
4. Common infrastructure enables continuous delivery.  When there is a common technical infrastructure to IT delivery teams to deploy into it is easier to deploy.  The easier it is to deploy, the more often it makes sense to deploy.
5. Enterprise architecture scales agile.  A disciplined agile approach to enterprise architecture enables organizations to scale agile strategies “horizontally” across their entire IT department.