Kenya Day 1 (28/8) - IT Solutions ... simplicity, build and delivery - Willy-Peter Schaub's Cave of Chamomile Simplicity

Kenya Day 1 (28/8) - IT Solutions ... simplicity, build and delivery

Due to limited access to the Internet, I will have to wait until I am back in SA before posting these blog posts.

 (Nairobi International Airport)

During our flight to Central Africa and "enjoying?!?" an eventful flight from Johannesburg to Nairobi to Mombasa, I started wondering about a presentation covering MSF by Rafal Lukawiecki. It is an excellent session he delivered at TechEd 2007, track DEV210, during which he mentioned the Standish Group and the comparison of IT solutions and roller coasters.

Why would I think about the session while flying and what is the relevance ...

Let us look some statistics published by the Standish Group:

IT solutions currently enjoy an average of:

  • 45% cost overrun
  • 63% time overrun
  • 67% expected functionality delivered

The following chart, published in the 2003 Chaos report, shows yet another interesting aspect of IT solutions.

What does it mean? Flying over Africa, having zero control of the plane, I started wondering again. What if Boeing or Airbus delivered planes as per the above graph? In other words, one to two (1-2) planes out of ten (10) never leave the factory, five (5) planes go up in smoke or are delivered to airlines with challenging flaws and/or limitations, while only three (3) out of ten planes are fully functional. Would we board the plane, knowing these statistics? Would Boeing or Airbus be able to remain in business for long? Would we, as stakeholders, pay for such services?

Hhhhmmmm, according to the Standish Group the above diagram shows the averages of failed, challenged and successful IT projects. Fortunately the statistics in our company are a lot better, but if compared with roller coasters or planes ... or even a space flight to PLuto as covered in our third book ... I would still have a queezy feeling.

Finally, why does simplicity and a regular build appear in the subject description?

To increase the green area of the above graph, we need ... in my humble opinion ... (1) a solid and accepted process, (2) simplicity which reduces both maintainability and test complexity, and (3) a reliable build process.

  1. MSF CMMI, MSF Agile, Conchango Scrum, Lightweight Scrum and RUP ... all frameworks/processes that offer a solid foundation for an IT solution. It is important you select the right tool for the job ... i.e. do not use a sledgehammer to fit the bold that holds the engine under the airliners wings.
  2. Test code and test procedures are not for the weak and timid ... it is essential for reliable and fully functional solutions.
  3. The daily or continuous build ensures that we have an indication of how functional a solution team is, a counter-measure to future integration issues, a visible indicator and overall a solution heart beat. No build, no pulse, no comfort feeling.

Thinking about it there are many solutions, including Team Foundation Server (TFS) that guide, not enforce, the above prerequisites for a successful solution. Perhaps we should be more willing to embrace these solutions, or take a flight to Central Africa and have a similar "I wonder" journey, that I had.

I often have debates with various stakeholders, including project managers, analysts and developers as to the value of project lifecycle management, automated testing and automated builds. All these artifacts are possible with the buy-in of all stakeholders, with minimal impact to the team, but major contribution to the quality of delivery. We should not be satisfied with delivering less than expected functionality, less than expected quality, or for business and project management to put the software development lifecycle under pressure. 

Perhaps the sponsors and users of IT solutions should view the IT solutions as roller coasters or planes, raise the quality bar and lower the tolerance for less than perfect solutions. May the debates continue...

The core list of principles after day 1 is:

  1. Implement, adopt and use a suitable SDLC process to guide and support, not enforce. 
  2. Strive for simplicity throughout.
  3. Implement a regular build process.

Happy flying...

Published Friday, August 31, 2007 8:19 AM by willy

Comments

No Comments

Leave a Comment

(required) 
(required) 
(optional)
(required) 

Enter the numbers above: