You cannot test quality into software

I've seen many test approaches and most have been successful, except for one and it was not necessarily a test approach.  It was more of the customer over committing to a calendar event, and not focused on the software lifecycle.  

The problem was that the customer requirements were never really nailed down upfront, so they became a moving target.  Once they were identified, the developer had already committed his team to what they thought the customer would want.  Unfortunately, it was not what the customer wanted.  So, many meetings and conference calls were scheduled to determine what would be the best get well plan.  All of this time ate into the development time and the customer began compressing the test cycle.

Unfortunately, there were many problems with the software because of early decisions and non-decisions regarding requirements.  The code rework and moving the development team around introduced errors, but the epicenter of the problem started with the customer.  Committing to a schedule without a hardened set of requirements is asking for trouble.  No matter the development approach, be it agile or waterfall, one must know the desired outcome by defining the requirements upfront.

When the software finally arrived, the test team was pushed hard to finish on time; on time meaning the artificial date set when everything looked great on day one.  I believe the test team lost some where around eight weeks of test time, but they were expected to meet the delivery date despite no relief on testing requirements.  Many critical errors were found in the beginning of the testing which obviously elevated the emotions of everyone involved, as we were all beginning to see the train wreck coming.  The test lead was doing his best to juggle everything and continue to get his team to focus on their test plan.

At one meeting, the test lead started his update with this phrase, "We cannot test quality into the software."  It was brilliant.  Without screaming the software was not ready for testing, he put everyone on notice that the software would not be ready for primetime no matter how hard his team worked.  You have guessed correctly if you just thought that people took offense to the statement and disagreed that there was a problem.  His charts showed another story, as there were critical errors all over the system, which were going to require a patch...a patch was identified before the system was even released.  The level of effort was hundreds of hours of development and re-testing of the modules.  It was not pretty.

Ultimately, the customer backed off the artificial delivery date, and a patch was delivered and tested.  A lot of egos were bruised, as the team had a lot of "can do" attitudes who felt they could do anything when, in reality, they should have been saying NO.  It was a great lessons learned for everyone.  We're still not ready to laugh about it.

Can you be a soccer coach and a project lead?

A couple of years ago, a friend and I coached a soccer team.  Neither of us had ever coached soccer, so we learned as the season progressed.  Our girls did well despite our missteps.  But, that's not the topic.  I was cleaning up my computer files and found the "Coaches Guidelines" document that was provided by the league to all coaches (new and old).  Most of it was common sense, but it had good info to have available.

What's interesting about it is how easily this soccer coach guideline can be applied to a software development effort.  Certainly some of the highlighted items below are bit of a stretch for me to bridge the connection between soccer coaching and software development.  But, I'm going to give it a try.  Let's see how this works....

Coach

• Communicate.  Inform parents and players of schedules, locations, rules and items needed at practice and games.
• Keep it fun.  While we want our team to learn the game (skills and sportsmanship), this is not military basic training and the players should be enjoying themselves while learning.
• Plan each practice.  Have a written plan for each practice to ensure progression of skills through the season.
• Be prepared.  Ensure the field is ready to start practice on time.  Kids standing around, waiting generally results in “not fun” and “not learning”
• Ball touches count.  Be sure practices allow as many touches as possible for each player.  Standing has little instructional value.
• Be on time for practice.  Last player to practice is on "cone duty". Cone duty is picking up all the cones and gear at the end of practice.
• Positive encouragement is good; negative comments are bad.
• Cheering is good, but do not yell at your child or anyone else's child during the game. It can be distracting and what you tell them may be different from what the coaches are saying. If you would like to be an assistant coach, please call me, I would love your help.
• Be careful not to say anything that might be taken the wrong way or hurt someone's feelings. Remember: this is for fun and these are children.
• Be a good role model and a good sport."
• Do not yell at the Referees or say anything bad to or about the other team. Never boo the other team or cheer when they make a mistake.

So, what do you think?  Do you agree how easy it is to make the leap from the field to the scrum?

This video is an example of how not to do it.

What I learned from the brick layer

I was stopped at a red light as I driving home from work last night and saw a bricklayer working.  He was laying the first brick on what appeared to be the beginning of a very large retaining wall.  As I was driving away, the thought occurred to me that the first brick has to be the most important, for the entire wall will be built incorrectly if that first brick is askew.  It also occurred to me that this also applies to system development of any size or complexity.

You start with your idea of a grand, new system, but you don't start out building that new system.  You instead plan and consider what direction you want to take your system.  How large, how many customers, continuous availability, the list can grow according to your desires.

In bricklaying, just like in software development, you start with the plan to build the best brick wall ever seen, but you don't just start building a wall.  Instead, you must begin with the very first brick.  That first brick is what will make your entire brick wall successful.  Place that brick at an angle and everything following it will be angled until either you realize your mistake or until it topples.  A poorly designed software package will eventually topple, too, if not carefully considered and planned - no matter if you are using agile or waterfall methods.

There are many that believe one can just start whipping code together and figure it out as you go.  Sure, you can do that.  Anyone is capable of that.  It is those that stop to ponder how they really want their system to behave and respond to customers that will have the successful software experience; whether their business idea is a good one is not relavant.  We can learn and apply many things that are outside our domain by just stopping and considering how other's approach problems.

So, what have you learned from others outside your domain that have helped you in your business?