Initial Situation
Thanks to one of the principal engineer's project-management background, we adopted SCRUM (www.scrumalliance.org) at the outset. Within months, we were using the basic SCRUM artifacts—short meetings, daily follow-ups, flat organization, collaborative estimating/planning, product/sprint backlogs, and the omnipresent burn-down chart (Figure 1), which was always telling us how good (or bad) we were doing.
Still, the small team and tight product focus (Plastic SCM) didn't appear to be a perfect match for CMMi. Indeed, when we made the commitment to go for CMMi evaluation, we were one of the few companies in Spain trying to reach Level 2 while making a product. And we were SCRUM users.
If we were committed to CMMi, why SCRUM? Why not just introduce a more traditional methodology?
The answer is simple: Developing a new SCM product is a huge challenge. We needed to get the most out of our developers—not just commitments, but also innovative ideas. And to reach those targets, we needed to make the development cycle less formal and more fun. Of course, being less formal, giving developers more freedom, and getting rid of boring tasks (like detailed analysis or design) has its drawbacks. Still, we hired people who rapidly became a real team, in the "peopleware" style. There is something you gain and something you lose, but as core Jack "the code is the design" Reeves followers, we preferred the code to be a key part, and the fun, motivation, and personal abilities to take care of the rest.
SCRUM is straightforward to learn and easy to follow. It maximizes project control and provides fallback solutions, which was aligned with our overall company goals; see Steve McConnell's Rapid Development (www.stevemcconnell.com/rd.htm).
