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


Agile Concerns

During the first adoption cycle, we had to make some subtle modifications to our SCRUM process, some considered as Agile showstoppers—registering working hours, for instance. When we started using Defect Control as our internal bug-tracking and project-management tool, it didn't support worked hours or estimates. We added a module to let developers tell how long they worked on a certain task, and how long they needed to finish it; see Figure 5.

[Click image to view at full size]

Figure 4: Version control.

[Click image to view at full size]

Figure 5: Registering work hours.

While estimation clearly adapts to SCRUM, registering working hours is decidedly antiagile. However, developers got used to introducing information about the tasks they were working on each day, and providing working/remaining hours didn't appear as a problem. Working time is not used as a staff-control mechanism, but for project-control. We managed to build a team, so sharing goals and having a strong motivation let us think of worked-hours registering as a mechanism to create a database of historical data and not anything else; see Software Estimation, by Steve McConnell (www.stevemcconnell.com/est.htm).

The benefits of having such data are obvious: You create your own historical data that is useful to enhance estimates. For example, we formerly estimated our weekly integrations as four-hour processes (taking into account not only the branch/merge process, which was short, but also running unit, smoke, and GUI tests). Then we discovered our estimates were always wrong when it came to integration—we were always underestimating. We just took a look at the historical database and saw that integrations were taking about 10 hours because of the increasing number of tests we were executing.

Finally, when identifying subprojects, each sprint was treated as a single project from the CMMi point of view. We were worried about introducing additional overhead and making our rapid development process fail. However, we managed to make the entire administrative burden fit at the sprint review and retrospective meetings.

Easy to Adapt Areas

There were also easier areas, such as data management and configuration management. We had a couple of documents (none longer than 10 pages) describing how we handled all the data in the team (backups, storages, servers, and so on) and our internal configuration-management practices.

Project management and control procedure/practices were smoothly adapted from our SCRUM process, too. We ran a planning meeting at the beginning of each sprint, then daily follow-up meetings to check what had been done, what we had to do until the next meeting, and identifying problems and deciding how to react. We kept decisions registered on the wiki, something that proved to be helpful when introducing evidence for the CMMi evaluators. At the end of the sprint, we had both the review and the retrospective meetings. All these practices fit perfectly with CMMi; indeed they proved to be effective project-control mechanisms.

We had a project plan with a roadmap, role descriptions, available resources, and restrictions even before going for SCRUM. We used all this as our basis for CMMi, but formalized and revisited it to get the key points included. Product backlog played a key role in defining the goals (roadmap), high-level requirements, and sprint duration. Our first development effort had clear start/end dates, constrained by business restrictions. So our "big picture" first project was clearly set, having sprint iterations or subprojects (but managed as full-featured ones). When we passed the initial release date, we reorganized our development in a new year-long period containing a full set of sprints.

As the project was progressing, we started to be less formal on backlog management during the first big cycle. We failed to introduce a detailed list of desired functionalities at each sprint planning meeting, falling down behind Agile and towards chaos. CMMi helped us, forcing us to do what we were supposed to do according to our own rules. It is important to emphasize that CMMi doesn't impose any working method—it just asks you about your own processes. So when project teams end up with an overwhelming heavy procedure, they have to blame their own working methods (or lack of them), not CMMi. In our case, we forced ourselves to follow the SCRUM practices. Fortunately, we restarted our work to keep the backlog up-to-date and make better sprint meetings.

We refused to use conventional planning tools, and creating Gantt charts didn't seem to fit with our process. Product backlog plus the sprint burn-down chart were enough for us, and enough for CMMi, too.


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.