Since Disciplined Agile (DA) joined the PMI family in August 2019 we've gotten a collection of questions from people along the lines of "Why is there a difference between the advice in DA and PMI's advice?" So I thought I would write a few blogs examining why that is. This is the first.
There are several reasons why there are differences between existing DA and existing (non-DA) PMI materials:
My point is that there are very good reasons for the differences between what is in DA and what PMI has traditionally focused on. These differences are an important aspect of the value proposition of DA for PMI, and more importantly for our membership, because we can learn from these differences and then improve and grow based on those learnings. We're currently evolving DA based on the great material encompassed by the existing PMI standards and practice guides and our hope is that the existing PMI offerings will evolve to reflect Disciplined Agile ways of working (WoW) too.
In the next blog in this series I will do a deep dive into the differences between DA's take on Program Management and the PMI Program Management Standard. I suspect this will help to make some of the ideas in this blog more concrete and it will certainly make the opportunity before us a bit more explicit.
The contrite answer is that they’re as large as they need to be, and the contrite agile answer is that they’re as small as they can be. Now that we’ve gotten the contrite answers out of the way, how large are agile teams in practice?
In November of 2016 we ran the 2016 Agility at Scale survey. It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on. The following graph summarizes the responses around team size.
This year’s survey found that roughly half (48%) of agile teams are more than 10 people in size and one-quarter are more than 20 people in size. These findings are similar to what we’ve found in the past with both the 2012 Agility at Scale survey and the 2009 Agility at Scale survey.
In short, don’t let anyone tell you that you can’t do agile with a large team because others are clearly doing so in practice. Yes, large team agile is different than small team agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery. The Disciplined Agile (DA) toolkit provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including team size. In fact, you may find our article around large agile teams to be of interest.
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):
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.
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:
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:
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.
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.