Book Review: Crossing the CHASM

I’ve heard people make references to Geoffrey A. Moore’s Crossing the CHASM book for several years now but hadn’t read it until this past week.

Moore’s book is a must-read for any IT company trying to launch a new product.  Although the concepts in the book are not novel (so admit’s Moore) the book brings a vocabulary and metaphoric dictionary to the readers allowing marketing groups, investors, and techies alike to communicate about the playing field in a proactive manner.

Moore discusses the importance of delivering continuous innovation, instead if discontinuous innovation.  Our new innovations need to help people do what they are already doing better, and not force them to abruptly change something that kinda works for something that they are not sure about that may possibly work better.

Moore introduces the Technology Adoption LifeCycle, complete with five categories of market segments.  He discusses how to market in succession to each group:

  1. Innovators
  2. Early Adopters
  3. Early Majority
  4. Late Majority
  5. Laggards

Finally, Moore introduces some business concepts you may have heard of by now, like the bowling alley, the tornado, and the fault line.

If you haven’t heard of these, then you need to get reading!

Mike J. Berry
www.RedRockResearch.com

Publishing My First Book: Software Quality Systems Management

Posted by mikeberry | Book Reviews,Leadership | Tuesday 21 July 2009 1:59 pm

I’m publishing my first book next month.  It’s about software quality management.

Quality management, that is, in the sense of improving software processes and production support methods, not about ‘how to test software.’

I include overviews of the four formal quality models: CMMI, Six Sigma, and ISO 90003, and ITIL.  I outline how to create a quality system within an organization and I discuss common fixtures it should have.

I talk about checklists, measurements, purpose, accountability, and continuous improvement.

So now I want your help.  Tell me what else I should include in a book about managing quality in an IT/Software Development/Production Support environment.

Also, suggest some titles.  Thanks in advance!

Mike J. Berry
www.RedRockResearch.com
 

Software Development Best Practices – Software Requirements Management

I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public.  Our topic was Software Requirements Management.Requirements Management is perhaps the most controversial topic in software development.  Everyone seems to have their own technique.  It is also the most important skill-set–statistically more important than development skills–to the overall success of a software project (Standish CHAOS Report, 2009).Let me say that another way because this principle is not intuitive…if you want to improve the performance of your development projects, improve the skill-sets of your business analysts who generate requirements.  Statistically, this has more of a performance boost on a projects outcome than any other skill-based area.Many published requirements management techniques exists, and yet in a $220 Billion industry with a project failure/delay rate of 64%, it appears that most of these published techniques are not embraced.Our seminar covered Eliciting, Prioritizing, Validating, and Documenting a requirements baseline.  We discussed the progression of system context diagrams, UML actors, use cases, data-flow diagrams, High-Level Overview diagrams, High-Level Design diagrams and finally the Software Requirements Specification document.   We talked briefly about  a Concept of Operations document and a System Design Description document.We discussed the difference between a plan-based documentation stack, and a minimized Agile-development documentation stack–which would be generated during a Sprint-Zero.  (Yes BTW, you DO create documentation for Agile projects!)We discussed techniques to control scope creep after the requirements baseline, and then discussed techniques for dealing with what I call ‘approval noise.’What puzzles me the most about this topic is an entrenchment I encounter occasionally, as expressed by one of the seminar participants.   He stated, after the seminar, that all of this was interesting in a textbook-like manner, but that he felt none of it was pratically applicable.I asked him to explain how his company performs requirements practices and he said “Well, we have nothing written.  We have everything in our head and we just talk across the cubicles.”  He then told me he was frustrated at some additional items he was asked to add to his project that morning because it was supposed to be completed two weeks ago.  He also told me that the owner of his organization wished they had a structured approach to software project management, and that–oh, by they way–many of the programmers were given layoff notices at the beginning of the week because the company is failing.Hmm, it’s almost as if the problem is not properly in focus.  Downstream problems are caused by upstream actions or omissions.  I mean no disrespect, I just wish to point out the obvious that if companies like this would adopt upstream structure they would benefit from downstream success.You see, the problem proper requirements practices solves is not at the development effort level, it is at the project management, estimation, budget, and strategy planning–or business level.Software centric business level practices become predictable and executives can be proactive if their projects properly consume the time estimated.Projects will consume the time estimated if they include all of the functionality needed for a desired level of business value, and those functions are identified in whole, at the beginning of the project.  This way the software project time-frames and feature-sets can be included accurately in the estimation, budgeting, resource planning, and strategic planning of a company.  This way, scope creep will be minimal, and the whole company will benefit from a predictable project delivery process.Without proper requirements skills, entire feature-sets get missed upstream and need to be added ‘at the last moment’ downstream,  the risk of re-work increases drastically, and recurring cycles of this erode project managers and the development team’s credibility in the eyes of the executive team and the waiting customers.  In worst case scenarios, this can lead to layoffs and finally company failures.If you haven’t been trained on proper requirement management techniques, you are holding your organization at risk.  Attend our next three-day Software Requirements Management training course held September 7-9 in SLC.Mike J. Berry, PMP, CSM, CSPMwww.RedRockResearch.com

Book Review: The Book of Five Rings

Recently, while attending the ’09 Agile Roots conference in Salt Lake City, UT, Alistair Cockburn–the keynote speaker–referenced Miyamoto Musashi’s 16th-century book called The Book of Five Rings.

