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

• Project Management
  • Project Planning – Although Scrum and LeSS are used for product development, not project management, each sprint can be treated, as a small, independent mini-project.  What remains fixed is duration of a sprint and its fixed price (cost of all developers combined, based on an average hourly rate and total person/hours). What is usually kept, relatively, flexible – is scope.  With effective sprint planning and capacity/historical velocity/workflow management, a sprint scope can be delivered, relatively accurately.  So, effectively, all three project variables are present in each sprint.  By the same token, multiple sequential sprints could be treated as a bigger project, with the same three variables being present.  The ladder situation is, sometimes, encountered, when multi-sprint production releases, aligned with business cycles,  are necessary.  Note: it is important understand that each sprint’s deliverable must be represent a potentially shippable product increment (PSPI) and whether something is released is a purely business (product owner) decision.
  • 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 additional to Kanban methods, the following methods could be used: Sprint Burn-Up and Burn-Down diagrams…..
  • Supplier Agreement Management – On agile engagement’s, any client-to-vendor contractual relationship can be written in a way that takes into account adaptive/agile ways of working. For more comprehensive steps, 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 that sprint 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 product, operate out of the same product backlog, and serve the same product owner.  LeSS – is highly advanced organizational design system that supports product centricity.  Proper LeSS implementation requires a significant amount of investment in learning and education and involves senior executives, as well as developers. It also assumes that organizational design and reporting structure I improved in favor of products interesting and enablement of multiple teams working synchronously and the same widely defined product.
  • Integrated Supplier Management – As mentioned above, while dealing with a single supplier/vendor on adaptive/agile project, your organization must utilize a contractual agreement that is supportive of agile ways of working.  It is important 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.  It is also important to understand what sort of vendor / supplier engagement model your organization is willing to implement:  (1) mixing its internal workers with external workers, supplied by vendor or (2) fully outsourcing an entire project to a vendor company.  There are certain specific ways that are recommended for 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 organizational (LeSS) system can be affectively utilized for this.
  • Integrated Teaming – It is important to realize that in adaptive/agile product development, the process of product management and the process of 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 with each other, while closely collaborating directly with each other, without intervention of middle tiers and translation layers.  Teams are able to accomplish this because they work very synchronously, on the same cadence, integrating continuously their codebase among developers of the same respective team, as well as between multiple teams.  This assumes that there is a very close relationship between multiple 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.  Risk cannot be completely eradicated and avoided however they can be significantly reduced when expectations are managed while using short cycle time and effective short feedback loops.  In Kanban, scrum and  Large-Scale Scrum (Less) system can be achieved by doing consistent spring reviews, single-team and overall retrospectives.  One of the best ways to reduce risks in adaptive / agile product development, is by not hard-fixing all three corners of the conventional / traditional project management triangle (a.k.a. the ‘iron triangle’): Time, Budget and Scope. It is highly unadvisable in software product development to create this triple constraint rigidity.  This ties back directly to the aforementioned planning and project management and control sections.  Adaptive/agile ways of work and 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 become a free by-product of effective work management and creation of full transparency and traceability of work back to developers and teams.  Notably with this approach an organization is able to significantly reduce costs, associated with redundancy and waste that is due to too many monitoring roles and processes.  Some of the best metrics known are gradual maturation and the ability to meet definitions of Ready (DoR) and Done (DoD), as well as the 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.  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.  Important to recognize that the need for metrics, micro-management and control is inversely related to teams /organizational ability to deliver true business value and users and customers.
• Support
  • Software configuration management (SCM)  – The major difference between adaptive/agile vs. traditional ways of managing software configuration changes, is the ownership of responsibilities.  For large scale product development, where Large-Scale Scrum (LeSS) system is being implemented, the 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 assigned to an individual team, group or department that is not directly involved in product development.  This creates a lot of asynergy and hard dependencies, as well as introduces other organizational weaknesses, such as segregation of ownership ownership and loss of teams autonomy.   In adaptive/agile ways of working software configuration management belongs to software product development teams.
  • Process and Product Quality Assurance
  • Measurement and Analysis Causal Analysis and Resolution
  • Decision Analysis and Resolution
  • Organizational Environment for Integration (IPPD)
• Engineering
  • Requirements Management
  • Requirements Development
  • Technical Solution
  • Product Integration
  • Verification
  • Validation

MATURITY PROCESS AREAS (from low to high)

• Configuration Management
• Process and Product Quality Assurance
• Measurement and Analysis
• Supplier Agreement Management
• Project Monitoring and Control
• Project Planning
• Requirements Management
• Integrated Supplier Management (SS only)
• Org. Environment for Integration (IPPD only)
• Decision Analysis and Resolution
• Integrated Teaming (IPPD only)
• Risk Management
• Integrated Product and Process Development
• Integrated Project Management
• Organizational Training
• Organizational Process Definition
• Organizational Process Focus
• Validation
• Verification
• Product Integration
• Technical Solution
• Requirements Development
• Quantitative Project Management
• Organizational Process Performance
• Causal Analysis and Resolution
• Organizational Innovation and Deployment