Many Teams Are Regulated
According to the survey, 44% of software teams face some sort of compliance issue, another complexity factor, which did not vary by paradigm. Looking a bit deeper into data, 19% of teams face self-imposed compliance (for example, CMMI/ISO) and 32% have legislated (such as FDA regulations or SoX) compliance. Compliance often increases the bureaucracy and thus expands the schedule and cost risk. However, legislated compliance exists to motivate teams to reduce domain-related risks, such as not letting people come to harm in the case of health regulations or your organization not coming to harm in the case of financial regulations.
Legislated regulations typically focus on risk management, particularly around requirements and testing, two areas where disciplined Agile strategies shine. Disciplined Agile teams, particularly those in life-critical regulatory situations, will adopt acceptance test-driven development, also known as behavior driven development (BDD), as well as developer-level TDD strategies to address these sorts of risks. These practices, particularly when combined, result in detailed executable specifications that are in perfect sync with production code, provide full traceability from requirements to design to code to tests, and do so in a provable manner. The downside is that they require greater skill and discipline from the development team. A less sophisticated approach, which is still far too common on traditional teams and even some Agile teams, is to capture requirement, design, and test specification as detailed documents, to then review and baseline these documents, to adopt onerous change management processes, and to manually maintain traceability between all of these artifacts. Not only is this approach expensive and time consuming, in practice, it proves to be brittle, morale-draining, and it requires a host of expensive tools to succeed. In both cases, regulatory compliance is addressed by increased process complexity, making things that much harder for development teams.
Agile Teams Get Better Results
Software development teams work in a range of situations, and in fact, every team is in a unique situation. The implication is that we need to tailor our approach, including our team structures, our processes, and our work environment, to reflect the risks faced by the team. Interestingly, the survey found that on average Agile software development teams outperformed non-Agile teams when it came to providing return on investment (ROI), developing quality solutions, producing solutions that address the needs of stakeholders, and delivering in a timely manner. Clearly, these are all results that stakeholders find important. Furthermore, Agile teams enjoy higher team morale, which in turn leads to increased productivity and staff retention.
I have argued for years, based on both experience and on research results, that business stakeholders are far more interested in repeatable results than they are in repeatable processes. Stakeholders want to spend their IT investment wisely, they want IT solutions that meet their real needs, they want sufficient quality, and they want these solutions in a timely manner. They don't really care how we pull this off.
Given the range complexities faced by software development teams, it is clear that we need to be flexible in our approach. A team of five people will work differently than a team of 20, which in turn works differently than a team of 200. A co-located team will work differently than a team that is dispersed, which in turn works differently than a team of teams spread across locations or even organizations. A team facing great technical complexity will work differently than a team facing little complexity. A team facing a difficult domain problem will work differently than a team facing a problem they've solved before. A team in a life-critical regulatory situation will work differently than a team only facing financial regulations, which in turn works differently than a team facing no regulations at all. Different teams in different situations require different organizational structures, different tailoring of their software process, and different tooling configurations. One size does not fit all, nor will it ever.
The need for greater flexibility within development teams can make it more difficult to govern development teams, to support them via enterprise architecture and data management strategies, and to even to staff said teams. Software development can be very, very hard indeed.
The survey results, including the source data and the original questions as they were asked, are available free of charge at the 2014 Software Development at Scale Survey Results page. Results of previous surveys can be found at Surveys Exploring the Current State of Information Technology Practices.
The Non-Existent Software Crisis: Debunking the Chaos Report explores how people actually prefer to define success, and shows there's a clear desire for repeatable results over processes.
For a detailed discussion of technical debt and its implications, the On Technical Debt site is a great starting point.
The complexity factors that software development teams face are described in The Software Development Context Framework and Does Your Team Own Its Process or Merely Rent It? works through the implications of tailoring your approach to address these complexity factors.
September 2014 IT State of the Union Survey
I invite you to fill out the September 2014 State of the IT Union Survey. The goal of this ongoing survey series is to find out what IT professionals are actually doing in practice. The survey should take you less than five minutes to complete, and your privacy will be completely protected.
The results of this survey will be summarized in a forthcoming article. This is an open survey, so the source data (without identifying information, so as to protect your privacy), a summary slide deck, and the original source questions will be posted so that others may analyze the data for their own purposes. Data from previous surveys has been used by university students and professors for research, and I hope the same will be true of the data from this survey. The results from several other surveys are already posted, so please feel free to take advantage of this resource.
Surveys such as this are not only a great way for you to compare your team with the rest of the industry, they're also an opportunity for you to give back to the rest of the community by sharing your experience.