Category Archives: Compliancy

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.

Agile Regulatory Compliance

For further reading about compliancy, please read our detailed blog posting Agile and Regulatory Compliance.

Related Posts

How to make Agile and CMMI work together effectively

Agile vs. CMMI

Our experience is that to make agile and CMMI co-exist effectively is that four things need to occur:

  1. You need to adopt an enterprise view of IT.  Adopting an enterprise view of IT can require an open mind be both CMMI and agile practitioners.  An important implication of enterprise awareness is that different teams are in different situations, therefore they need to tailor their strategy accordingly.  This requires enterprise professionals who work with many project teams to be capable of working with and governing those teams accordingly – they need to work with traditional teams in a traditional manner and agile teams in an agile manner.   For agilists being enterprise aware can be very difficult at first due to the prevalence of a project mindset within the development community.   Agilists need to become disciplined enough to leverage and enhance the existing software and data infrastructure, to follow common guidelines, to work with enterprise professionals such enterprise architects and operations professionals, and to be governed effectively.
  2. You need to focus on quantifiable business value.  Your organization must focus on delivering quantifiable business value to your stakeholders in all activities that you perform.  In other words, perform real process and organization improvement at squeeze out the needless bureaucracy that is all too prevalent in CMMI environments.  We have yet to work with a CMMI organization, including those rated at L4 and L5, that didn’t have huge opportunities for improving their productivity by adopting more agile ways of working.   For example, we often run into existing development processes where a requirements specification is created, then test plans and test cases are written so that the solution may be validated, and traceability maintained between these artifacts (and more) for good measure.  Yes, business value is being delivered via this process, but we can work more effectively while achieving the same goals.  For example, but adopting an acceptance-test driven approach the acceptance tests become both the detailed tests and detailed requirements specification, with full requirements-to-test traceability between them with no extra work to be performed.   By working smarter, not harder, you not only reduce the work required to provide the same business value as before but you do so with a shorter feedback cycle between requirement elicitation and implementation, thereby reducing project risk.
  3. Agile teams must adopt a full delivery lifecycle.  Minimally this lifecycle includes project/team initiation, construction, and deployment activities although enterprise activities such as portfolio management, enterprise architecture, asset management, operations, support, and others should also be considered.  The Disciplined Agile framework includes four delivery lifecycles: The Agile/Basic Lifecycle based on Scrum, The Advanced/Lean Lifecycle based on Kanban, The Exploratory Lifecycle based on Lean Startup, and the Continuous Delivery Lifecycle.
  4. You need to adopt a hybrid approach. Many agile methodologies – including Scrum, XP, AM, Agile Data, Kanban, and more – focus on a subset of the activities required to be CMMI compliant.   Before the advent of DAD you needed to cobble together your own agile methodology to get the job done.   DAD adopts ideas from Scrum, Agile Modeling, Agile Data, XP, Kanban, Lean Software Development, and many more.  The bottom line is that if you intend to address all of the CMMI process areas you will need to adopt a hybrid approach such as DAD or do the work to invent your own.

In the next blog in this series we will explore how Disciplined Agile Delivery (DAD) maps to the CMMI framework.

Are Agile and CMMI compatible?

Answering Your Questions

We’re occasionally asked whether agile and CMMI are compatible, so we thought we’d write a short blog posting on the subject.  The quick answer is yes, but you need to know what you’re doing.  In this article we explore whether organizations are actually combining agile and CMMI in practice and then address some of the rhetoric around this topic.

Survey Says…

The Dr. Dobbs Journal (DDJ) Summer 2012 State of the IT Union Survey examined this issue.  The goal of the survey was to explore whether organizations were successful or unsuccessful at various levels of the scaling factors called out in the Software Development Context Framework (SDCF).  One of the SDCF scaling factors is regulatory compliance, including both legal compliance such as Food and Drug Administration (FDA) compliance as well as self-imposed compliance such as CMMI or ISO 900X.  This survey found that of the respondents whose organizations had achieved success apply agile techniques in practice, 44% indicated that one or more of their project teams had done so when self-imposed compliance requirements were in place.  Of the respondents whose organizations had experienced one or more failed agile projects, 30% indicated that one or more of their projects had self-imposed compliancy requirements.  More recently the DDJ Spring 2014 State of the IT Union Survey found that 44% of agile software development teams (and 43% of non-agile teams) face some sort of compliancy requirement.  The following figure shows that agile teams, just like non-agile teams, are in fact working at scale.

