I'm attending a mini-software development conference host by IBM at Michigan State University in East Lansing, Michigan.

The conference is only two days and I'll be tweeting a few bits of advice and updating this article with the key takeways from the various sessions on Agile software development using IBM's Rational tool suite.

If you want to follow along in real-time, just follow me @andymakar on Twitter or you can view all the postings by searching for the hash tag: #ibmmsu via Twitter

Here is the link with the latest Twitter posts and bits of advice from the Rational Software Development Mini-Conference

Key Note Take Away

Tuesday's keynote presentation focused on the importance of delivering a quality product versus delivering a best in class software development method.  As software developers, we often think about the best process to develop software.  Software is just part of the solution as the entire product needs to consider not only the software time to market but the business functions they support.

An interesting fact was the presentation cited only 34% of all software projects are successful at the cost of $300 Billion.  Can you imagine what the failed projects cost?  The keynote also emphasized the need for iterative development as a product is developed.

Agility at Scale

Lee Reid gave an interesting presentation on an Agile Software Development Maturity Model that highlighted the different stages organizations experience as they adopt Agile.  Not suprisingly, a lot of waterfall organizations have needs at the most mature stages of the maturity model although they need to start at the first level of Agile Maturity.

The maturity model presented provides a roadmap for organizations to adopt Agile best practices.  An interestng fact was IBM has transitioned their software development process to embrace agile concepts using their own Rational products to improve collaboration.

The presentation also highlighted the concepts in the http://www.agilemanifesto.org and new concepts for software craftsmanship and community at http://manifesto.softwarecraftsmanship.org

It was also refereshing to learn IBM recommends a variety of techniques to elicit requirements including use cases, user stories and short statements to define requirements.  I've seen some organizations that have methodologies that require EVERYTHING to be modeled instead of focusing on the critical or complex requirements.

Here is the link for the Agility at Scale presentation.

Rational IBM Team Concert

Rational Team Concert is an interesting idea as a collaboration platform across developers.  It has a lot of functionality although my perspecitve is it has a big learning curve.  Incorporating instant messaging, release planning, iteration planning and various agile components in one Eclipse-like platform is an impressive set of features.  However, I thought the demo was a difficult to navigate.

Compared to VersionOne or RallyDev, the Team Concert had a lot more complexity and I felt like I'd was searching and pecking for the specific features.  As a collaboration platform, I thought a better UI would encourage collaboration not only from the development team but from the product owner.  VersionOne and RallyDev have a different approach that makes collaborating around Agile seem easier.  I only spent an hour with the demonstration and I believe a development team would have a different perspective.  The Jazz concept is a useful product for collaboration indepedent of the Rational Tool set.

The other observation is the solution set for IBM software development seems quite LARGE. Instead of purchasing 1 product that supports requirements, quality management and software processes, you'll need to purchase all the solutions to effectively maximize your efficiency.  I appreciate having a lot of different products but with every product comes a learning curve that even enterprise organizations will struggle adopting.

I thought the concept was exciting and I like the idea of cross team collaboration.  However, I've seen other software products execute the solution better.

Good Requirements

The next session was on establishing Good Requirements.  Lee Reid faciliated the discussion and he had a good perspective on requirements definition and requirements managment.  I liked the model he drew on the chalkboard (yes..a chalkboard at MSU vs. a whiteboard...I haven't seen one of those in a while).  The key points included:

• requirement issues drive excessive rework, delays, poor quality and project failures
• time not spent in requirements is time spent in rework at cost X 200
• business req: the user shall be able to...
• system requirement: the system will do..
• a good requirement depends on WHO is reading it
• requirement confusion occurs when we mix the problem space with the solution space
• it is important to realize projects don't need to apply all types of requirement elicitation techniques. Pick 1 or 2 and augment

I found it interesting that the requirements management and requirements definition presentation didn't integrate Agile with the presentation.
Often when we talk about requirements management, we ask "Where is the approved business requirements" and defend any changes to the "signed off" requirements.  The reality is requirements evolve through a project and and good requirements need to embrace flexible processes that allow requirements to elaborate and change.  The key note presentation addressed the need to build software incrementally.  Requirement processes also need to adopt this focus...otherwise you're faced with a 200 page requiremement document that the business customer has no interest in reading.  In all honesty, neither does the project team.

Here is the presentation on IBM's Good Requirements

Overall, the first day was very informative and I enjoyed learning how IBM is "moving the needle" with improved collaboration and better software development practices.