Avoiding False Dichotomy: “If We Are Agile, We Are Not CMMI Compliant”.

“Our organization is trying to become more agile and we are using agile frameworks to deliver products to our customers. Therefore, it is going to be practically impossible for us to meet CMMI requirements”. – WRONG!

If your organization wants to become Capability Maturity Model Integration (CMMI) compliant because of direct government mandates or because it sub-contracts for a government agency that imposes CMMI requirements or regulations on your company, it does not mean that your organization must abolish the idea of being adaptive, agile, nimble!  Do not throw in a towel!  You can certainly meet and exceed many of those expectations, set by the standards that were, by the way, introduced decades ago!

Below are some ideas for how to meet the requirements of CMMI across all five(5) levels.  Please, keep in mind that these are just the guidelines, and they should not to be considered, as a definitive or prescriptive approach.  Please, note that agile/adaptive ways of working, such as Kanban, Scrum and Large Scale Scrum (LeSS) are used here, as suggested “sources of answers” – where your organization could look  into, to meet CMMI requirements, without sacrificing its adaptiveness/agility.

In order for the below ideas to be relevant, your company is expected to have a very strong understanding of the aforementioned adaptive/agile ways of working.  A failure to do so will render many of the below ideas immaterial and obsolete.

CAPABILITY PROCESS AREAS