Agile Software Development Scales

The survey results lead me to three important observations.  First and foremost, people are in fact successfully applying agile and CMMI together.  Second, it can be a rocky road when doing so because some organizations are running into problems.   Three, there isn’t any blatantly obvious evidence for or against applying the two together.   Granted, this third observation is based on averages – your organization may have very good reasons to apply the two together.  In particular, I suspect that the organizations applying CMMI and agile together are the ones where they already have a strong-CMMI culture and are now in the process of increasing their productivity through agile and lean techniques.

Reality Over Rhetoric

One only has to spend some time online to discover that when it comes to applying agile and CMMI together there is some questionable rhetoric being bandied about.  We feel it’s important to surface this rhetoric and describe the reality of the situation.  Common agile CMMI rhetoric includes:

  1. Agile and CMMI are incompatible. This is clearly not the case as we learned in the aforementioned surveys.  A quick web search results in many publications on the topic, including case studies. From what we’ve seen most of this problem stems from agile protagonists not understanding CMMI and CMMI protagonists not understanding agile.
  2. Scrum is CMMI level 5. This is nothing more than marketing hogwash.  The reality is that Scrum is a very, very small part of what you need to do to succeed at agile. Scrum’s focus is on some aspects of project leadership and requirements management, and it relies on other methodologies such as Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), and many others to fill in the blanks. Yes, Scrum can be used in CMMI environments but Scrum on its own clearly doesn’t even address all CMMI L2 issues let alone higher levels. Similarly, agile methods such as XP and AM can also be applied in CMMI environments to address portions of one or more process areas in an agile manner.
  3. CMMI doesn’t add value. Empirically you can observe that this is clearly not the case by simply hopping on a flight to Bangalore to see how the Indian IT service providers have leveraged CMMI into a multi-billion dollar industry.   Furthermore there are numerous studies that have shown that as organizations move up CMMI levels their productivity improves (although some have shown that productivity peaks upon achieving CMMI L3, so be careful).  Our experience is that the secret is to keep your CMMI implementation as agile as possible.
  4. CMMI equals needless bureaucracy. The way that an organization addresses CMMI compliancy is up to them. They can choose to adopt a documentation-heavy strategy, which many unfortunately do, or they can choose to adopt a more streamlined agile approach. Many agilists have had very bad experiences in heavy CMMI shops and in many cases that is their only CMMI experience, hence the bitterness regarding CMMI.

In the next posting in this series I’ll discuss how Disciplined Agile Delivery (DAD) and CMMI can potentially fit together.




Agile and Regulatory Compliance

Agile Regulatory Compliance

A common question that we get is whether it’s possible for a team to take an agile approach in a regulatory environment.  The answer of course is a resounding yes, although your approach will need to be tailored to reflect the constraints of the applicable regulation(s).

Let’s explore issues pertaining to compliance:

  1. The regulations vary.  Not all regulations are created equal.  For example, financial regulations such as Sarbanes Oxley (SoX) are typically less stringent than life-critical things such as the various Federal Drug Administration (FDA) regulations.  So, one regulatory compliancy strategy does not fit all and your team will instead need to tailor their agile strategy to reflect the applicable regulations that you face.
  2. Agile teams are working in a regulatory compliance scenarios.  The quick answer is yes.  As you can see in the chart above, the 2016 Agility at Scale study found that two-thirds of agile teams face either regulatory, organizational, or both forms of compliance.
  3. Organizations are succeeding at applying agile within a regulatory regime.  The 2012 Agility at Scale study found that some respondents indicated that their organizations had successfully applied agile strategies with regulatory situations. As you can see in the chart below they are applying agile in all types of regulatory environments, including but not limited to life-critical and financial.  If other organizations are succeeding at doing so perhaps yours can as well.
  4. Organizations are failing at this too.  The 2012 Agility at Scale study also asked if organizations had agile project teams that failed within regulatory situations and respondents indicated that they had.  If other organizations are struggling with agile and regulatory compliance then yours might too, so please consider the advice provided below.
  5. The regulations rarely tell you how to work.  Regulations typically provide criteria that your process needs to meet.  For example they may call out the need to have independent testing, but they won’t say that you need to have an onerous testing phase nor that all testing needs to be done this way.  There you could adopt parallel independent testing in addition to your whole team testing efforts to conform to this requirement.  The implication is that you can tailor your solution delivery process to be as agile as you can while still being compliant – you don’t need to take a waterfall/V-model style approach.
  6. Sometimes compliancy is self imposed.   Some compliancy requirements are not legislated, such as FDA and SoX, but are instead willingly adopted by your organization.  Examples of this include compliancy regimes such as ISO-900X and CMMI, strategies which may have been adopted for marketing reasons (typically by IT service providers) or perhaps process improvement reasons.  As you can see in the chart organizations are both succeeding and failing at applying agile in these situations.
  7. You need to read the regulations.  Our experience is that many organizations will let their more bureaucratic-leaning staff members interpret how to conform to regulations.  Not surprisingly their strategy often involves a lot more paperwork, activities, and checkpoints than is actually needed.  When pragmatic people are asked to interpret regulations you often end up with a more pragramatic response.  So, if you’re in a regulatory environment we’ve found that it behooves you to take the time to read the regulations so that you can streamline how your agile team addresses them.  Fair warning: Most regulations are incredibly dry reading.


