The term “technical debt” refers to any quality issues within the implementation of an IT solution that hampers your ability to work with or evolve that solution. Technical debt is often thought of as a source code problem, but you can also have technical debt in your user interface design, in your data sources (a huge problem that gets very little attention in the literature), in your network architecture, and in many other places. The existence of technical debt incurs “interest payments” in the form of higher costs to evolve your solution, longer times to do so, and greater overall risk in doing so.
One of the issues that we explore in the 2015 Q1 Agile State of the Art Survey was how often agile teams release their software-based solutions. We asked about how often they release internally, say into a
pre-production testing environment or a demo environment, and how often they released into production. This insight summarizes what we found.
In the 2015 Q1 Agile State of the Art Survey we asked how long the sprint/iteration length was for agile teams. For the team who were following an agile lifecycle the survey found that two thirds of teams had a two-week iteration length, and that over 90% have iteration lengths of three weeks or less.
Overall, on average Lean teams enjoy a higher success rate than Agile/Iterative teams which in turn fare better than Traditional/Ad-Hoc teams.
Overall, when it comes to delivering a quality product, stakeholder satisfaction, providing good return on investment (ROI), and delivering in a timely manner modern software development approaches work better than either traditional or no process at all.
The problem with that definition of success is that it breaks what is referred to as the “iron triangle”.
When people define success criteria for software development projects, and when given the choice, they clearly lean towards agile philosophies.
A common question that we get from customers is how do the various software development paradigms compare? Here at SA+A we prefer to answer questions like this with industry data whenever possible.
Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you.
I was recently asked the question “What happens when the Product Owner and the Architecture Owner don’t agree?” and realized this is an issue for everyone on DA teams in general. Here’s my advice.
© 2015 Scott Ambler + Associates