The quick answer is of course “Yes”. ??
A couple of years ago we caused a bit of confusion when we expanded the scope of Disciplined Agile Delivery (DAD) to address the activities of an information technology (IT) department. When we did this we realized that the scope of the toolkit and the name no longer matched, so we decided to rebrand to be simply the “Disciplined Agile (DA)” toolkit. Having said that, sometimes it makes sense to say DAD and sometime DA depending on what you’re focusing on at the time.
The Scope of Disciplined Agile (DA)
As you can see in the following diagram, which depicts the scope of the DA toolkit, it’s clear why there has been some confusion because DA covers a lot of ground.
Let’s explore each aspect depicted in the diagram:
The first “1.0 release” was the original Disciplined Agile Delivery book in June of 2012. As the title suggests the focus was on DAD, although it laid the groundwork for Disciplined DevOps in that it baked in the development side of DevOps right into DAD. In 2015 we began publishing our work in both Disciplined DevOps and Disciplined Agile IT (DAIT) and renamed the toolkit to Disciplined Agile (DA) to reflect this expanded scope. Since 2017 we have begun to flesh out Disciplined Agile Enterprise strategies and will soon begin the share them here on this site.
We often hear that agile software development is fine for small co-located teams, but that you couldn’t possibly take an outsourcing approach with agile. The customer organizations would love to do agile but are convinced that vendors are unable to do so, and the vendor organizations typically say they’d love to be agile but that the customers don’t ask them to work that way. It’s a fair question to ask if agile and outsourcing are being combined in practice, so we decided to look into this issue.
The following diagram summarizes the responses to our question from our 2016 Agility at Scale study around whether agile teams were organizationally distributed (one of the tactical scaling factors potentially faced by agile teams). As you can see, over half of agile teams are organizationally distributed in some way, with 58% of agile teams including contractors, consultants, or outsourcers in some way. Interestingly, about one agile team in six includes outsourcing.
Answering the question of how to be successful at agile and outsourcing is worthy of a detailed article in its own right, something we’ll do in the near future. Until then, here are some initial thoughts based on our observations at multiple organizations around the world:
We will write a more detailed article that expands on these points in the near future. Stay tuned!
We often hear that agile software development is fine when you face a simple problem, but that agile isn’t sufficient for more difficult problems. Of course this falsehood is promoted by people who have little or no agile experience, or who have been involved with a failed “agile adoption” (usually these teams adopted ad hoc strategies thinking they were agile). Anyway, we decided to look into whether agile teams are taking on hard domain problems in practice.
The following diagram summarizes the responses to our question around agile teams and compliance from our 2016 Agility at Scale study. As you can see, 40% of respondents indicated that their agile team faced either complex or very complex problems, and that a further 38% faced medium complexity. Interestingly, only one in eight respondents said that their team faced a straight forward problem.
The bottom line is that agile strategies, and in particular disciplined agile strategies, are in fact applicable for taking on complex problems. More importantly, this is happening in practice around the world on a regular basis.
We often hear that agile is great for simple situations but as soon as you face compliancy issues that it doesn’t work. Is it possible to be agile when you face regulatory compliance, such as PCI and FDA compliancy? Is it possible to be agile when you face organizational compliance, such as working in a CMMI regime? Important questions that we decided to look into.
The following diagram summarizes the responses to our question around agile teams and compliance from our 2016 Agility at Scale study. As you can see, 62% of respondents indicated that their agile team faced some form of regulatory compliance, 20% some form of organizational compliance, and 15% said both. In fact, two-thirds of agile teams operate under one or more compliancy requirements.
For further reading about compliancy, please read our detailed blog posting Agile and Regulatory Compliance.
Many people, particularly those new to agile, will tell you that agile teams must be small and co-located. That is certainly a smart way of organizing a team, but is isn’t required. In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located. In practice, not theory.
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 geographic distribution.
The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space. Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.
Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice. Yes, geographically distributed agile is different than near-located 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 geographic distribution. In fact, you may find our article around geographically distributed agile teams to be an interesting read.