You Want IT When?

Early in my career I had the good fortune to work under a management team that valued producing high quality applications - ones that rarely, if ever, crash under continual load.   The director of the department believed, not only in words but in action, that a defect discovered in the field is significantly more costly to fix than one discovered in development.  We lived by that rule, and we all believed in it.  

For this product, we did not have a sustaining engineering team to fix and deliver patches to the field because it was simply not needed. Over the course of the seven years of working on this team through multiple product deliveries, I recall only two or three issues from the field that required an engineering fix.   Now think of all the features you could deliver by investing the money saved in a sustaining engineering team into new feature development. That’s what we did.

I’d like to describe the six practices required to produce and release stable applications.  The level of stability that you achieve in your products will correlate to the degree to which you commit to these practices.  The strategy by itself isn’t enough to achieve great results.  Great results require discipline, persistence, and a strong will, and most importantly, it requires a leader and a team that values quality above all other criteria.

(more…)

I’m reminded of an interview I had with a young company for a Software Director role.  They were at point where they were ready to begin rapidly acquiring new customers.  When a new customer signed, there was customization required to have the system operate according to the customer’s demanding requirements.   The turnaround time from signing the new customer and having them productively using the system was approximately four weeks - at least that was the goal. 

(more…)

Purpose 

To clarify some possible misconceptions about the goal of this article series, it is NOT to advocate that there should be unrealistic schedules.  Quite the contrary, I don’t support expecting a team to deliver herculean efforts.  It’s an unsustainable model.  However, dates and requirements are often forced upon software teams, and they often have little ability to influence the commitments, both in date and content.  The goal of this series is to outline a model to successfully manage through these challenging circumstances for the benefit of the company, the team, and yourself.

(more…)

Management Approach

I’ve identified eleven tasks that I believe are essential for delivering to an unrealistic schedule.  While the tasks are numbered, they signify a loose priority.  It’s not intended for them to be followed exactly one after the other except for the first two.  The first two are the most important of the tasks, and the approach hinges on the first two for this to be successful.  When you’ve completed the first two tasks you’ve essentially identified your strategy.

(more…)

What’s your worst fear as a software professional? My worst fear is changing jobs and joining a team that is in crisis. You’ve probably been part of a team, heard about a team or witnessed another team in your company deliver to one of those unrealistic schedules.  Often times, the project starts off right, but entropy slowly builds as changes are introduced to the schedule with the velocity of an open fire hydrant.  It doesn’t start that way: it builds with a crescendo.  It’s not a case of replacing the old water with new water; it’s a case of filling a pool that’s filled 98% of capacity while watching the water spill over the sides and drain into the streets.

It’s not the fear of working hard, long hours, or getting my hands dirty that concerns me - in fact I find crisis invigorating - it’s whether I’ll be empowered to make the changes required to right the ship that concerns me most.  There’s nothing like the feeling of dread when participating in an endeavor that controls your life because the leadership is making mistaken decisions that you believe are the root cause of your undesirable circumstances: the kind of decisions that dig the project into a deeper and deeper hole.

Well it happened to me when I started a new job as a Software Development Manager in 1999.  When I arrived at the office on that first Monday, I was the first one to arrive, and when the first veteran employee arrived, he greeted me with the traditional first hellos and said, “yeah, the guys will be strolling in late today, they just worked through the weekend.”  I knew instantly that things were going to be interesting, and I was not to be disappointed.

(more…)

It happened when I participated for the first time on a SEI/CMM process improvement initiative at my employer.  That’s when I realized the power of software metrics.  Instead of handing us a ready made process to follow, each of the different product organizations were tasked with the objective of developing their own processes with the goal of achieving Level 2 certification.   Each group formed teams around the key process areas (KPA) to develop the practices to be followed.  It was without a doubt the best process improvement experience of my career changing the way I manage and view software management permanently.  

When the process areas were complete, it was then my responsibility as a Technical Project Leader to use the processes developed on the implementation of my next assignment.  While there was skepticism with the initiative, the organization I worked in decided that they were going to support it and give it a good college try, and we did.  Some organizations simply wrote the procedures and loosely followed their processes, which is more often the case.

That’s when the epiphany happened.  One of the key principles for estimating is to first size the project and permute the size into a duration using historical data or industry standard data when no historical data exists.   Since we never recorded this type of data before, we used industry standard data, or what we believed to be.   Once the estimates were developed and work began, the power of that approach revealed itself when I began to track the project.  The tracking KPA required that all estimating assumptions be tracked, both time and size.

(more…)

When I was a high school student I was an avid competitor in the sport of wrestling.  It’s an extremely demanding and punishing sport: requiring extreme stamina, strength, skill, agility, and mental toughness.  You have to have a strong mind to compete successfully in wrestling.  When you’re in the 3rd period of a match, you’re exhausted, and your opponent continues aggressively to push the action, only the tough-minded continue to fight and pull out a win.

Preparation for competition is key and demanding.  Practices are lengthy, exhausting, painful, and mentally draining.  It is common for a wrestler to lose anywhere from 3 to 10 pounds of body weight in a single practice.  Preparation requires discipline to keep with a training and weight loss program.  The diet can drain an athlete mentally having to refrain from the daily temptations of satisfying treats.

(more…)

Did you ever read one of those articles where the writer had instant credibility?  I recently stumbled upon one when I was looking to get my web site indexed on dmoz.org.  The article is titled “Nine Steps to Delivering Defect-Free Software” by Terence M. Colligan.  When I read the article I knew he isn’t just writing about somebody else’s experience because it mirrored my own experiences when I was writing software myself.  In the article he identifies nine traits contributing to defect free code.

(more…)

Does your final project schedule look identical to the project schedule that you began your release with?  If it does, you either aren’t managing your schedule or you are working on a dead product.  Project Management is predominantly an exercise in change management - so much so that I like to think of them as synonyms for one another. 

There are two primary sources of schedule change.  One source is when the actual productivity doesn’t match the budgets in your work break down structure.  The other source, the more problematic source of change, is when your requirements change.  This article will concentrate on managing changing requirements.

(more…)

Have you ever been so frustrated with a piece of software that you wanted to scream?  I’m sure it’s happened to you.  You’ve just completed a part of your project that you’ve worked so hard to get right and then – poof — magically the application goes away and you just lost all of your important changes. It happened to me when I started to get involved in video editing. It was difficult to find an application that I could successfully complete an entire project.  I evaluated many of them before I settled on Adobe Premiere, and even that was buggy; it happened to be the best of the field of video editing applications.

(more…)