Home > technical > Ultimately And Unsurprisingly

Ultimately And Unsurprisingly

Take a look at the latest, dorky, BD00 diagram below. The process model on the left is derived from the meaty, 482 page CMMI-DEV SEI Technical Report.  The model on the right is derived from the lean, 16 page Scrum Guide.

Comparing CMMI-DEV and Scrum may seem like comparing apples to oranges, but it’s my blog and I can write (almost) whatever I want on it, no?

Don’t write what you know, write what you want to know – Jerry Weinberg

The overarching purpose of both process frameworks is to help orgs develop and sustain complex products. As you can deduce, the two approaches for achieving that purpose appear to be radically different.

The CMMI-DEV model is comprised of 22 practice areas, each of which has a number of specific and generic practices. Goodly or badly, note that the word “practice” dominates the CMMI-DEV model.

Unlike the “practice” dominated CMMI-DEV model, the Scrum model elements are diverse. Scrum’s first class citizens are roles (people!), events, artifacts, and the rules of the game that integrate these elements into a coherent socio-technical system. In Scrum, as long as the rules of the game are satisfied, no practice is off limits for inclusion into the framework. However, the genius inclusion of time limits for each of  Scrum’s 4 event types implicitly discourages heavyweight practices from being adopted by Scrum implementers and practitioners.

Of course, following either model or some hybrid combo can lead to product quality/time/budget success or failure. Aficionados on both sides of the fence publicly tout their successes and either downplay their failures (“they didn’t understand or really follow the process!“) or they ignore them outright. As everyone knows, there are just too many freakin’ metaphysical factors involved in a complex product development effort. Ultimately and unsurprisingly, success or failure comes down to the quality of the people participating in the game – and a lot of luck. Yawn.

  1. September 1, 2012 at 10:50 am

    Don’t forget 3 other things: communication (in and out), collaboration, and skill coverage.

    Ultimately, these are all people qualities, too. But they are far from automatic, just because a competent group of individuals is assembled.

  2. charliealfred
    September 1, 2012 at 10:59 am

    Also, keep in mind the difference in scale. SEI’s main customer is the DOD and they tend to deal with rather large projects. SCRUM was originally designed to be lightweight (“team size <= 9, co-located team"). I realize that SCRUM has been applied successfully in broader contexts, but it's sweet spot is not 100's of geographically dispersed team members.

    There was an excellent IEEE Software article some years back (which took the form of a debate between Barry Boehm and Kent Beck), where Beck compared Waterfall to a dinosaur and agile to a mouse. Beck said that the dinosaur went extinct because it couldn't adapt to changes in its environment. OTOH, not many dinosaurs were in jeopardy of being eaten by hawks.

    This all seems to point back to Weinberg's quote – "you can be well adapted, or adaptable, but you can't be both at the same time."

    • September 1, 2012 at 11:45 am

      Thanks for adding your thoughts to the post Charlie.

  1. September 9, 2012 at 6:43 am
  2. October 5, 2012 at 1:02 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: