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.
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.