• Project Management
  • Project Planning – Although Scrum and Large Scale Scrum (LeSS) where historically introduced for software product development, not project management, each sprint can be treated as a small, independent mini-project.  In each sprint, what remains fixed is its duration and price (cost of all developers combined, sonce it is based on an hourly rate of each developer, multiplied by a total person/hours). What is usually kept flexible – is scope.  So all three project variables are present in each sprint.  With effective sprint planning and capacity/historical velocity/workflow management, a sprint scope can be delivered, accurately.  By the same token, multiple, sequential sprints could be treated as a longer project, with the same three variables in place.  The ladder situation is, sometimes, encountered, when multi-sprint production releases, aligned with business cycles,  are necessary.  However, it is important to understand that, still, each sprint’s deliverable must be represent a potentially shippable product increment (PSPI),whereas if something is released, remains a purely business (product owner) decision, not technical capability.
  • Project Monitoring and Control – In Kanban, the following methods can be effectively used to monitor and control progress of workflow: Cumulative Flow Diagram (CFD), Throughput, Cycle Time, Lead Time, queue WIP management.  In Scrum and LeSS, in addition to Kanban methods, the following methods could be used: Sprint Burn-Up and Burn-Down diagrams, Release Burn-Up and Burn-Down diagrams, Epic Burn-Up and Burn-Down diagrams, etc.  The ladder few are rather workflow management tooling capabilities, than agile concepts, however, if properly used, they may serve the needs of ‘monitoring’ to e.g. meet CMMI requirements.
  • Supplier Agreement Management – On adaptive/agile engagements, any client-to-vendor contractual relationship can be written in a way that takes into account agile ways of working.  For in-depth recommendations on this topic, please refer to “About Contracts That Support Agile Ways of Working“, “Agile Contracts” and Survival List to Vendor Selection on Agile Projects.
  • Integrated Project Management – Considering that each sprint in Scrum is a mini-project, management of multiple sprints, means that there are multiple teams sprinting concurrently with each other, on the same cadence.  This type of synchronization is best to be achieved by using a Large Scale Scrum (LeSS) system that effectively brings together multiple teams that work on the same, widely defined product, operate out of the same product backlog, and serve the same product owner.  Effectively, in LeSS, real-time “project integration” takes on the form of sprint synchronization of multiple teams.  Also, since LeSS is highly advanced organizational design system that supports product centricity, proper LeSS implementation requires a significant amount of investment in learning and education, not just by developers but also by business people and senior executives. LeSS also assumes that organizational design and reporting structure are improved in favor of products, where multiple teams equally share a responsibility of delivering the same widely defined product.
  • Integrated Supplier Management – As mentioned above, in the Supplier Agreement Management section, while dealing with a single supplier/vendor on an adaptive/agile project, your organization should utilize a contractual agreement that is supportive of agile ways of working.  It is critical to realize that  the best way to ensure that contracts are written in ways there are supportive of adaptive/agile ways of working, is by properly educating vendor managers and legal counsels that are responsible for writing and executing such contracts, and then letting them formulate contractual agreements, as per new guidelines.  It is also important to understand what sort of vendor/supplier engagement model your organization is going to implement:  (1) a mix of its internal workers with external workers, supplied by vendor or (2) full outsourcing of an entire project to a vendor company (see the third scenario, at the bottom of this page).  There are certain specific ways that are recommended in each case, in order to ensure an effective large scale adaptive product development: how to mix and match internal assets with external assets.  Especially this becomes critical when an organization needs to leverage multiple external vendors.  Properly designed Large Scale Scrum (LeSS) organizational system can be affectively utilized for this.
  • Integrated Teaming – It is important to realize that in adaptive/agile product development, product management and process management are complementary but not the same.  The former, is typically a responsibility of a product owner, business stakeholders and developers. The latter, is typically a responsibility of scrum masters, organizational design coaches, and executive management.  Similarly to integrated project management, as per above, integrated teaming assumes that multiple teams work in close conjunction, and closely collaborate directly with each other (through code and face-to-face), without intervention of middle managers and translation layers.  Teams are able to accomplish this because they work very synchronously, on the same cadence, integrating their codebase continuously, with every product developer, of each respective team, participating, as well as, explicitly between multiple teams.  This assumes that there is a very close relationship between all product teams that go through planning, refinement and  daily interaction  – together.  Such high degree of synergy and collaboration can be effectively achieved through Large-Scale Scrum (LeSS) system implementation.
  • Risk Management –  Adaptive/agile product development risk management is most effectively achieved by iteratively managing expectations of business stakeholders, users and customers.  Although, risks cannot be completely avoided, they can be significantly reduced when expectations are fairly managed, by reducing cycle time and shortening feedback loops.  In Kanban, Scrum and  Large-Scale Scrum (LeSS) system, this can be achieved by doing consistent spring reviews, as well as single-team and overall retrospectives.  One of the best ways to reduce risks in adaptive/agile product development, is by relieving tension in one of the three corners of the conventional/traditional project management triangle (a.k.a. the ‘iron triangle’) that consists, as mentioned above, of time, budget and scope. It is highly unadvisable in software product development to create this triple constraint rigidity, and this ties back directly to the aforementioned planning and project management and control sections.  Adaptive/agile ways of working also assume that teams emphasize accuracy more than they do precision and, while communicating with business stakeholders, users, and customers, use ranges, such as scope range or date-of-delivery range, not precise values.  For example with respect to your time frames it is highly advisable in adaptive/agile product development to deliver a PSPI in short increments, using short Cycle Time (Scrum)  and Throughput (Kanban).
  • Quantitative Project Management – Similarly to Project Monitoring and Control, as per above, quantitative measurements (metrics), can be effectively collected on adaptive/agile product development initiatives.  In fact, they typically become a free by-product of effective work management and through creation of full transparency, into work that product development teams perform.  Notably, with this approach, an organization is able to significantly reduce costs, associated with redundancy and waste that are, further, due to too many monitoring roles and processes.  Some of the best metrics are gradual maturation of definitions of Ready (DoR) and Done (DoD), as well as an ability to decrease transaction costs and switching costs.  There are many other types of metrics that could be used on micro – and macro-level, for individual and multiple teams.  Some of them are described above in the Project Monitoring and Control section.  However, it is important to understand that metrics should be simple.  One of the biggest advantages of adaptive/agile product development is that, while operating in short iterations, and delivering small increments of a potential shippable product (PSPI), long-term predictions (a.k.a. ‘IOU promissory notes’) become less relevant.  The need for metrics, micro-management and control is inversely related to teams /organizational ability to deliver true business value to users and customers at the end of each sprint.
