Software, the war, the battles
In general terms, the word "War" has a bad connotation. Many lives have been lost and so much suffering caused since the very first dispute over some land or water source, don't make an easy task to argue in favor of war. However, bitter experiences leave lessons and learnings that I can list but, sincerely, I doubt myself doing a better job than what the excellent Lean Enterprise book does as follows:
Uncertainty is expressed in questions: What users need or appreciate? What is to be built? How much time it takes? How much is going to cost? In attempting to answer them, many proposal have been put on the table; all of them with the best intentions, few of them really effective. Let me take, for example, Gantt charts. Even in the 21st century and after failing over, and over, and over again, many people still believe that a Gantt chart provides certainty on how a software project will be; it doesn't. More often than not or desired, projects failed for the same exact reasons wars are lost: to ignore or skip the fundamentals on how to fight to win.
Let's grab the fundamental "nor planning beyond the circumstances you can foresee" and add another from the The Art of War: "There is no instance of a country having benefited from prolonged warfare.". At this point I come to the following conclussion: wars are easier to win if they are short in duration. One battle at a time, the next hill to conquer.
A software project battle is defined by the next most important functionality to accomplish. It is also time-framed by the development team and no one else: not the managers, not the CEO, not the salespersons. How to determine the most important functionality to accomplish and how to estimate responsibly deserve articles on their own. Suffice it to say that keeping in mind that not planning beyond the foreseeable circumstances is prime. The foreseeing ability is different for everyone. In my case, it's enough for the next three, ten, but no more than thirty days while keeping in mind that circumstances change very rapidly so, another ability, comes very handy: to adapt.
In contrast, Gantt chart-driven software projects failed because they are started without enough information (high degree of uncertainty) and attempt to control too much for long periods of time. I have known of project plans spanning 6, 12, 18, 36 months and, sincerely, can't figure out why the future will behave so. Remember that no plan survives contact with the enemy. A Gantt chart and the crew in charge of it, don't tackle uncertainty (the enemy) but rely on Whishful Thinking, one of the Classic Mistakes cited by Steve McConnell: "Wishful thinking isn’t just optimism. It’s closing your eyes and hoping something works when you have no reasonable basis for thinking it. It's knowing that something can't be done but agreeing to try anyway. Wishful thinking at the beginning of a project leads to big blowups at the end. It undermines planning and is at the root of more problems than all the other mistakes combined."
Successful software projects have more to do with performing short duration cycles for creating functional increments that, by their additive property, led to the proverbial "the whole is greater than the sum of its parts" while receiving continuous feedback from every possible source to react and adapt. It's extremely important to get in contact with the project ground from the very beginning because that's the better way to reduce or eliminate uncertainty. One more from The Art of War: "Hence the skillful fighter puts himself into a position which makes defeat impossible, and does not miss the moment for defeating the enemy." So, don't miss any moment for defeating uncertainty by having a handful of functionality requirements as detailed as possible instead of tons of them touched only by the surface. If we cannot win a one or two weeks project (a battle), there is no reason to think we can win the war.
- Napoleon used a style of war known as maneuver warfare to defeat larger, better-trained armies. A key element in maneuver warfare, the goal is being able to learn, make decisions, and act faster than your enemy.
- The Prussian Army, following its defeat by Napoleon, led by Carl von Clausewitz, David Scharnhorst, and Helmuth van Moltke, not only was reconstructed but improved through the idea of Auftragstaktik or Mission Command. Mission Command details go beyond this article but I extract the following as its main contributions:
- To recognize the authority to make decisions as the situation on the ground changed without waiting for approval through the chain of command which allow to adapt to rapidly changing circumstances.
- No plan survives contact with the enemy.
- In war, circumstances change very rapidly, and it is rare indeed for directions which cover a long period of time in a lot of detail to be fully carried out.
- Not commanding more than is strictly necessary, nor planning beyond the circumstances you can foresee.
The Software War
From my point of view, every software project is a war. The enemy? There are many but, if I have to choose the greater, uncertainty it is. Starting a software project with a high degree of uncertainty is the best first step to a failed software project as it goes against the classic Fred Brook's "No Silver Bullet" where "...the hardest single part of building a software system is deciding precisely what to build."Uncertainty is expressed in questions: What users need or appreciate? What is to be built? How much time it takes? How much is going to cost? In attempting to answer them, many proposal have been put on the table; all of them with the best intentions, few of them really effective. Let me take, for example, Gantt charts. Even in the 21st century and after failing over, and over, and over again, many people still believe that a Gantt chart provides certainty on how a software project will be; it doesn't. More often than not or desired, projects failed for the same exact reasons wars are lost: to ignore or skip the fundamentals on how to fight to win.
Let's grab the fundamental "nor planning beyond the circumstances you can foresee" and add another from the The Art of War: "There is no instance of a country having benefited from prolonged warfare.". At this point I come to the following conclussion: wars are easier to win if they are short in duration. One battle at a time, the next hill to conquer.
A software project battle is defined by the next most important functionality to accomplish. It is also time-framed by the development team and no one else: not the managers, not the CEO, not the salespersons. How to determine the most important functionality to accomplish and how to estimate responsibly deserve articles on their own. Suffice it to say that keeping in mind that not planning beyond the foreseeable circumstances is prime. The foreseeing ability is different for everyone. In my case, it's enough for the next three, ten, but no more than thirty days while keeping in mind that circumstances change very rapidly so, another ability, comes very handy: to adapt.
In contrast, Gantt chart-driven software projects failed because they are started without enough information (high degree of uncertainty) and attempt to control too much for long periods of time. I have known of project plans spanning 6, 12, 18, 36 months and, sincerely, can't figure out why the future will behave so. Remember that no plan survives contact with the enemy. A Gantt chart and the crew in charge of it, don't tackle uncertainty (the enemy) but rely on Whishful Thinking, one of the Classic Mistakes cited by Steve McConnell: "Wishful thinking isn’t just optimism. It’s closing your eyes and hoping something works when you have no reasonable basis for thinking it. It's knowing that something can't be done but agreeing to try anyway. Wishful thinking at the beginning of a project leads to big blowups at the end. It undermines planning and is at the root of more problems than all the other mistakes combined."
Successful software projects have more to do with performing short duration cycles for creating functional increments that, by their additive property, led to the proverbial "the whole is greater than the sum of its parts" while receiving continuous feedback from every possible source to react and adapt. It's extremely important to get in contact with the project ground from the very beginning because that's the better way to reduce or eliminate uncertainty. One more from The Art of War: "Hence the skillful fighter puts himself into a position which makes defeat impossible, and does not miss the moment for defeating the enemy." So, don't miss any moment for defeating uncertainty by having a handful of functionality requirements as detailed as possible instead of tons of them touched only by the surface. If we cannot win a one or two weeks project (a battle), there is no reason to think we can win the war.
Comments
Post a Comment