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.
One of the difficulties I have with the Agile software methodologies and its proponents is that they go to far. They are often susceptible to hyperbole while hawking their methodology like used car salesmen. Their embracing of the practice of refactoring is one example of this. Of course, we should refactor, but refactoring isn’t a design methodology, it isn’t a way to be agile, and it doesn’t help deliver software faster. Refactoring as advocated by the Agile processes is essentially a design methodology. A team following Agile arrives at an optimal design and implementation via a series of iterations and refactoring efforts. Refactoring as a design methodology is incompatible with the Agile goals of delivering faster and accommodating change anytime in the project life-cycle.
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.
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.
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.
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.
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.
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?
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.
There’s a lot of activity and promotion of the Agile software methodologies that can be found on both the Internet and in books today. Its adherents are zealous in their commitment to the Agile principles codified in the principles behind the Agile Manifesto. I first became interested in the Agile development practices when the Extreme Programming practices began generating a lot of interest in the software community. My first reaction to this was to be turned off. The name conjured up images of chaos, cowboy programmers, and death march development projects — practices I am all too familiar with. I found the advocacy of pair programming to be unnatural and impractical.
After reading many articles published by Agile proponents, I remain steadfast in my beliefs that something is wrong, and rather than advancing the state of the art practices in Software Development, Agile proponents are setting us back, and in this world where jobs easily cross international boarders, especially easy in software, we need practices that demonstrate the value proposition for keeping teams here in the US: practices that deliver reliably and predictably on commitments and practices that can demonstrate improvements in productivity and quality.
This work is licensed under a
Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.
You Want IT When? © 2007 All Rights Reserved. Using WordPress 2.5.1 Engine
Entries and Comments.
Prosumer 1.4 made by Nurudin Jauhari
