Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

SCRUM Meets CMMi


New Areas

There are two issues—internal quality audits, and measuring and analysis—which we weren't dealing with, but which must be covered to reach CMMi Level 2. The first one gets integrated in the quality assurance area, and the second is a new area altogether.

A formal QA process had a certain impact: We were focused on testing, but QA activities as such were not considered. We were not having internal interviews checking whether things were getting done.

QA asked us to perform regular checks on our practices. We then ran checklists at the end of each sprint, making sure we followed our own rules. Repositories are where they should be, backups scheduled, tasks correctly linked to their corresponding requisites, solved tasks have their resolution fields correctly filled in and have an associated developer, worked hours, and so on. A plan is also created specifying when these checks have to be performed.

Measuring and analysis is an area we weren't addressing until the last CMMi adoption phase. Indeed, we were gathering different data about our development, but we never had time to analyze it. We set some measures aligned to our business practices and project-management concerns. We had a look at our internal tracking tool to see how long bug solving took during the last sprint, how much time we were working on new functionalities, doing design, coding, and so on. Estimate deviation was also computed and presented to the team during sprint review meetings. We already had this data in different Defect Control reports, but we weren't paying attention to it.

Because we analyze our metrics, we were able to decrease unplanned working time. The time we were working on initially unplanned tasks was a big percentage of the total sprint time, and during the last sprints it has been getting shorter.

What Went Right

What has helped us improve? For one thing, we're more confident of our process. We know we are doing what we are supposed to do according to our own procedures. CMMi greatly helped here. Also, project management tasks were easy to adapt.

We were only using expert-based estimation techniques or our best efforts most of the time. We moved to a more structured estimation making use of historical data and PERT estimation. Finally, we introduced risks as a new work item category on Defect Control. This way we didn't need an extra tool to deal with risks, and the available query mechanisms also helped here.

The Tough Points

The really painful points were related to requisite management. Defining dependencies between requisites was a big task, as was getting used to defining and managing fine-grained requirements. The traceability matrix was also tough.

Conclusion

At the end of the day, CMMi helps us do what we say we are doing—forcing us to follow our own process. It also makes us aware of our own working practices, even the ones we aren't performing on a daily basis.

The effort to get adapted to CMMi has fired an internal process that makes us keep an eye on best software practices. This is not a consequence of CMMi, but the improvement process itself. Now we are running internal training on patterns, good coding practices, and restarting code inspections and informal reviews, something we run on the past and wanted to pick up again. And we have gained a deeper knowledge on CMMi itself, something that, as toolmakers, helps us better understand our customers.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.