War and Software development strategies — Part 2. Sun Tzu’s The art of war
In case you haven’t got the chance to read them yet.
We are going to explore how Sun Tzu’s The Art of War written in the 6th century BC, a Chinese military treatise that is still revered today as the ultimate commentary on war and military is very similar to certain business principles, we use nowadays in software development. Unlike some I am not going to argue that every principle is actually very well confined in our paradigm, however, while some of those contradict agile they are very well aligned with
Waterfall methodology
“Now the general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes, but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all.”
The very opposite of Agile right? However, Waterfall was here long before many of us started writing code and many of us might still use it in certain situations, but software development is about today, or even about tomorrow, right? So let us see what interops with Agile.
Iterative development
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. If you lay siege to a town, you will exhaust your strength.
There is no instance of a country having benefited from prolonged warfare.
In war, then, let your great object be victory, not lengthy campaigns.
If you march 50 LI in order to outmaneuver the enemy, you will lose the leader of your first division, and only half your force will reach the goal.If you march 30 LI with the same object, two-thirds of your army will arrive.
All those are very correlated with the sixth’s principle of scrum
This is why we are having sprints instead of long periods of development, Operating in small iterations will bring continuous value to the business, conserve team strength, keep the team morale high and enjoy the client’s trust, deliver an MVP
Scum instruments for keeping control
The control of a large force is the same principle as the control of a few men: It is merely a question of dividing up their numbers.
Fighting with a large army under your command is nowise different from fighting with a small one: It is merely a question of instituting signs and signals.
This is where we talk about instruments such as the Dailies the dashboard and the burn-down chart, Scrum, and the Scrum of Scrums for larger teams.
Team superpower
The clever combatant looks to the effect of combined energy and does not require too much from individuals. Hence his ability to pick out the right men and utilize combined energy.
This is about the team superpower
As we know the team always does more than on the talented individual, mentioned more than once.
Teams are what get things done in the world of work. — Jeff Sutherland
Estimations
Ponder and deliberate before you make a move.
Estimations, backlog grooming, as we all know is the secret sauce that keeps us going.
Propper control and requirements
When the general is weak and without authority; when his orders are not clear and distinct; when there are no fixed duties assigned to officers and men, the result is utter disorganization.
Unclear requirements, no team lead, no BA, no definition of done, we all know how it ends right?
MVP and MMF
Move not unless you see an advantage; use not your troops unless there is something to be gained; fight not unless the position is critical.
If it is to your advantage, make a forward move; if not, stay where you are.
MMF is erroneously equated to MVP. MMF is about delivering value to customers, whereas MVP is about learning more about the ultimate product, but both reinforce the idea that we should seek the minimum functionality in order to accomplish a specific outcome and not waste more resources than we have to.
Conclusion
So to sum up, our efficiency in software development is very much tied with lessons understandings the cruel truths the war has taught us, so next time you write code, try to remember some of those principles were written in blood,
so please do your best to follow ;)
