Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Scott Ambler
Do Agile Teams Pay Down Technical Debt in Practice?
| Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. Technical debt can be compared to monetary debt in that if it is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Important questions to ask are “How common is it for agile teams to run into technical debt in practice?” and “When they do run into technical debt, are they paying it down?” The following diagram summarizes responses to our question from our 2016 Agility at Scale study around technical complexity. As you can see 84% of agile teams are working with legacy functionality and 51% with legacy data sources (so yes, the vast majority of teams are working in environments that are likely to have some form of technical debt). More importantly, 38% of teams are actively paying down functional technical debt and 32% are paying down data technical debt (48% are paying down one or the other).
Related Posts
|
Can You Outsource and Still Be Agile?
| 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! Related Posts
|
Do Agile Teams Take on Hard Problems?
| 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. Related Posts |
Do Agile Teams Face Regulatory Compliance?
| 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. Related Posts |
How
| We are often told that agile teams should be whole, that they should have sufficient people, funding, and skills to fulfill their mission. The idea is that this reduces the dependencies that your team has on others, enabling them to make decisions and to collaborate more effectively. But, is this actually happening in practice? Are agile teams truly whole, or do they still need to collaborate with other teams (hopefully productively) to get the job done? Being strong believers in empiricism over rhetoric we decided to look into this issue. 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 infographic summarizes the findings from the question that explored whether agile delivery teams need to work with external teams or groups to get their work done – in other words, are agile teams truly whole or do they rely on others? As you can see, 96% of respondents indicated that in practice their team had to work with one or more other teams, leading to the conclusion that very few agile teams appear to be truly whole.
One of the fundamental principles underlying the Disciplined Agile (DA) toolkit is that disciplined agilists should be enterprise aware – they should recognize that they need to collaborate with others outside of their team, that they should work towards a common organizational vision, and that they should strive to do what is best for the organization and not just what is convenient for them. Given that agile teams are collaborating with others in practice, it is clear that this philosophy of being enterprise aware is important. The following diagram presents the results from the survey question in greater detail. You can obtain the source data, a copy of the original questions, and a slide deck key diagrams at the 2016 Agility at Scale survey page.
Related Posts: |