Disciplined Agile

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 Situation Context Framework (SCF).  One of the SCF 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.

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.

This blog posting has been replaced by:

• Enterprise Architecture Workflow - Internal
• Enterprise Architecture Workflow - External

This blog posting has been replaced by Enterprise Architecture Practices.

This blog posting has been replaced by Enterprise Architecture Team Structures.

Organizations face an increasingly competitive marketplace.  To be competitive, organizations must be able to react to environmental changes and bring new offerings to market quickly.  This requires an adaptive approach to IT, which in turn requires a flexible and malleable approach to enterprise architecture.  To succeed in this new organizational climate enterprise architects require a new mindset, and new ways of working, that reflect the realities that they now face.

In this blog posting we describe a disciplined agile mindset for enterprise architects.  The following terms describe this mindset:

• Collaborative.  First and foremost, disciplined agile enterprise architects (EAs) collaborate closely with their stakeholders.  These stakeholders include business executives, IT executives, IT operations staff, and of course IT solution delivery teams.  Disciplined agile EAs will spend the majority of their time working with stakeholders.
• Learning oriented.  Every day, disciplined agile EAs strive to learn more about the people they are working with, about the business, about the business environment, about the technology and its application, and about the process they are following.
• Sharing. Disciplined agile EAs, and disciplined agilists in general, constantly look for opportunities to share their skills and knowledge with others.  An important part of their job is to help those around them to get better.
• Business focused.  Disciplined agile EAs must have an understanding and appreciation of the business and the way that it operates to effectively interact with, and support, business leaders.
• Multidisciplinary.  Enterprise architects will often start their architecture career as a solution architect, or a data architect, or a business architect, or some other architecture specialty.  Although these are good starting points, enterprise architects need to consider a wider range of issues than those focused on by each of these specialties.  Just as enterprise architecture frameworks such as TOGAF, Zachman, DODAF and others all take a multi-view approach, disciplined agile EAs must have the skills, or be in the process of gaining them, to address a wide range of views.
• Evolutionary. Disciplined agile EAs work in an evolutionary manner.  As you see in the following diagram, when your enterprise architecture team is first formed it may invest a bit of time to perform some initial architecture envisioning.  The team should come to an agreement around their overall vision and get some of the fundamentals captured.  Then the EAs will work with business stakeholders to understand and guide their vision for their lines of business, in particular how they can leverage technology more effectively to provide greater value to the organization.  The EAs will also work closely with IT delivery teams, often taking on the role of architecture owner on the team, so as to help guide and coach the team in architectural skills and concepts. The EAs will also meet on a regular basis, perhaps weekly for a couple of hours, to share what they’ve learned amongst themselves to evolve the architecture assets based on their learnings.  More on this evolutionary approach in a future blog posting.

• Practical.  Disciplined agile EAs are not afraid to get their hands dirty, which is why they will work collaboratively with their stakeholders.  They recognize that for developers, who are important stakeholders of their enterprise architecture efforts, that the proof is in the code.  As a result disciplined agile EAs will produce working code examples as the primary component of their reference architectures.  They realize that developers are much more likely to work with (and then copy) high-quality working code than they are to read a detailed white paper or detailed model extolling the virtues of some architectural concept.
• Pragmatic. Disciplined agile EAs know when to trade-off short and long-term gains and more importantly can help guide their stakeholders through these decisions while coaching them on the implications of what they’re doing.
• Improvement oriented.  Disciplined agile EAs are always looking for ways to streamline the processes that they run into.
• Reuse.  Disciplined agile EAs promote a reuse mindset with both their business stakeholders and with IT delivery teams.  To achieve reuse on a large scale within your organization there needs to be a guiding vision, and that vision is provided by your enterprise architects.  More on this in coming blog postings.
• Technical debt savvy.  Disciplined agile EAs should be a driving force within your organization for addressing technical debt.  They will guide and coach IT delivery teams on both avoiding new debt and on removing old debt.  In parallel they will work with business leaders to understand the implications of technical debt and help guide them in supporting IT delivery teams in addressing it.
• Technical.  And finally yes, disciplined agile EAs must have a technical background so that they understand the implications of the technologies in use (either now or in the future) within their organization.  As noted earlier, a critical strategy for keeping their technical skills fresh is to collaborate with IT delivery teams on a regular basis.

All the features on this list should sound like common sense – that’s because they are.  It’s probable that you’ve worked with enterprise architects in the past whose mindset exhibited many of these features, but did they exhibit all of them?  Likely not.  No matter how good you are, there is always room for improvement.

Related Readings

• The Enterprise Architecture Process Blade
• Agile Enterprise Architecture 101
• Agile Enterprise Architecture Team Structures
• Disciplined Agile Enterprise Architecture: A Goal-Driven Approach
• Disciplined Agile Enterprise Architecture: Workflow
• DevOps Strategies: Enterprise Architecture