CMMI

Capability Maturity Model Integration

What is CMMI?
A model for optimizing development processes.

Helps organizations streamline process improvement, encouraging a productive,

efficient culture that decreases risks in software, product and service development.

The CMMI model is not prescriptive; it describes what to do to improve an

organization’s capabilities, not how to do it.
Why use CMMI?
A primary goal of CMMI is the creation of “reliable environments where products,
services and departments are proactive, efficient and productive.”

CMMI helps a business quickly understand its current level of capability and
performance in the context of its own objectives and as compared with similar
businesses and organizations.

If business needs and objectives are not being met, CMMI practices can guide
systematic and effective improvement to elevate and optimize performance to better
serve the needs of the business.
Why ARK should consider it
We could use it as a base reference, a path, for how to manage the improvements and
build the right habit. I don't think we should start training or appraisals.

The processes under evaluation are:

Development
Service: delivery, incident
People compensations, staffing, comunication, career
DevOps, Waterfall, Agile, CMMI
What these words means?
Do you use implement them in ARK?
DevOps: a Culture, not a Ruleset
Not talking about Azure DevOps

DevOps is a culture and set of broad concepts and practices to break down the silo
between developers, tester and system operators (and security). A major part of a
DevOps culture is collaboration.

The key to achieve the DevOps velocity is developer autonomy.

DevOps consists in a set of best-practices intended to reduce the time between the
definition of a change to a system and the change itself being placed into normal
production empowering developers with the tools to make it happen.

Automation, Automation, Automation.

DevOps: Where is ARK?
Ark implements DevOps since more than 4 years.

4y ago: Automated Testing, Git-Flow, Logging Standardization

3y ago: Continuos Delivery, unknownly seed of DevSecOps
2y ago: Standard Infrastructure and Application Configuration (Infrastructure as
Code)
1y ago: Standardization of Metrics and E2E Tracing
current: Standard Alerts, Standardization DevSecOps
future: keep the pace of industry ...
Agile: a philosophy
Agile is a collaborative, self-organizing, cross-functional approach to completing work
and requirements.

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

https://agilemanifesto.org/
Agile: Key Principles
priority is to satisfy the customer through early and continuous delivery
welcome changing requirements, even late in project development
business people and developers must work together daily throughout the project
the most efficient and effective method of conveying information to and within a
development team is direct conversation
continuous attention to technical excellence and good design
the best architectures, requirements, and designs emerge from self-organizing
teams
Agile: and the stories?!
Agile philosophy has been declined in multiple methodologies and frameworks.

Scrum: an Agile framework in which "Stories" are planned in Sprints and the daily
interactions within the team (including business users) are managed via defined chores
(daily standup, sprint plan, sprint retrospectives, etc.) with responsabilities assigned to
roles (Product Owner, Scrum Master, etc.) and monitored (sprint burndown, project
burndown).

Kanban: an Agile framework in which "new" Stories are sorted in priority, started in
priority order and with a strict guarantees on the number of Stories "in progress". That
is to force the delivery of that. Multiple developers can work on the same Story. There
are no roles.

There are others: Lean, XP, RAD, etc.

Agile: Where is ARK? (1)
Agile in ARK is a conflictual. Inherently, if you look at ARK as a single big-team, you can
find most of the philosophy present (this discussion included). But from a project
execution perspective, we are not really Agile.

Agile is for continuos products, not much for projects.

We tried to be Agile, but we never grasped it. We don't have nor a Kanban, nor a Scrum
model.
Agile: Where is ARK? (2)
Our main problem are small projects, with "virtual" teams executing them. Impossible
to adopt a Scrum model. Would be possible considering them all a single big Agile
project named "ARK" but the overhead of PM/Stakeholders/Planning makes difficult to
plan and deliver value.

We're loosly implement a Scrumban with a 1-week plan assessement (not really a
Sprint).

