Whiteboards for Everyone!

Do you like designing on whiteboards?  I do.   Colorful markers against a clean, white surface inspire all kinds of creativity and fun.

Recently David Crossett of Ready Receipts gave me a great tip.  He told me that instead of going to your local OfficeBOX superstore and paying $200 for a 4×8 whiteboard, just hit HomeDepot instead and get a $12 piece of showerboard.  It works just as good and if you need a smaller size they will cut it for you on site for no additional charge!  At that price, you can line your walls with thinking space.  Power to the Consumer–thanks David!

Mike J. Berry
www.RedRockResearch.com

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

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

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

How to compute % defects removed from release candidate code

Recently someone on StackOverflow.com asked me to explain how to compute the defect removal rate for release candidate software.  There are two methods for producing this number and I teach both in several of my seminars, but I’ll explain the simpler method in this post…

Lawrence Putnam presented this model in his 1992 Book titled Measures for Excellence.  His book reads more like a math text than a software development guide, and suffers from an unfortunate formula typo which has lead to widespread confusion about his models in the industry, but I will  explain his defect removal rate calculation process.  (I hired a math wizard to examine his data and correct the formula!)

1. For a typical project, code is produced at a rate which resembles a Rayleigh curve.  A Rayleigh curve looks like a bell curve with a long-tail.  See my ASCII graphics below:

||||
|||||||||||
|||||||||||||||||
|||||||||||||||||||||||

2. Error ‘creation’ typically happens in parallel and proportional to code creation.  So, you can think of errors created (or injected) into code as a smaller Rayleigh curve:

||||
|||+++|||||
||||+++++|||||
||||+++++++||||||||

where ‘|’ represents code, and ‘+’ represents errors

3. Therefore, as defects are found, their ‘detection rate’ will also follow a Rayleigh curve.  At some point your defect discovery rate will peak and then start to lesson.  This peak, or apex, is about 40% of the volume of a Rayleigh curve.

4. So, when your defect rate peaks and starts to diminish, factor the peak as 40% of all defects found, then use regression analysis to calculate how many defects are still in the code and not found yet.

By regression analysis I mean if you found 37 defects at the apex after three weeks of testing, you know two things:  37 = 40% of defects in code, so code contains ~ (37 * 100/40) = ~ 93 errors total, and your finding about 10.2 defects per week, so total testing time will be about 9 weeks.

Of course, this assumes complete code coverage and a constant rate of testing.

Hope this is clear.

Mike J. Berry
www.RedRockResearch.com

A Free Software Requirements Specification Template (SRS)!

Need a good software requirements specification (SRS) template?  Use an industry-standard SRS.  Can’t find one?  Well now you have-get it here for free.  Enjoy!

Mike J. Berry
www.RedRockResearch.com
Software Development Process Guidance

Excellence over Heroics

I value Excellence over Heroics.

‘Excellence’ can be defined as “the crisp execution of established procedures.”  Think about that for a minute.

Do you know of a software development shop where several prominent developers often stay up late into the night, or come in regularly over the weekend to solve high-profile problems, or put out urgent mission-critical fires?

The thrill of delivering when the whole company’s reputation is at stake can be addictive.  I remember once staying up 37 hours in-a-row to deliver an EDI package for a bankers convention.  I was successful, delivering the application just before it was to be demo’d.  I went home and slept for 24 hours straight afterwards.

The problem with ‘Heriocs’ is that the hero is compensating for the effects of a broken process.  Think about that for a minute.

If heroes are needed to make a software development project successful, then really something upstream is broken.

Most problems requiring heroics at the end of a project stem from improper effort estimations, inability to control scope, inadequate project tracking transparency, mismanaged Q/A scheduling, unnecessary gold-plating, or inadequate communication between the development team and the project users/stakeholders.

A well-organized development group humms along like a well-oiled machine.  Proper project scoping, analysis, design deconstruction, estimating, tracking, and healthy communication between development and the users/stakeholders will bring that excellence that trumps heroics.

Hey, I hear that Microsoft is looking for some Heroes.

Mike J. Berry
www.RedRockResearch.com

NewsCHIME.com passes the 100+ repeat visitor mark!

Posted by mikeberry | Agile Executives,Leadership,Most Popular,Strategy & Portfolio Management,Uncategorized | Thursday 23 October 2008 11:11 am

NewsCHIME.com, the ‘News from everywhere, every 10 minutes’ website has officially passed the 100+ repeat visitor mark!  This site was launched in May of ’08 with no advertising at all, and now enjoys more than 100 repeat visitors, and over 1000 unique visits per month.

I classify a ‘repeat visitor’ as somebody who has come back four or more times.   The number four is kind of arbitrary, but I think somebody who comes back only once or twice is not really a captive audience participant.  They are more link a potential customer peering into the store window.

NewsCHIME.com was created to bring headline news to people who, like me, love to read the news.   We love it so much, in fact, that that’s all we want to see on the site–news headlines and nothing else.

Have a BlackBerry and a few spare minutes between (or during) your meetings?  Go to NewsCHIME.com and check out what’s happing across the world!

Need to do research for education, work, or personal interest?  You can search for headlines topics from the past 18 months or so on the search page.

This works great if you are expected to know about something newsworthy in a short amount of time.

For example, a search for ‘Obama’ or ‘McCain’ and a quick headline perusal will give you a one-sentence summary of everything noteworthy these candidates have done for the past 18 months.  10 minutes on NewsCHIME and you be more infomed about the upcoming presidential election than more than 300 million other people.

