Project Management

Disciplined Agile

by , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Hybrid | Improvement | inception | Inception phase | Kanban | Large Teams | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | Workflow | show all posts

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

Combining Agile and CMMI? Then You Better Be Disciplined

Categories: CMMI

Agile vs. CMMI

One of the great advantages of agile and lean software development is the wealth of practices, techniques and strategies available to you.  This is also one of its greatest challenges because without something like the DA toolkit it’s difficult to know what to choose and how to fit them together. The DA toolkit adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense, methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DA the mortar to fit the bricks together effectively.

Another strategy to process improvement is captured by the Capability Maturity Model Integrated (CMMI)-Development (CMMI-Dev) approach.  With this strategy organizations will organize their improvement efforts around the CMMI process areas, which has the effect of local optimization of each process area at the expense of the overall flow and efficiency within your software process. The fact that CMMI-Level 5, which few organizations achieve in practice, focuses on process optimization belies this point that overall flow tends to be an afterthought in CMMI environments.

It is possible to combine agile and CMMI approaches together, as a quick Internet search will reveal.  There appears to be a fair bit of evidence showing that applying agile within CMMI environments appears to improve the situation.  It is our opinion that applying CMMI to agile teams tends to decrease their effectiveness in practice.

A better strategy is to first apply the DA toolkit with the goal of streamlining your overall software process.  Then if, and only if, you need to be CMMI-compliant you should make changes to your process to become compliant.   As we show in Mapping CMMI-Dev to Disciplined Agile the DA toolkit can be fully CMMI-compliant. The DA framework in effect shows how to weave the various process areas together.   For example, the Produce a Potentially Consumable Solution process goal includes process factors such as Needs Exploration, Solution Exploration, and Planning which map to aspects of Requirements Development (RD), Technical Solution (TS), and Integrated Project Management (IPM) CMMI process areas respectively.  By starting with DA, you will tailor a light-weight software process to meet your actual needs while only requiring a few (hopefully) minor tweaks so that you can easily pass a SCAMPI assessment.  In short, get the process right and then make it CMMI compliant – focusing on CMMI-compliancy will almost assuredly guarantee you have a software process that is heavier than it needs to be.

Via the combination of supporting multiple lifecycles and lightweight process tailoring via application of process goals the DA toolkit provides a context-sensitive and scalable approach to the agile software process.   Furthermore, the DA toolkit presents time-oriented advice, e.g. at this point in time here’s what you need to do and here’s how it fits together, that is actionable by agile teams. In short, the toolkit takes the mystery out of how all of these agile and lean techniques work together in practice.

Our fundamental advice is to avoid CMMI if at all possible.  If you then your best bet is to take a Disciplined Agile approach to CMMI compliancy.

 

Posted by Scott Ambler on: February 24, 2016 08:48 PM | Permalink | Comments (0)

Principles for Effective Software Process Toolkits

Principles

The Disciplined Agile process decision toolkit is guided by the following principles:

  1. Choice is good, and making informed choices is better.  Every team is a collection of unique individuals that face a unique situation within the context of a unique organization. One process size does not fit all. To provide choice the DA toolkit supports several delivery lifecycles and is process goal driven. Most importantly the DA toolkit describes the tradeoffs involved with a myriad of agile and non-agile practices enabling people to make intelligent decisions regarding which practices to adopt given the current situation that they face.
  2. Optimize the whole. The DA toolkit addresses the full IT lifecycle, showing how it all fits together. Without an understanding of the larger process environment teams run the risk of locally optimizing their own processes to the detriment of the whole. For example, your data management team may have their own streamlined process based on traditional DAMA strategies, your delivery team may have their streamlined process based on the principles of the Agile Manifesto, and your operations team may have their streamlined process based on ITIL. Yet your overall process is ineffective because these three locally optimized strategies contradict and degrade one another when combined.
  3. Every team owns its process. Teams, and the individuals on them, must be free to improve the way that they work based on their learnings over time. In agile parlance we say that these teams “own their process”.
  4. Improve continuously. Individuals, teams, and organizations must strive to continuously learn and improve the way that they work. The DA toolkit includes the process goal Improve Team Process and Environment which describes options for doing exactly what its name implies. It also has an explicit process blade Continuous Improvement that describes strategies for sharing improvements across teams, thereby speeding up your organization’s process improvement efforts.
  5. Embrace process change. IT departments are complex adaptive systems. One implication of this is that any improvements that a team makes may change the way that they work with other teams, motivating process improvements within those teams. Those changes may motivate improvements within other teams and so on. Disciplined agile teams are enterprise aware and understand that they will need to work with other teams to help them to understand and adopt new innovations, and be prepared to be helped by others to do the same.
  6. Repeatable results are far more important than repeatable processes. Effective teams focus on producing repeatable results, such as delivering high-quality software that meets stakeholder needs in a timely and cost effective manner.  Because each team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  Each team in your organization must be allowed to follow their version of the process, ideally sharing similar process components defined by a common process framework, to achieve the results required of them.
  7. Empiricism is far more important than theory. Observing how well a technique works in practice, and more importantly the context of the situations in which it (doesn’t) work is far more valuable to practitioners than theories or prognostications about what should work. Theory has its place, but it is a poor cousin to empiricism. The DA toolkit was originally developed based on observations of dozens of organizations worldwide, and has evolved since then based on learnings from many more. Furthermore it is backed up by our ongoing industry research.

IT departments are unique, complex adaptive systems. Anyone working in such environments needs a process framework that is sufficiently flexible to address the range of situations faced by your teams. The Disciplined Agile process decision framework is light-weight yet sufficiently flexible to support scaling at both the tactical and strategic levels.

Translations

Posted by Scott Ambler on: September 28, 2015 06:27 AM | Permalink | Comments (0)

How to make Agile and CMMI work together effectively

Categories: CMMI, Compliancy

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 (DA) toolkit 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.

Posted by Scott Ambler on: June 19, 2015 03:45 PM | Permalink | Comments (0)

Are Agile and CMMI compatible?

Categories: CMMI, Compliancy

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.

 

 

 

Posted by Scott Ambler on: June 18, 2015 09:57 AM | Permalink | Comments (0)
ADVERTISEMENTS

"Ambition is like a frog sitting on a Venus Flytrap. The flytrap can bite and bite, but it won't bother the frog because it only has little tiny plant teeth. But some other stuff could happen and it could be like ambition."

- Jack Handey

ADVERTISEMENT

Sponsors