• Support
  • Software configuration management (SCM)  – One of the main differences between adaptive/agile and traditional ways of managing software configuration changes, is the ownership of responsibilities.  For large scale product development, such as Large-Scale Scrum (LeSS) system, a responsibility for SCM is with product teams that are directly involved in product development.   It is important to understand that in traditional ways of working and managing software configuration, this responsibility is typically dispersed throughout an organization and assigned to dedicated/”special” teams, groups or departments that are not directly involved in product development.  This creates a lot of asynergy and hard dependencies, as well as introduces other organizational challenges, such as loss of true ownership and teams autonomy.   In adaptive/agile ways of working, software configuration management belongs to software product development teams, not to ‘third parties’.
  • Process Quality Assurance – Agile/adaptive teams ensure that their processes are of high quality, by practicing frequent inspection adaptation, consistently, throughout each sprint.  Due to a short sprint duration and frequent feedback, learning is more effective than in traditional, long-term delivery cycles.  At the end of each sprint, there is a standard touch point, for each product development team  – a team retrospective, where an entire team reflects on recently implemented process, and decides whether or not anything has to be improved.  Typically, these sessions are facilitated by skilled process improvement specialists, such as seasoned Scrum Masters and team-level coaches.  In large scale product development, where Large-Scale Scrum (LeSS) organizational design system is used, there is an  additional opportunity, to inspect and adapt at the end of each sprint, to ensure that systemic improvements are applied to all of the teams, involved in product development.  This is done at an Overall Retrospective, where Scrum Masters, selected team members, a product owner and empowered senior managers are in attendance (importantly, managers, typically, walk away with many to-do items).
  • Product Quality Assurance –  one of the biggest advantages of agile/adaptive ways to develop a software product is that quality assurance takes place not at a specific, single point of time but throughout an entire sprint.  This ensures that all work items go thought gradual workflow and all stages SDLC, in one sprint and this includes thorough, end-to-end testing.  Importantly, in Kanban, Scrum and Large-Scale Scrum (LeSS), the responsibility for quality assurance sits not with a dedicated single function specialty team or individual but rather belongs to an entire product development group (2-8 product development teams).  On each team, there is more than just one person that is responsible for quality assurance of PSPI.   This is a major distinction between adaptive/agile teams, made of multi-skilled, full-stack product developers and traditional teams that are made of single-function specialty developers.  It is also important note that adaptive/agile teams very heavily rely on modern engineering practices, including unit testing, TDD, ATDD, BDD and CI/CD.
  • Causal Decision Analysis and Resolution – One of the most powerful techniques that is used in organizational design system Large-Scale Scrum (LeSS) is causal-loop diagramming (CLD). This is a lightweight, coaching and facilitation tool that allows for deep systemic analysis of organizational dynamics, while leveraging system thinking and systemic problem solving.  Organizations that implement LeSS for large scale product development have a huge advantage over other organizations, because of their ability to get to an original root cause of their systemic issues and ability to resolve them in the more effective and sustainable way.  In fact, those organizations that go through a methodical and thoughtful LeSS learning journey, insure that their organization leaders, senior managers and internal coaches get a good handle of the CLD tools/techniques.