Agile is hard. Agile teams need to be highly skilled in a variety of areas, including
knowledge of the most common Agile methodology frameworks.
Agile: Where is ARK? (3)
Scrum Master: responsible for ensuring the team lives agile values and principles and
follows the processes and practices that the team agreed they would use.

Not to be mixed with C&C PMs. Scrum Master are heralds of team, coaching them,
shielding them, ensure they are in a position to, and do, follow Agile practices.

In ARK this is logically covered by Lab Manager.

Agile: Where is ARK? (4)
Product Owner: a product owner is the leader responsible for maximizing the value of
the products created by a scrum development team. Is the sole person responsible for
managing the Product Backlog. Clearly identify and describe backlog items in order to
build a shared understanding of the problem and of the designed solution and
prioritize them.

How to identify him? It's the guy you first call when you have a question on how/why
a product work. He's single point of information that keeps the team focused and
reduces churn resulting from waiting for answers, or conflicting priorities.

In ARK this is a bit mixed but covered mostly covered by the Lead Developer.

They interface with the Stakeholders (PM is the main one), describe the solution, splits
work in single requirements, sort them in priority with the info gathered, builds an
overall plan.
Agile: Where is ARK? (5)
And the ARK PM?

The ARK PM under the Agile unbrella is mostly mapped to the "Customer" or "Client". Is
the liason/facade of the real Client, that tries the product at each release and feedbacks
new requirement / bug / changes as he would be the client.
Waterfall: old (but gold) methodology
The Waterfall Model is also referred to as a linear-sequential life cycle model. It was the
first Process Model to be introduced. Waterfall project management originated in
construction and manufacturing—industries where one phase must be completed
before another begins.

Because Waterfall does not allow going back to a prior phase, project requirements
need to be clear up front. This methodology begins with gathering and documenting
requirements and then making these requirements accessible to team members.

Team members also document their work as the project continues through each phase.
Ideally, team members can exit or enter a project without disrupting workflow, making
Waterfall a good solution for teams expecting changes in bandwidth.
Waterfall: basic developemnt flow
1. Gather and document requirements
2. Design
3. Implementation
4. UAT
5. Release
6. Maintenance

Each time you fail, you go back a step, paying a big price.
Waterfall: the pro/cons
Waterfall is pretty easy to understand how it works. Thus, you can manage your projects
effortlessly and move forward without any hurdles.

When you are using Waterfall, the processes are made to be simple and
straightforward.

It’s risky because you can’t make any (big) changes to the plan/outcome without
stopping and going back.

Another thing is that the client can’t see results until in the late stages of development,
which takes a few months.

For you to use the Waterfall model successfully, you’ll have to know what product your
customers desire before developing it.
Waterfall: Where is ARK?
Ark more often than not, plan/manage as Waterfall.

There is a need for "when is done?" "how much it costs?" "A timeline?" questions that
are not part of Agile. Agile has two of Budget, TimeFrame or Features. Waterfall aim for
3 of them.

Ark is probably Wagile: short waterfall projects/phases.

Wagile software development becomes vital when you are dealing with different
stakeholders. It adds great value with enterprise customers/stakeholders. These
customers have fixed scope, fixed budget and fixed time projects that they expect you
to execute. On top of it, they are only concerned with the status updates that in which
phase project currently is. Given this waterfall approach, it becomes challenging to
follow agile.
CMMI + DevOps
CMMI in 2018 released the V2.0 of it's model. It aim to be less "waterfally" and more
"agile". It targets both Agile and DevOps and the sinergies between them.

It's of particular interest the association of CMMI with DevOps since the two are not in
contradiction. The same is not true with Agile given that Agile born exactly to oppose
hightly regulated models like Waterfall and anything the CMMI would try to implement.
And Azure DevOps CMMI ?!
Yeah, it all started from that ...

Azure DevOps CMMI could be a good bridge. It maps nicely to a rappresentation we

know and use in the documentations we have. It may help add traceablity and play well
with DevOps culture. It feels a natural rappresentation.

