Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Why CMMi? Initial Situation The SCRUM Process Agile Concerns Requirements Management New Areas

The SCRUM Process

We managed the project using SCRUM. We were making 30-day sprints, planning each one at the beginning with a product owner introducing the goals and the team involved in estimation and planning. We were doing daily short reviews, trying to make them no longer than 15 minutes. At the end of each sprint we had both a review and retrospective meeting.

We mixed SCRUM with our own task-centric approach—everything a developer works on is a task, with a number, description, estimate, and full change log. Each task that involved code changes has its associated branch on the version-control system (Plastic in our case), providing an additional service to developers (their own private safety net or "undo button"), and project manager, thanks to a controlled weekly integration process. Once a week we built a new release, merging the approved tasks and creating a new baseline used as a starting point for all ongoing tasks during the next week. We tried to have a release at the end of the sprint to be used as a fully working product, as SCRUM requires.

We implemented our process using three tools:

• Defect Control. An open-source tool we previously developed and adapted to our internal process. Defect Control registers tasks, assignments, pending work, finished tasks, manages queries, and handles release notes. Everything we work on is a task on the Defect Control; see Figure 2.
• Wiki. We installed a standard wiki on our Linux server. Analysis and design documentation, planning, technical articles, and how-to guides are registered on it. We also use the wiki on a daily basis to register short, informal logs of each sprint daily meeting; see Figure 3.
• Plastic SCM. Version control is the third pillar of our development process. Everything is under version control—design documents, digital assets, and code. We make extensive use of branches, which Plastic deals with; see Figure 3. (We were early adopters of our own tool, following the "eat your own dogfood" principle.)

[Click image to view at full size]

Figure 2: Defect Control program.

[Click image to view at full size]

Figure 3: Wiki.

Adapting to CMMi

The process of adapting to CMMi took us about 14 months. We probably could have achieved the same results in a shorter period, but our CMMi effort wasn't continuous.

A few months after the project began, we started working on the first CMMi procedures and received initial training. This continued until we entered a totally product-centric period, causing us to put aside CMMi. Eventually, a new person joined the team and took on responsibility for the QA group, with a special focus on CMMi. We then combined our development efforts with CMMi adoption and institutionalization.

Previous Page | 1 Why CMMi? | 2 Initial Situation | 3 The SCRUM Process | 4 Agile Concerns | 5 Requirements Management | 6 New Areas Next Page

RELATED ARTICLES Danube Releases ScrumWorks Pro 4.1 Why We Need a Theory for Software Engineering Nokia Takes Task Management For A Spin Programmer Productivity Integrating ALM: Lessons Learned Deploying Tasktop at Nokia		TOP 5 ARTICLES No Top Articles.