Sun Tzu wrote:
The enemy is complexity. Complexity comes from having to make dozens
of decisions correctly for your software project to even have a chance of
succeeding. For every thing that you
know at the outset of the project, there will be at least ten things that you
don't know. Complexity is compounded by making those decisions on a deadline, especially if that deadline is not well chosen.
Since the enemy is
complexity we can not deceive
it. Rather the problem is that we allow
ourselves to be deceived by complexity.
How often do you see developer's say that they can code anything over a weekend over a case of Red Bull?
That the impact of
your army may be like a grindstone dashed against an egg—this is effected by
the science of weak points and strong
Using Spies, 5 —6
The enemy is complexity and is intangible, i.e. invisible, odorless, and untouchable. Your spies are your business analysts, architects, and project managers.
Your business analysts will work with the business to define the scope of the complexity. Ask for anything you want, but commit to build all you ask!
Remember that all large complex systems that work are built from small simple systems that work, so aim to build the smallest usable product initially. Asking for too much and providing insufficient resources and/or time will lead to a failed project.
The architects provide checks and balances on the business analysts to make sure that the project is feasible.
The architects will provide key dependency information to the project managers who make sure that a proper execution plan is created and followed.
Each of these spies sees a different aspect of complexity that is not visible to other people. Unless the reports of three types is combined effectively you risk not knowing the extent of the software that you are trying to build. If you go into battle without proper intelligence you are back to the scenario of the Charge of the Light Brigade.
Winning whole in a
software project means delivering the software on time and on budget without destroying the health and reputations
of your team (including management). Failed
projects extend their effects to every member of the team and everyone's
resume.
War is of vital importance to the
state; hence it is a subject of inquiry which can on no account be neglected.
In our modern world, software is of vital importance to your
organization. If you can build software
consistently and reliably you will gain a tremendous advantage over your
competition.
If developing software is like waging war then who is the enemy?
If developing software is like waging war then who is the enemy?
So when you consider launching a software project you are looking at the tip of the iceberg. Your ability to handle uncertainty will dictate how successful you will be.
Unlike a conventional war this enemy does not sleep, has no
obvious weaknesses, and can not be deceived.
Once you engage the enemy your success will depend on correctly
estimating the magnitude of complexity and making excellent decisions.
Sources of Uncertainty
If you know the enemy
and know yourself, you need not fear the result of a hundred battles. If you know
yourself but not the enemy, for every victory gained you will also suffer a
defeat. If you know neither the enemy nor yourself, you will succumb in every
battle.
Attack by Stratagem, p. 18
Uncertainty comes from a few main sources:
- Team resources unfamiliar with the technologies to be used
- Requirements that are incomplete or inconsistent
- Technical requirements that turn out to be infeasible
- Inability to understand project dependencies
- Inability to formulate a correct and understandable plan
Unfortunately the way most organizations develop software resembles
the Charge
of the Light Brigade (poem).
In that battle about 400 men on horses attacked 20 battalions of infantry supported by 50 artillery pieces.
Needless to say it was a slaughter.
In that battle about 400 men on horses attacked 20 battalions of infantry supported by 50 artillery pieces.
Needless to say it was a slaughter.
The Art of War (online)
Several principles outlined by Sun Tzu apply to software
development as well:
- Deception
- Leading to advantage
- Energy
- Using Spies
- Strengths and weaknesses
- Winning whole
Deception
How often do you see developer's say that they can code anything over a weekend over a case of Red Bull?
People generally do not launch software projects because
they want to fail; but when only 3
out of 10 projects succeed, it shows that people have been deceived about the complexity
of building software.
This statistic has haunted us for 50 years.
This statistic has haunted us for 50 years.
Senior management should really pause and consider if all
their ducks are lined up in a row before embarking on a software project. Unfortunately senior management is still underestimating complexity and sending teams to face virtually impossible projects.
Leading to advantage
Thus it is that in war
the victorious strategist seeks battle after the victory has been won, whereas
he who is destined to defeat first fights and afterwards looks for victory in
the midst of the fight.
Tactical Dispositions, p. 15
Tactical Dispositions, p. 15
Complexity emerges from the sources of uncertainty mentioned
above. Successful organizations plan to remove known uncertainties and
have a plan to handle the ones that will emerge. Getting into a project before understanding
the magnitude of the uncertainty is a recipe for failure.
Energy
Energy, p. 4
The team's energy needs to be directed against uncertainty with
appropriate force at the appropriate time.
When this happens uncertainty will be minimized and the chances for
success will increase.
It is imperative to create a table of all risks that
might affect your software project. If
you aggressively minimize the probability of risks triggering you will reduce
uncertainty and increase your chances of success.
Software projects succeed when there is a rhythm to the attack on complexity. High intensity problem solving needs to be followed by lower intensity stability building. The team must move at a sustainable pace or risk burning out. Software teams do not succeed when they are working 10+ hours a day; they become like dull swords -- unable to do anything.
Software projects succeed when there is a rhythm to the attack on complexity. High intensity problem solving needs to be followed by lower intensity stability building. The team must move at a sustainable pace or risk burning out. Software teams do not succeed when they are working 10+ hours a day; they become like dull swords -- unable to do anything.
Using Spies
Foreknowledge cannot be elicited from ghosts and spirits; it cannot be inferred from comparison of previous events, or from the calculations of the heavens, but must be obtained from people who have knowledge of the enemy's situation.Using Spies, 5 —6
The enemy is complexity and is intangible, i.e. invisible, odorless, and untouchable. Your spies are your business analysts, architects, and project managers.
Your business analysts will work with the business to define the scope of the complexity. Ask for anything you want, but commit to build all you ask!
Remember that all large complex systems that work are built from small simple systems that work, so aim to build the smallest usable product initially. Asking for too much and providing insufficient resources and/or time will lead to a failed project.
The architects provide checks and balances on the business analysts to make sure that the project is feasible.
The architects will provide key dependency information to the project managers who make sure that a proper execution plan is created and followed.
Each of these spies sees a different aspect of complexity that is not visible to other people. Unless the reports of three types is combined effectively you risk not knowing the extent of the software that you are trying to build. If you go into battle without proper intelligence you are back to the scenario of the Charge of the Light Brigade.
Strengths and weaknesses
Military tactics are
like unto water; for water in its natural course runs away from high places and
hastens downwards. So in war, the way is
to avoid what is strong and to strike at what is weak.
Weak Points and Strong, p. 29—30
Weak Points and Strong, p. 29—30
Water exhibits ordered flexibility. It is ordered because it seeks to flow downhill;
however, it is flexible and will go around rocks and other obstacles. A software project needs to make continual
progress without getting sandbagged with obstacles. Methodologies like RUP or Agile software
development can make sure that you exhibit ordered flexibility.
Winning whole
When you engage in
actual fighting, if victory is long in coming, then men's weapons will grow
dull and their ardor will be damped.
Waging War, p. 3
Waging War, p. 3
When organizations bite off more than they can chew they
exert tremendous pressures on the team resources to work extended hours to make
deadlines that are often unrealistic.
In the pressure cooker you can expect key personnel to defect and put you into a worse position. How many times have you found yourself on a Death March?
In the pressure cooker you can expect key personnel to defect and put you into a worse position. How many times have you found yourself on a Death March?
Conclusion
Both waging war and software development are serious topics
that involve important struggles. If software
development is a war against ignorance, uncertainty, and complexity then many
of the strategies and tactics outlined in The Art of War give us direction on
how to execute a successful project.
No comments:
Post a Comment