Disciplined Agile Delivery (DAD) addresses regulatory compliance issues via several key strategies:

  1. Adopt a hybrid process.  DAD is a hybrid framework that adopts strategies from a range of sources including Scrum, XP, Agile Modeling, Kanban, Unified Process, and many more.  Regulations typically cover a wide range of issues and as a result you need to adopt supporting practices from numerous sources.  This may include management practices from Scrum, agile development practices from XP, agile documentation practices from Agile Modeling, data quality practices from Agile Data, and so on.  The DAD framework has already done the heavy lifting for you by showing how these practices fit together, unlike methods such as Scrum which leave this work up to you.
  2. Adopt a full delivery lifecycle.  Most regulations address the full delivery lifecycle, not just construction.  DAD supports a full delivery lifecyle, in fact it supports several such lifecycles (a Scrum-based lifecycle, a lean lifecycle, a continuous delivery lifecycle, and so on) to reflect the differing contexts faced by teams in typical enterprise environments.
  3. Focus on solutions, not just software.  Disciplined agile teams produce consumable solutions, not just “shippable software”.  DAD recognizes that delivery teams are working on solutions that have a software component, that run on hardware, that are supported by documentation, and that the team may even change the business process around the usage of a system and even the organization structure of the people using it.
  4. Take a goal-driven approach. Recognizing that solution delivery teams find themselves in unique situations, DAD doesn’t prescribe how they should work.  Instead, it focuses on providing advice for how teams can tailor their strategy to reflect that context of the situation that they find themselves in.  DAD does this by promoting a process goal driven approach.  This strategy guides teams through the process decisions that they’re making, some of which will be driven by regulatory compliance.  The DAD framework has already done a lot of the heavy lifting regarding how to tailor your agile process to meeting scaling concerns such as regulatory compliance, large teams, geographically distributed teams, and other issues.  Interestingly, as we’ve written in previous blog postings, the majority of the tailoring effort to address scaling issues such as regulatory compliance is handled by four of the twenty-two process goals: Exploring Initial Scope, Identify Initial Technical Strategy, Move Closer to a Deployable Release, and Coordinating Activities.  A future blog posting will describe exactly how these goals are affected by compliance concerns.
  5. Adopt an explicit governance strategy.  DAD has agile governance strategies built right in, including explicit light-weight milestones, metrics, named phases, and many other aspects of governance expected by many regulations.  Once again, the DAD framework has done a lot of the heavy lifting for you.
  6. Be enterprise aware.  DAD promotes the concept of enterprise awareness, the recognition that agile teams do not work in a vacuum.  This includes strategies for engaging with enterprise architects, how to deal with enhancement requests and defect reports coming in from operations, and how to work with other enterprise professionals.  These can be key issues to understand when tailoring agile to be compliant within an existing organizational ecosystem – your entire process needs to comply to the regulations, not just the development portion of it.

In short, yes it is possible to successfully follow a disciplined agile strategy given the constraints of regulatory compliance.  Contact us at Scott Ambler + Associates if you’d like to hear more.