I like Asian philosophy (and swords and such) so I picked up the book and read it.  The book was written in 1643 by an undefeated Japanese samurai master who was so effective he was rumoured to have spent the latter part of his career entering sword-fights purposely without a weapon.  Although meant as a battlefield manual, the book has gained popularity as a handbook for conducting business in the 21st century.

The book was translated into English by Thomas Cleary at some point and the edition I read was published in 2005.   Improperly named “The Book of Five Rings,” the book is actually a compilation of five scrolls.

The Earth Scroll: Musashi talks about how a straight path levels the contours of the Earth and how various occupations provide life-improving principles.  He talks about observing patterns and learning from them.  Certainly a great primer for any business trying to get across the chasm.

The Water Scroll: Here Musashi talks about how water conforms to the shape of its container.  He suggests a separation of one’s inward mind against it’s outward posture, maintaining that one’s control over one’s mind must not be relinquished to outward circumstances.  He translates these philosophies into about 80 pages of sword fighting techniques.  An interesting modern parallel is found in Jim Collins book, Good to Great, where he talks about how the most successful companies are able to say ‘No’ and not be influenced by immediate but non-strategic opportunities.

The Fire Scroll: As with any book written by a 16th century samurai master, you’d expect a core discussion on combat strategy.   The fire scroll is full of combat strategies, positioning, and pre-emptive theory.  Very interesting.  Did anyone notice how Apple’s announcement of the latest iPhone came about 1 day after the Palm Pre phone was officially launched–killing it’s market blitz?  No coincidence there.

The Wind Scroll: The wind scroll contains a directive to study and be aware of your opponents techniques.  Translated into business speak, this means one should always study ones competitors.  Be aware of new offerings, partnerships, markets, etc. that they pursue.  Emphasis is placed on observing rhythms and strategically harmonizing, or dis-harmonizing with them as appropriate.

Finally, The Emptiness Scroll:  This scroll discusses the value of escaping personal biases.  Emphasis is placed on not lingering on past situations and being able to adjust quickly to new scenarios.

Overall I found this book ‘enlightening’ to read.  If you like metaphors and inferences, or sword-fighting, then you will enjoy this book.

Mike J. Berry
www.RedRockResearch.com

Two Days with Alistair Cockburn

Posted by mikeberry | Agile Development,Most Popular,PMI-ACP,Product Owner,ScrumMaster | Saturday 11 July 2009 9:16 am

I recently attended an Agile Development Product Owner class taught by Alistair Cockburn.  The content was excellent.  He taught us about the proper perspectives an Agile Product Owner needs to successfully interact with the project sponsors, users, and the development team.Alistair Cockburn has authored several books on Agile Development, and is one of the original signers of the Agile Manifesto.I would describe Alistair’s environment as squirrely and fun.  We built user-stories out of the Rumpelstiltskin and Cinderella stories (from the original Nicht fur Kinder european versions–full of voilence and gore!)We also discussed the differences between Use Cases and User Stories.  I was happy to hear he prefers Use Cases, because so do I.All class attendees had already been through the ScrumMaster course, so as we executed sprints for our product backlog, it was interesting to see how many attendees actually sought the sponsors/users feedback during the iterations–without being reminded.Overall it was an educational and enjoyable experience.Mike J. Berrywww.RedRockResearch.com

Software Development Best Practices – Software Estimation

Posted by mikeberry | Plan-based Development,Software Estimation,Software Requirements,Uncategorized | Friday 10 July 2009 11:02 am

Red Rock Research held our first of a weekly series of seminars on software development best practices yesterday at the Miller Campus – Professional Development Center.  Our topic was Software Estimation.

We covered the typical informal methods: Fuzzy Logic, Wide-band Delphi, Planning Poker, and the primary formal methods: Function Point counting, the Putnam Model, COCOMO II, and COSMIC-FFP.   We also discussed how to estimate the percent of defects still in your application at the time of release.

Along with ‘how’ to estimate software projects accurately, we discussed how to manage the expectations of the executive team and the investors who typically want everything now.  Chris Perry, from the Utah iEEE CS chapter was in attendance and said “All the things your talking about I’ve been living for the past 10 years!”

Join us this Thursday, July 16 for our 2-hour seminar on Software Requirements Management.  The cost is only $10!

Mike J. Berry
www.RedRockResearch.com

Don’t miss these Software Development Best Practice Workshops…

I’m hosting weekly Software Development Best Practice workshops each Thursday during the next four weeks.  These are held during work hours so ask your manager/VP/CIO and perhaps they would like to come along.  The topics are different each week.

This is basically a summary of my three day courses that I am now offering.  I’m giving the info away to get some attention in the valley.  Each workshop is from 3:00 – 5:00pm Thursday afternoon at the Miller Campus – Professional Development Center  This represents a tremendous value as I have put over 3000 hours of research into the material and consumed over 100 industry books.

Topics

Software Estimation – July 9th

Software Requirements Management – July 16th

Software Quality Systems Management – July 23rd

Software Development Life Cycle (SDLC) Management – July 30th

Event Calendar and Info

http://www.utahtechcouncil.org/Events/Community-Events/Community-Calendar.aspx

Hope to see you there!

Mike J. Berry
www.RedRockResearch.com