• Engineering
  • Requirements Management – In Scrum and LeSS, collection of requirements is a primary responsibility of teams, working in tight conjunction with users and customers.  Requirements may flow from various channels and different business domains/ lines of business (LOB), and represent needs of different types of users and stakeholders.  Ultimately, the responsibility of requirements prioritization is given to a product owner.  It is important to understand that in LeSS, due to the size of a product group (up to 50 to 60 developers/2-8 teams could be involved in development) and cognitive load limitations of a product owner, it is highly recommended that clarification of requirements, as much as possible, flows directly from users and customers to developers, whereas prioritization and strategic decision making power still resides in hands of a product owner.
  • Requirements Development – This part of agile/adaptive SDLC completely belongs to teams that are involved in software product development.  In Kanban, Scrum and LeSS, developers, collect requirements, by directly interacting with users and stakeholders, and develop them into workable features, each and every sprint.
  • Technical Solution –  In  adaptive/agile ways of working, such as Kanban, Scrum and LeSS system, this responsibility, in full, belongs to the teams that are involved in product development.
  • Product Integration – In  adaptive/agile ways of working, such as Kanban, Scrum and LeSS system, this responsibility, in full, belongs to the teams that are involved in product development.
  • Verification – In  adaptive/agile ways of working, such as Kanban, Scrum and LeSS system, this responsibility, in full, belongs to the teams that are involved in product development.
  • Validation – In  adaptive/agile ways of working, such as Kanban, Scrum and LeSS system, this responsibility, in full, belongs to the teams that are involved in product development.

MATURITY PROCESS AREAS (from low to high)

Note: only maturity process areas that have organizational impact are listed:

• Organizational Training  – Organizational design and system thinking-based training, used in Large-Scale Scrum (LeSS), focuses on the whole organizational system and assumes that the whole organization (“parallel organization” concept is applied) undergoes a comprehensive bottom-up and top-down training, delivered by experienced and accredited LeSS trainers.  Delivering this learning is pivotal in guiding organizations towards a more streamlined, value-driven, and human-centric ways of working, and it comes at the very early stage of a LeSS adoption experiment.  LeSS training is based on deep system thinking and leverages system modeling (mentioned above), as means of understanding an organizational system and searching for ways to improve it in a continuous and sustainable way.  In LeSS training, the following critical organizational enablers are thoroughly covered; budgeting/finance, HR norms and policies, side strategies, vendor management, as well as many other organizational dimensions that are typically left out in role-based types of training.
• Organizational Process Definition – Upon completing LeSS organizational design training, an organization is typically offered comprehensive and continuous coaching/consulting support.  It is imperative that such support comes from experienced and well-versed organizational design consultants, coaches and trainers.  As a part of this longer, continuous phase, multiple processes are defined and introduced to an organization.  This is a result of a thorough assessment of an organizational design, as well as individuals roles and responsibilities of people that are involved, and everyone’s career path/motivation, compensation, skill set and professional capabilities.  Based on this, a minimum set of process requirements is defined, with efforts made to avoid unnecessary complexity, redundancy and waste that could result from an excessive process implementation.  Processes are added gradually, bottom-up, in such a way that only minimalistic complexities are added.
• Organizational Process Focus – This process area is directly dependent on Organizational Process Definition area described above.  In organizational systems such as Large-Scale Scrum (LeSS), the responsibility and focus of process improvements lies on very seasoned Scrum Masters that are responsible for multiple teams, within the same LeSS product group.  Also, during the initial phase of a LeSS adoption. seasoned team-level coaches are also present and support multi-team dynamics.  Furthermore, organization design coaches (a.k.a. enterprise coaches) are responsible for guiding the whole organization and helping senior management to focus on organization-wide processes and impediments.   In larger LeSS implementations, such as LeSS Huge, there is even stronger reliance on organizational design consultants and coaches that help senior executives to focus on a process. This is because in LeSS Huge hundreds-to-thousands of people might be involved.
• Organizational Process Performance – Similarly to organizational processes definition and focus, in LeSS, organizational performance (measurements) is a joint responsibility of senior executives and organizational design coaches/consultants.  While many measurements and assessments can be done throughout each sprint, it is common to discuss organizational performance and additional organizational improvements at the end of each Sprint during an Overall Retrospective (OP).  As mentioned above, one of the most powerful facilitation/coaching tools that is used at OP, is system modeling/system thinking that helps with deep systemic learning.
• Organizational Innovation – Similarly to organizational processes definition, focus and performance measurements, this is a joint responsibility of senior executives and organizational design coaches/consultants.