Methodology wars … not!

Recently I reengaged with Agile methodologies, attending a ScrumMaster workshop conducted by LitheSpeed in DC (highly recommended if you are looking for a ScrumMaster workshop). Took the test and passed it.

I have been reading a lot about Agile, so nothing really new in the workshop. But I did get a sense that there are divisions among the various Agile practitioners (some of you may go “duh!”) There are the XP, Scrum, RUP, Lean practitioners that decry that their way is the only way. They all agree that waterfall doesn’t work (I too, although I’ve made it work by layering CBPM on top of it, making it somewhat Agile!)

Mark Kennaley’s SDLC 3.0: Beyond a Tacit Understanding of Agile does a very good job of tying the various Agile methodologies together, showing how to leverage the various strengths. To me, this is the way to go. In my experience, it is rare that one set of tools/methods can address any one situation. I pick and use what makes sense at the time, changing in mid-stream if necessary. Mr. Kennaley’s approach is refreshing and I’m sure there are many other Agile practitioners who feel the same way.

SDLC 3.0 also points the way forward from here. So, if you are interested in Agile and how they can work together, you may want to pick up Kennaley’s book.

Mathematical Explanation of why CBPM (and Agile) works

Just got from Amazon SDLC 3.0: Beyond a Tacit Understanding of Agile by Mark Kennaley. I have seen it mentioned in one of the Agile emails I get on a regular basis and sounded interesting: where do we go from current Agile?

As readers know, CBPM (Commitment-Based Project Management) is also an Agile framework that can help team deliver not only software but also hardware and other types of projects (it’s been used in semiconductor development, factory design, rocket design, radiation dosimeter development among other efforts).

So, I started the book thinking I was going to get a lot of words, some nice pictures, etc. Then I got to chapter 3 and I thought I was back at West Point in my EE3xx (can’t recall the number) Control Systems class! Here it was, including Laplace and Fourier transforms, stuff that I once knew about but could not remember much of!

Well, it turns out that while software development projects (the book is focused on Agile methods that are used for software development. However, the findings apply to CBPM which also does hardware as mentioned above) are chaotic in nature, they are still predictable, controllable, and can be modeled.

The model uses a proportional control (resources), an integral control (summation of past errors — test of deliverable), and a derivative control (how fast an error is changing).

Adding too many resources to a project (proportional control) to catch up make the project later (remember Frederick Brooks and The Mythical Man-Month? If no, time to read it!). It also leads to out of control situations as resources try to “help”, making things worse. Not providing resources doesn’t let the project reach it’s result.

Assessing how well the product meets requirements is the integral control. With CBPM checking weekly (derivative control), the error added in one week is minimized, controlling how far out of spec the solution gets. Traditional project management, with its limited, late in the cycle checking, has to deal with a potentially very large error.

Little did I know that my electrical engineering course work would come back so much later to be helpful! If you are interested in why CBPM (and Agile) works, take a look. It may give you ammunition next time your boss wonders why you are checking results so often.

Besides this chapter, there’s a lot of other good “stuff” in the book. So take a look.