We've have recently updated our thinking around the tactical scaling factors that we apply in DA to help understand the context faced by a team or organization. Figure 1 depicts the original scaling factors and Figure 2 the new scaling factors. Below we discuss what changed and how this can affect anyone taking a Disciplined Agile (DA) certification exam.
The changes we made were motivated by our experiences applying the scaling factors outside of IT teams. Originally these scaling factors were described by the Software Development Context Framework (SDCF) which we evolved into the Situation Context Framework (SCF) in late 2020. Here is what has changed:
As you can see in Scaling Factors we have made it clear that the exam will test you for knowledge about the original version for now (in Figure 1) and that when we update the courseware and exam to reflect this update we will let you know. In general our intent is that whenever material on the web gets ahead of what is being tested for that we'll make it clear that this has happened. More on this in a future blog posting.
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.