Yet another gloomy and tempestuous day here in Detroit, both methodologically and financially, with thunder and lightening in the air and the apparent bankruptcy of Chrysler finally announced. However, I’m comfortably ensconced in the MGM Grand Detroit attending this year’s Software Best Practices Conference, sponsored by the IT Metrics and Productivity Institute.

The speakers include:

1. Bob Lawhorn, CTO of CAI, on “IT and the World Wide Manufacturing Revolution.”
2. Ed Yourdon, author and international consultant, on “Moving Beyond SEI Level 1.”
3. Larry Dribin, principal of The Pearl Street Group, on “What Gets Measured Gets Done.”
4. Dan Galorath, President of Galorath, Inc., on “Sizing, Cost, Schedule, and Risk for Software: A 10 Step Process.”
5. Bob Lawhorn again on “Transforming IT Management for Dramatic Business Success.”

It isn’t quite lunch yet, but I’ll be updating this post during the day (laptop battery permitting) with some of the speaker comments and highlights.

BTW, you can watch the webinars live here.

Update: Ok, we’re on a break, I can share a few of the nuggets so far.

“Moving Beyond SEI Level 1,” by Ed Yourdon.

1. Generally, things have improved within the software development space from a quality and productive standpoint in the last 15-20 years when you review the SEI CMM data.
2. Process maturity = quality + productivity.
3. In 2003, 60-80% of all SEI Level 5 companies were in India.
4. “There is not enough pressure to change” when it comes to improving software (itself) or process.
5. Ed presented an interesting list of “barriers to improvement.” The bottom line is that the same barriers that have existed for decades. My two favorites were:
   • Sturgeon’s Law: Ninety percent of everything is trash.
   • “Software is a human effort — and people are still the same.”

This last point is certainly in harmony with my own beliefs. Software is a human effort, and this point can’t be underestimated when you are planning and executing a software development effort that requires more than one person to complete.

Mr. Yourdon also pointed out a few of his blog posts that you may find of interest related to these barriers to improvement: November 9th, 2006, and November 19th, 2006.

“What Gets Measured Gets Done!” by Larry Dribin.

Larry’s presentation highlighted a number of challenges and opportunities within the metrics and measurement space. His comments had a patriotic flavor and he indicated a few times that the US has work to do in order to be able to compete successfully with other countries who have focused more on quality than we have. He mentioned a specific example in which a project was developed by two teams, one in the US and one in India. Apparently, of the nearly 1500 bugs that were uncovered during the testing phase, over 1400 of them were produced by the US team. His main comment was, “Indian software firms publish their defect density on their home page. If you don’t know yours, how can you compete?”

He also referenced the work that 37 Signals has done in the “making things smaller” space, which is directly correlated to the fail fast concept. This mention of 37 Signals reminded me, for the second time this week, of the fantastic book Dreaming in Code, by Scott Rosenburg.

The ninth chapter of this book, simply titled “Methods” (click here for the endnotes) reads like a short summary of software development methodologies over the last 30 years, and I believe it actually foreshadows what software development will look and feel like in the future: very simple, very small, and very productive. I can’t remember who borrowed my copy of the book so I can’t look up the details at this moment (I will update this post later if I find it and it changes my memory), but in essence he points out that smaller teams are more effective and productive (like 37 Signals) and that even this fact may suggest what the next phase of software development methodologies will become post-agile (somewhat like The Agile Cloud I’ve mentioned before). Definitely worth the read, both for this informative chapter and the wonderful world of start-up companies that the book covers.

“Sizing, Cost, Schedule, and Risk for Software: A 10 Step Process,” by Dan Galorath.

Dan talked about the importance of determining what to measure when it comes to metrics as well as one of my favorite topics, estimates. He advised getting at least three estimates (best case, likely, and worse case) and told a number of interesting stories about the process and importance of estimation that certainly rang true with my own experiences (this is no surprise given Dan’s expertise on this topic). His talk included a fantastic set of graphs; the one I found most interesting focused on the optimal staffing model for a project. I’ll pass along a link as soon as I find it.

Dan also alluded to the importance of baselining your projects either against your own data (over time) or against publicly available data, like that from ISBSG. Obviously, the extent to which you want to take this sort of optimization effort needs to be scaled to your business model and needs, but being able to articulate the effectiveness of your internal process either over time or against the backdrop of industry data is a powerful corporate capability.

“Transforming IT Management for Dramatic Business Success,” by Bob Lawhorn.

Bob spoke at length regarding “the transformational journey” needed to improve software management:

1. Standard Processes
2. Managing with Metrics
3. Automation

He made a number of interesting comments, my favorites of which were:

• We need to develop a way to bring new members into a team so that they can be safe and learn effectively by learning from their mistakes.
• You have an ineffective process if your mistakes are not found within the team that creates them, as it diminishes the effectiveness of a reliable feedback loop.
• Executives and the friends of developers are the two largest sources of black market (out of scope) activities.
• Rework is one of the areas that has the greatest opportunity for the reduction and removal of waste, and therefore for the improvement of productivity.

Overall, it was an enjoyable day of presentations by a very esteemed group of software and IT leaders. It was not even dampened by my losing $8 on the quarter slots on the way to the parking deck.

The only disappointment to me was that nearly all of the speakers made what I would call gently critical comments regarding the agile software development movement at some point in their speeches. This may actually have been predictable given that, in general, agile is not overly focused on metrics and measurement with respect to productivity but instead on collaboration, working software, and responding to change. I don’t believe that these are mutually exclusive worlds — my last agile shop could generate fantastic metrics regarding historical estimates, backlogs, and time dedicated to canceled features because we had the systems and processes in place to capture this data — but I would agree that there isn’t as much science in this aspect of software development in the agile world as there is in the waterfall one. There may be an opportunity for an effort to begin tracking data regarding agile projects and their associated metrics in order to fill this void.

Regardless, companies like 37 Signals may have the final word on productivity and quality if their success is any indication.