It adds usual Project Management items, like Issue, Risk, Impediments.

It helps organizing the project in Iterations (Phases) and Requirements in a hierarchy.

It made me discover CMMI and doing this research.

We're thinking of tring out in "Indisponibilità Centrali"

Yeah, good ... now what?
Our biggest challange lies in the fact that we have one big team with a lot of
stakeholders/clients. It's almost 1:1 ... we have Artesian, K4view, Axpo plus the
wanted addition: MET, ER, etc.
Agile would call in ARK for a single PO, a single Scrum Master, for all ARK
Development members. Some may argue to split in 2 Teams but, with 2 POs
feeding the 2 Teams (not IT vs IRL, but mixed Teams)
We're either too big or too small depending how you see it
An usual problem in Scrum are POs overstepping Scrum Masters acting as team
boss (old style PM). In ARK we have Scrum Masters that often fills PO role
CMMI could help us asses and confirm what we miss for completing Maturity Level
2, aiming for Level 3
Yeah, good ... now what?
IF we want to be more Agile we need to:

Increase team cooperation with SME/Analysis, that must be part of the

"Development" team
Have few ARK POs that act as "Product Owner" (per area?) in which the Product is
not "the XY project" or the "ZZ Product" but is the would satisfaction of the
internal/external stakeholders
OR
Have one PO per-project/product paired with the PM

In both cases they have to write clear quality functional/technical requirements and
prioritize them to match the stakeholder (PM/Client/AM) needs. Be the herald of the
development Team.
Yeah, good ... now what?
IF not?

Honestly, got no idea. But ...

PRs welcome
Proposal - General
Adopt a more Agile process.

View ARK as a single Cross-Functional (Analysis, Service, Frontend, Graphic etc.)

Team, with the future aim to split in two.
Manage projects with only rough initial estimate and Business goals.
Adopt Azure DevOps CMMI "process" to keep a more natural story-vs-requirement
model
Introduce one or two PO as part of the Development team.
Formalize the current 1-week Scrumban approach. No ScrumMaster, Kanban picks,
formal weekly plan meeting and sharing with committment
Business people and Developers must work together daily throughout the project,
as member of the Team
Proposal - DevOps rappresentation (BABOK+CMMI)
Proposal - DevOps rappresentation (BABOK+CMMI)
Business Requirement: the organizational requirement in the context of the
project/product. What is the business value that this project/product will cover.
Most of the time in ARK projects is one. ER had many. MET a few.
Stakeholder Requirement: the user requirement from a business need/perspective.
A project "Feature" for a given Persona. "As MO, I want an automatic send of the
Internal Tickets so that I can spend more time in PR (coffee machine talks)"
Functional/Non-Functional Requirement: all the single, small, requirements
required to satisfy the Stakeholders in the context of the overall Business value
delivered. Configure the schedule, monitor the execution, receive an error
notification on fail, define what an Internal Ticket is, configure mappings and so on.
Risk: some possible impediment ahead if certain conditions are realized
Issue: or impediment. Something that is blocking or affecting the project execution
Proposal - Responsabilities - PM
Does manage:

Need: capture and analyze the business requirements, creating and scoping the
project
Budget: ensure that the project is delivered on-time and budget
Client: handle the relationship with the client and all stakeholders, ensure are
happy, and onboard
Risk: perform risk management mitigating project risks and resolving issues
Milestone: devies and maintain a long term plan, project phases and milestones
Maintainance: structures an appropriate transition to Maintenance, ensure the
project has an handover and doesn't require further PM
Proposal - Responsabilities - PO
Does manage:

Backlog: orchestrate the backlog, gathers and write requirements, ensure the Team
operate in the correct priority to balance the time/budget/scope triade
Visibility: ensure that both the Team and PM have visibility on the project
progression and contents. Tracks activity and project metrics.
Planning: oversee the actual execution of the project by planning, refining and
reviewing outcomes of each sprint. Accept and welcome changes.
Delivery: ensures continuous delivery to (PM/Business Analyst) and possibly to
clients too
Proposal - Responsabilities - Business Analyst
Does own:

