{"id":1538,"date":"2015-12-06T14:38:09","date_gmt":"2015-12-06T13:38:09","guid":{"rendered":"http:\/\/qualilogy.com\/en\/?p=1538"},"modified":"2015-12-07T16:43:58","modified_gmt":"2015-12-07T15:43:58","slug":"software-quality-maturity-model-technical-debt","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/en\/software-quality-maturity-model-technical-debt\/","title":{"rendered":"Software Quality Maturity Model & Technical Debt"},"content":{"rendered":"

\"Software<\/a>I suppose that you all know<\/span> CMMI<\/span>?<\/span> This model<\/span> developed by the<\/span> Software Engineering Institute<\/span> provides<\/span> five<\/span> levels of maturity<\/span> in order to measure<\/span> the quality of IT<\/span> services, and<\/span> best practices<\/span> associated with<\/span> this scale of five levels<\/span>, in order to<\/span> progress through<\/span> it.<\/span> <\/span><\/p>\n

I will not<\/span> write a whole<\/span> post<\/span> on this model,<\/span> it is<\/span> not the<\/span> subject of this article<\/span>, but I will try to present it simply,\u00a0<\/span>as I<\/span> could summarize<\/span> it to someone who<\/span> knows nothing about<\/span> project management <\/span>and<\/span> application development<\/span>. <\/span><\/span><\/p>\n

CMMI, the different levels<\/span><\/span><\/h2>\n

The model starts at level 1 where no process is defined. <\/span>This is what I call the level of the champions or, the stuff of heroes, because the success of a project depends on the presence of a champion, such as an expert in the technologies used on it or an experienced project manager<\/span>. <\/span>In short, at least one person, usually well known, always appreciated and who generally ends up allocated to projects of highest priority. <\/span>The failure of other projects does not encourage the organization to improve its practices.
\n<\/span><\/span><\/p>\n

The objective of level 2 (“Managed” in CMMI terminology) is to put in place processes that allow to overcome champions and make sure that any team can realize successfully any project by implementing them. <\/span>This is what I call ‘replicate the success’ independently of individuals.<\/span><\/span><\/p>\n

These processes are then adjusted (Level 3 “Defined”), that is to say, customized according to the project, with loops of improvement to capitalize on each experience. <\/span>Level 4 (“Quantitatively Managed”) implements metrics and statistical measures to control the processes, and thus lay the foundation for Level 5 (“Optimized”) in which the organization works in a constant process of optimization.<\/span><\/p>\n

CMMI level zero<\/h2>\n

I have always been surprised that the model starts at level 1, since in fact at this level, there is nothing, no process, only perfect amateurism. <\/span>But it allowed me to define what I call the “CMMI level zero”, that well describes some organizations that I have known, and for which the company culture promotes and encourages the emergence of champions. <\/span>Instead of seeking to progress to level 2 where the “indispensable people” are not necessary for the success of a project, managers looks unfavorably at any time spent into setting up any process<\/span>, even as simple as a light documentation to reproduce correctly repeatable project’s tasks and ensuring their continuity in the absence of “champions”. They may even create inextricable situations of extreme difficulty to prove that <\/span>they are made of “the stuff of heroes”. <\/span>Like “Let’s change everything on last day to work overnight and deliver tomorrow in a hurry”.<\/p>\n

Generally, these managers divide the world between “winners”, a small group to which they obviously consider that they belong, and “losers”, those weak and capricious people who are generally reluctant to work in the permanent chaos generated by an elitist hierarchy<\/span>. <\/span>These managers certainly do not want to progress up the CMMI scale but on the contrary to evolve down a CMMI level zero of quality where any improvement idea is suspect and whimsical.<\/span><\/span><\/p>\n

A<\/span> maturity model<\/span> of software quality<\/span><\/span><\/h2>\n

The<\/span> CMMI model<\/span> has lost<\/span> popularity since<\/span> some<\/span> companies<\/span> supposedly<\/span> certified<\/span> at the highest level<\/span> have actually<\/span> proved<\/span> unable to<\/span> deliver a<\/span> proper<\/span> service quality.<\/span> But I believe it<\/span> has<\/span> the advantage<\/span>\u00a0to be logical<\/span> and<\/span> easily understandable<\/span> by<\/span> everyone,<\/span> and<\/span> in many areas<\/span>.<\/span><\/p>\n

So I did imagine the following model<\/a> that I propose<\/span> to customers who want<\/span> to measure their<\/span> level of maturity<\/span> in Software<\/span> Quality.<\/span><\/span><\/p>\n

\"Qualilogy_Software_Quality_Maturity_Model\"<\/a><\/p>\n

At the first level, there are no processes or any structures to manage Software Quality. <\/span>This does not mean that there are no initiatives in this area, but it’s only by a few champions who decide by themselves to install on their project a code analysis tool, <\/span>versions control or to track bugs and change requests.
\n<\/span><\/span><\/p>\n

Level two is characterized by a reactive attitude to quality problems: the organization seeks to identify software defects and non-compliance of good programming practices that might impact users and endanger the business of the company, or <\/span>cause delays in the delivery of applications and increase maintenance costs. <\/span>At this level, software quality management is usually done by a dedicated structure, which installs and centrally manages a quality platform, that projects can join according to processes not always very flexible and often <\/span>considered as restrictive. <\/span>This team usually delivers on-demand services like Quality Gates to approve or reject the delivery of a\u00a0 new release by an outsourcer, and sometimes does assessments for the management.<\/span><\/span><\/p>\n

Level three allows us to switch to a proactive attitude in which we no longer simply identify and respond reactively to defects, but try to prevent them proactively, and as soon as possible in the <\/span>project lifecycle. <\/span>This requires a process of Continuous Integration and usually some Agile practices.<\/span><\/span><\/p>\n

At level four, metrics are used to measure and control Software Quality in all aspects of project management. <\/span>Service providers must comply with SLAs (Service Level Agreement) that incorporate them. <\/span>Benchmarkings are done to measure the quality of service among providers and compile a ranking highly appreciated by the Purchasing or Procurement department in charge of negotiating prices with them: “Sir, you went from 5th to 7th place this quarter. You have to do something. I am waiting for <\/span>an effort from you”. <\/span>IT directions use Quality measures in order to draw a map of their information systems and to define a strategy for each block of applications.<\/span><\/span><\/p>\n

At level five, projects are encouraged to optimize the management of Quality by pioneering new practices such as code reviews, Test Driven Development or eXtreme Programming (XP<\/span>). <\/span>The results on Software Quality are measured and compared to determine which of these practices are most profitable in the short, medium or long term. <\/span>Trainings and workshops are conducted in order to spread the best practices and encourage their adoption.<\/span><\/span><\/p>\n

Maturity and Technical Debt<\/span><\/span><\/h2>\n

Measuring Technical Debt is useful at all levels. <\/span>At level one, we might find a few champions who know the metaphor, but this will be isolated initiatives, and moreover not always understood by management.
\n<\/span><\/span><\/p>\n

Assessments at level 2 may rely on an evaluation of the Technical Debt, especially when management hesitates about the strategy for an application. <\/span>I frequently used it, based on certain criteria, such as the criticality of the application and its alignment with the business. <\/span>For example, within the same company, new markets with high growth will need new applications where time-to-market, reliability and performance will be critical to create a differentiation from the competition and gain precious <\/span>market shares. <\/span>On older markets, we will find a strategy of maintaining margins: therefore, IT will focus on compliance with budgets, and our assessment of the Technical Debt will then be aligned with the maintainability of applications.
\n<\/span><\/span><\/p>\n

It is always important to align Technical Debt on the business when you have to answer questions to the management and propose different strategies and associated action plans: outsourcing of an application, knowledge transfer to another internal team <\/span>(possibly composed of external developers), refactoring, reengineering (see our serie of posts on this subject<\/a>). <\/span>For a quality assessment, evaluating the Technical Debt is a real added value for the customer.<\/span><\/span><\/p>\n

At level 3, Technical Debt is measured daily or at least on a frequent basis by the project team to avoid as soon as possible any inflation of the debt and its interests. <\/span>Technical debt is thus managed at each iteration of the project and not specifically at the end of it (Quality Gate) or occasionally (assessment) as at level 2.<\/span><\/p>\n

At Level 4, the Technical Debt is measured with the objective of containing it and not to grow the interest on the debt as at level 3 but also in a normalized way on all projects. <\/span>This translates into SLAs for external suppliers. <\/span>For example:
\n<\/span><\/p>\n