Need research project material on the mortgage meltdown, type ‘mortgage’ and you’ll see the unfortunate play-by-play.

Be sure to take note of what you will NOT see at NewsCHIME.com.  You will not see lots of useless links to various websites that have nothing to do with your topic.  You will not see pictures of dancing people,  and you will not see ads from GM, Chevy or eHarmony.

I almost forgot to mention, NewsCHIME has free news alerts!  That’s right, Free!  Sign up and select which search criteria you want, and as those terms are named in news events you’ll be the first one to know about them.

So, impress your friends, impress your boss, impress you teacher.  The faster you can get at information, the more beneficial your decisions will become.  Enjoy.

Mike J. Berry
www.RedRockResearch.com

Anti-Values

I was sitting in a KFC eating lunch, reading the slogans painted on the wall.  This particular KFC is supposedly the first KFC in America.  Yes, it’s in Utah.  Along with some chicken legs and a drink, you can enjoy a small exhibit showing Colonel Sander’s original briefcase, white suite, shoes, etc.

One mural read, “Somehow we’ll do it, by the principles of thrift, honor, integrity, and charity.”

I thought for a moment.  Some of the financial service companies I’ve worked with would fail if they valued charity.  Then I thought about how trust is a wonderful interpersonal dynamic, but the companies I’ve worked with in the medical field allow no latitude for trust.  Everything must be written down and authorized by a credentialed physician.  Walk into a pharmacy and you’ll need a signature on piece of paper to get a prescription filled.

Hmmm, just like charity is an anti-value in the financial services industry, trust is an anti-value in the medical industry.

I spent the day thinking about this new concept.  I owe the title of ‘Anti-Value’ to the Discovery-Channel documentary about Anti-Matter I was watching the night before.  I  guess I’m coining the phrase here, but it makes a lot of sense to me.  Normally, a value is something our society charishs, yet in a particular situation, or line of business–it becomes the wrong thing to do.

I started seeing how this concept can be applied all over to help clarify the decision making process.

I remembered taking third place instead of second in a Maryland school-district programming competition in high school because I let the guy from our rival high school cut in line in front of me to turn in his test.  When the results were announced we had both scored the same grade, but because he handed his paper in first, he won second place and I won third. (I beat him in the State programming competition the following month.)

I’ve never forgotten this experience, and actually now that I think about it, offering your competitor any leeway is an anti-value.

Some business meetings I’ve been involved in are a collage of participants cutting other participants off mid-sentence to make their point known.  Rude? Yes.  But, in fact, politeness may be considered an anti-value in these types of situations.

I think the concept is fascinating.  Just as a good value system should be in place to help an organization, department, team, or individual govern their decisions, an anti-value system can compliment a value-system by providing additional clarity for the decision making process.

One example of this is the U.S. government’s policy on dealing with terrorists.  The government values having a “no negotiating with terrorists” policy.  As a disincentive to future terrorism, they have an additional policy to provide or produce exactly the opposite of what the terrorists are demanding.  The notion–to give them what they want–really becomes an anti-value, and is an additional input to the decision-making process.  So, in fact, their policy is set by values, and anti-values.

I hope you find this concept as fascinating as I do.  It was the best $7.79 I’ve spent on lunch in a while.

Mike J. Berry
www.RedRockResearch.com

Book Review: The 4-Hour Workweek

Posted by mikeberry | Agile Executives,Book Reviews,Leadership,Most Popular | Monday 10 December 2007 2:43 pm

I just finished reading The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich, by Timothy Ferriss.  Timothy Ferriss is a 29-year old self-made millionaire, TV actor in China, athletic advisor to more than 30 world record holders, Chinese Kickboxing Champion, first American to hold Guinness world record in Tango, speaker of four languages, and a four-world champion cage fighter.   This book now makes him an author.

Ferriss’s book is about beating Corporate America, and becoming content and happy using the newer technologies available to us today.

He provides a formula for successful entrepreneurship.  One important point he makes is the need to find a market, before investing in building the product.  He suggests this successful pattern:

  1. Pick an industry you understand.
  2. Target a product you can Create, License, or Resell.
  3. Look at competition to see how you need to differentiate your product.  Examples:
    1. More credibility indicators
    2. Offer a better guarantee
    3. Offer a better selection
    4. Offer free, or faster shipping
  4. Micro-test your product (before you put any money into it), by using eBay, or Google Ad’s.  Microtesting is “probing” customers to see if they would buy the product.  Some examples:
    1. Put an add on eBay, then cancel the add minutes before the auction ends, to see how much people are willing to pay.
    2. Build a dummy website, with item, description, pictures, and pricing.  After the user pressed ‘purchase now,’ display a “Thank you but this item is temporarily unavailable.”  This enables you to test your conversion rate up front, without needing to invest in manufacturing, etc.

This way, you can determine up front if there is a market for your product.  He suggests putting the price on a separate webpage altogether so you can measure the effects that changing the price alone will have on your conversion rate.

Ferris goes on to explain how to transform managing a business into automating the business.  He suggests time management is a thing of the past.  The key to living better today is to remove distracting inputs from our lives.

He talks about outsourcing every part of you business and empowering the outsourcers.  He talks about only answering email one day a week, and having your cell phone message redirect people to you email.

The final part of Ferriss’s book talks about what to do after you have successfully started and automated you business.  He talks about getting out of your comfort zone, travelling, learning new skills, and new languages.

I think this book is an excellent read, and surprisingly cutting-edge.  It’s nice to read a business book about PPC, Google AdWords, and eBay microtesting.   Makes me feel understood.

Mike J Berry
www.RedRockResearch.com