You Want IT When?

While reading a June 12, 2008 Time Magazine article “How He Did It,” an account of how Barack Obama came to win the Democratic nomination, it reminded me of the dynamics of a software project.   Early in the Obama’s campaign near panic set in as Obama was drawing record crowds and record donations, but he still trailed Hillary Clinton by 20 points in the polls.   Many in his campaign feared his approach to politicking would not get the job done.  Obama’s “top moneymen were urging him to rethink his strategy, shake up his staff, go negative.” 

(more…)

What happened to the software industry?  I hate professional certifications.  It didn’t used to be this way.  Many employers are looking for the certificate du jour on your resume as a filter for an interview.  Having a certification means nothing.  I remember as a child it was a big thing if someone had their black belt in Karate.  It meant they were tough until they picked a fight with the real tough guy who knew nothing about Karate.  Everyone was awed.  “Did you know Johnny beat up Tommy who has black belt in Karate, and Johnny can’t even spell Karate?”

There is a huge difference between what you know and what you can do, and a certificate signifies neither.  It only means you met the requirements for being awarded a certificate.  I went to High School with friends who cheated their entire way through High School.  One was even able to receive a college diploma by cheating his way through.  He neither knew anything nor could he do anything related to that certificate.  However, that’s the extreme. 

(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…)

You’ve probably been there, working to deliver on one of those unrealistic schedules.  They all roughly follow the same trajectory.  The marketing team sponsors the next project with a must hit inflexible date, an inflexible set of must have requirements, and an inflexible fixed budget.  As the software manager responsible for delivering the release, you attempt to bring some reality to the situation, but you instantly conclude it is hopeless: there’s no changing your circumstances, and if you continue to try, it will only harm you. 

This is when many mangers make the fatal mistake: they immediately start the team coding.  There is no time to plan, no time to document, no time for meetings, no time for reviews, and no time for unit testing.  There is only time to code it, build it, pass it to QA for testing, find defects, and repeat the process until the release date. Then, someone makes a decision to either release it as is or slip the date and apply more pressure.

(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…)

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…)

The Agile software development practices are in their infancy stage as evidenced by the number of variants that are being promoted in popular print and usage today:  Scrum and XP being two popular variants.  Clearly the Agile practices are still evolving, and I believe what will eventually emerge are a set of Agile practices that look awfully familiar to traditional approaches.  The question is, is once the Agile community arrives there, will the conflict cease?

(more…)

Have you ever wondered why software process has yet to flourish in the software industry?  Why, after many decades of industry growth, there is no consensus on a process methodology or even best practices?  Why specious Agile approaches have captured significant mindshare in the software community?  Why when you mention the words software process, software professionals cringe?

In other industries process innovation has been the contributing factor in the explosive growth.  Where would the industrial revolution be without the innovation of assembly line processes?  Where would the auto industry be?  A predictable, repeatable process has been the cornerstone of innovation and quality for many successful industries.  Did you ever wonder why a hamburger and french-fries at McDonalds taste the same no matter where in the world you purchase it?  It’s all about process.

It’s an enigma to me and others who have had great success with software process that we continue to debate the need for formal process in the software industry.  Yet the software industry continues unabated with a record of late deliveries, budget overruns, missed expectations, and low quality.  In this article, I’d like to explore the factors that contribute to software process adoption failure.

(more…)