Is adopting the CMMI more of a science or an art?

Hey, CMMI Appraiser – settle a bet between me and a fellow Michigan software engineering executive. Is adopting the CMMI more of a science or an art? I say science, because of its rigor and discipline, and he says art, because, he says, the Model can be interpreted differently for each company that adopts it. Who’s right? ~ Isaac F.

Yes!

Isaac, it’s both. Taking the journey to become a great company by adopting the CMMI is both an art and a science. So you both win.

Most people think art and science are polar opposites. Whereas art is expressive, emotive, decorative, or conceptual, science is logical, ordered, practical and functional. How could they possibly overlap?

To illustrate this dynamic, let me share a personal passion of mine.

This CMMI Appraiser started his career journey as a classical musician. I hold degrees in both Music and Computer Science. Today, in addition to running an Agile process innovation firm, Broadsword, I am a Certified Lead Appraiser, CMMI Instructor, ScrumMaster and author of “agileCMMI,” Broadsword’s leading methodology for incremental and iterative process improvement.  And I also play music semi-professionally.

Here’s my secret: I see most things as a musical orchestration. When I wrote software, it was like playing the computer – composing a piece and playing it on a complex instrument.

Today, when I walk into a company, I see an orchestra and a composition that is in need of arrangement and rehearsal. I see my job as a behind-the-scenes conductor or coach to the orchestra, a sectional coach, if you will, who goes around making sure all of the different sections (brass section, string section, etc.) are working together. Then I tap my baton on the stand and say, “Time to play,” and you hear beautiful music come out the other side.

Sounds like art … but there’s a whole lot of science that goes into a CMMI-based process improvement program before you can synthesize something new.

Charlie "Bird" Parker, my favorite jazz musician, did that. Charlie was known for his genius in playing fast and technically accurate.  For Bird (and for me) music is about engineering the craft. You learn the theory, history and all of the academics, which includes theory, drilling and finger exercises. After you master that, only then you can be creative.

A perfect example of an organization that does this is CutTime Productions (www.cuttime.com). Led by Detroit Symphony Orchestra bassist Rick Robinson, CutTime Productions is an artistic venture committed to connecting curious but inexperienced music lovers with the beauty and power of classical music in new and innovative ways. Broadsword recently became a supporter of CutTime, helping them cover the startup costs of traveling the country and introducing their music and methods nationally.

CutTime has the ability to apply science and discipline, and layer creativity on top of it. In that sense, CutTime Productions does for classical music what Charlie Parker did for Jazz, and what Broadsword does for software engineering. We are all after the same wonderful, paradoxical goal:

Applying science and art on the path to greatness.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.

Does the Agile Manifesto "forbid" writing down requirements?

Hey, CMMI Appraiser – I’m a member of an an agile team for a Maryland contractor to the National Institutes of Health. We just started designing a fairly complex financial system for NIH, but one of my teammates is adamantly against writing down changes to the requirements. He says the Agile Manifesto forbids it – but our boss clearly thinks it’s important. Does the Agile Manifesto really forbid writing down the requirements? ~ Carol W.

Carol, I had the same conversation with an XP team a couple of weeks ago. They said, “We don’t see any value in writing down the changes to the requirements. Business value is in our software, not in documents.”

Suffering through unclear requirements is not a question of "if" but "when" on any project team.  In my experience, anyone who says that has never suffered from the confusion and chaos that inevitably occurs when a team loses track of the current state of requirements (just ask any tester or customer).  In the case of your colleague, I strongly suspect he is mistaking the Agile Manifesto, a very well thought out, disciplined set of guidelines, for the "Lazy Manifesto."  Only one of those approaches is going to help make your company great (hint: it's not the Lazy Manifesto).  Let's take a look at what the Agile Manifesto actually says (with compliments to Sutherland, Jeffries, Beck, Schwaber, Beedle,  Cockburn, et al):

No doubt you've seen this before.  At this point, the Agile Manifesto is so familiar that a mythology has been built up around it. After listening to so many people talk about it I get this mental image of a gang of brainy geeks climbing up a mountain-side, complete with crampons and ice picks, setting up a smoke lodge, and sitting there on the mountaintop for a couple days. Smoke fills the teepee, and on the last day, out comes a puff of white smoke along with the Agile Manifesto, along with a torrent of hundreds of conferences and books!  Everyone in the teepee goes on to become a superstar and software is defect free and on-time forever!  Did I mention the rainbows and unicorns?

It turns out these folks got many things right … and one thing REALLY right.  Collaboration and communication  (and the structure to encourage them) are pivotal for creating great software.

They were also smart enough, as the founding fathers and mothers of "Agile," to say about the stuff on the right: “This stuff is important too.”

But somewhere along the way, too many people took a paper cutter to this document, and focused only on the stuff on the left.  This may be why your colleague is confused.  This is where comments like "business value only exists in code" came from.  That is ONE of the places business value exists, perhaps the most important, but not the only place.

So, IMHO, it is important to write down requirements.  Does it have to be a huge, heavy specification?  No, it can be as simple as sticky notes or maybe in a tool like iScrum or Process Focus.  Applying discipline to your Agile methods will help your team, customer, and boss understand the business issues at stake. This will help make your team more successful and put you in position to take on larger, more complex projects.

To be clear, when I say "apply discipline," I don't mean rigidity and useless documentation.  Of course we care more about the stuff on the left.  Just remember the stuff on the right is really important too.

Sounds like your colleague is about to get his first experience with that.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.