The 2009 ITMPI Software Best Practices Conference

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.

Agile Software Development and Fail Fast

I haven’t yet done a good job of describing the fail fast model with my thoughts on agile software development in this blog. Blogs feel more like streams-of-consciousness than articulated, structured documents. While I get my arms around how best to tell the fail fast story as I have experienced it through time, I thought it would be helpful to provide a bit more background on the topic by posting a copy of my Agile 2008 whitepaper, “The Big Projects Always Fail: Taking an Enterprise Agile.” You can now read it here; I would love to hear your thoughts and comments.

In Celebration of the Montreal Bagel

It the final years of the last century, I was amazingly fortunate to be working at Detroit Edison / DTE Energy when the transformation from “an Oracle shop” to “a Java shop” was being implemented. DTE’s CIO had the connections and insight to bring a wonderful group of people from the outside world in to mentor those of us on the inside, people who, a decade later, I still like to keep in touch with (Mr. Tibbetts, Mr. LeJacq, Mr. Meyer, etc.).

One of these wonderful people was Mr. Boutros, who flew in from his home in Montreal every Monday morning and back every Thursday night, if memory serves. I definitely remember the Monday mornings because that was when Stephane introduced us to Montreal bagels. As a native Michigander who had worked primarily in downtown Detroit until that point in my career, I had never even known that a Montreal bagel existed. Steph would bring in bags full of these bagels, which had been baked that morning at Beaubien Bagel (he picked them up at 5am), flown down to Windsor, and then trucked over the the border in the Tunnel Bus to DTE’s HQ. They were well-traveled bagels.

More importantly, they were fantastic. Sesame-seeded with a bigger-than-normal hole, they resembled an oval salt pretzel, but were sweet and denser. Fresh bagels were fantastic right out of the bag, and the development team would hail Steph and start devouring handfuls of bagels and cupfuls of the French press coffee we made every hour. (I guess, looking back, we were a high-maintenance technology team.) Whatever we didn’t eat that day were fantastic the next, toasted with cream cheese. These bagels have been favorites of mine ever since, and certainly their place in my gastronomic memory and heart was concretized by the unique person who introduced them to me.

I have gone to great lengths to get to a Montreal bagel since then. A few years ago, my wife and I went to Montreal to celebrate one of our wedding anniversaries. We stayed at the charming Auberge de La Fontaine, which I recommend for its location, comfort, and, naturally, the fact that they serve Montreal bagels for breakfast.

Others have also gone to great lengths to acquire them for me. The two oldest and most popular Montreal bagel bakeries are Fairmount and St-Viateur. Until recently, neither of them shipped to the US, unfortunately, so I had to hire a few gentlemen from Canada (Mr. Purdie and Mr. Tontodonati know who they are) and then have the bagels shipped to their homes so they could bring them to me, good men and great friends that they are.

Finally, at least one of these bakeries is now shipping directly to the US. It is not inexpensive — it looks as though the shipping is just as much as the bagels themselves — but they are certainly worth it.

I was never very good at geography, but I have learned that the heart and the stomach have a good memory for places. You heart knows where home is, where it was broken, where it has soared. Your stomach remembers where it has eaten well, whether it was breakfast in Traverse City at The Omelette Shoppe, the world’s best cafe mocha in Ann Arbor at Espresso Royale, a traditional Coney Island miracle at Detroit’s American Coney Island, or what I believe to be the best bagels in the world.