Requirements: create and maintains a clear requirement catalog by interacting with

stakeholders, identifyng Needs and Business Value
Product Quality: verifies each release, improves by studying current practices and
designing modifications and new requirements on each release and afterward
Value: identifies, evaluate and estimate the Value for the client/customer to drive
PM budget acquisition (ROI)
Documentation: writes and shares clear documentation, beautiful diagrams,
expressive use-cases. Ensure an ubiquitus language in adopted through the project
Proposal - Responsabilities - Scrum(ban) Master
Does own:

Team Members: ensure the Team morale, committment, training and career.
Overseer that the Team can self-organize and operate efficiently, that tasks are
(self)assigned to the right members with a balance between project and growth
Process: ensure the process is clear, understood, followed indipendently from the
Project in a standard way
Chores: ensure weekly plans, daily standups, handvoers are correctly executed
driving the outcome actions
Culture: ensure DevOps culture and Agile philosophy are understood and eboied,
promoting the right habits and demoting the bad ones
[Bonus] Timezone: ensure everyone adopts UTC as timezone in any comunication
Responsabilites - KAM (copied)
Develop a solid and trusting relationship between major key clients and company
Resolve key client issues and complaints
Develop a complete understanding of key account needs
Manage communications between key clients and internal teams
Manage account team assigned to each client
Strategic planning to improve client results and anticipate changes
Negotiate contracts with the client and establish a timeline of performance
Establish and overseeing company budgets and client budgets
Plan and present reports on account progress, goals, and quarterly initiatives
Meet all client needs and deliverables according to proposed timelines
Analyse client data to provide customer relationship management
Expand relationships and bring in new clients
Responsabilites - PMO (copied)
Establish guidelines and a framework for project managers and departmental
teams to adhere to
Audit projects in a program and profile feasibility on the grounds of time, data,
costs and resources needed ensuring that multiple projects run in a repeatable and
sustainable manner
Ensure the right people have access to the right, and relevant information in order
to make strategic decisions
Manage resources ensuring the right resources are available to deliver high-
visibility, high-return projects. Acquire resources, if necessary, before piped
projects commence
Ensure both the required skills and bandwidth are available future availability,
preventing a misstep in project planning
Responsabilites - PMO (copied)
Facilitate collaborative knowledge transfers. Make project plans, reviews, templates
and documentation widely available, saving time and costs that would have
otherwise gone into rework
Mentor and develop project manager’s competencies enhancing his/her ability to
lead and manage project execution
Offers support to key decision makers by tracking project portfolio health and
ascertaining dependencies between projects
Gathering data about project progress, status of milestones, goals reached. Create
and make available resports that capture project health and provide insights into
processes and frameworks that work
Open Points
This scaffold project needs to be augumented to cover the AM Team as
Stakeholder so that BA has the responsability to gather their requirements and PO
to plan and execute them, delivering incrementally and ensuring an handover.
Good reads
https://sunscrapers.com/blog/project-management-methodologies-agile-waterfall-
scrum-kanban/

https://agilemanifesto.org/

https://www.atlassian.com/devops#frameworks

https://hackernoon.com/agile-vs-waterfall-how-to-choose-the-right-methodology-for-
your-project-f7da3yoz

https://triciasinclair.com/2020/01/06/azure-devops-processes-part-3-overview-of-the-
cmmi-process/

https://www.youtube.com/watch?v=woLAYjYmR34

https://www.lucidchart.com/blog/product-owner-roles-and-responsibilities
Good reads
https://www.scrum.org/resources/what-is-a-product-owner

https://www.scaledagileframework.com/product-owner/

https://www.scrum.org/resources/blog/can-development-team-member-work-more-
one-team-time

https://devops.com/continuous-security-through-developer-empowerment/