Testing with Sun Tzu - Chapter 13

The last one! Of all things Chapter XIII is about The Use Of Spies.

None of us should be working in an environment where we need to have people in place to give us information, that may work well in government or on television, but in real life groups need to work together and be able to have a modicum of trust. Still its no reason to let your back go unguarded, what spies really do is provide information, that is information you need for your project so if you don't have a handy spy or some hidden microphones, go and get the information yourself. Ask questions. Be curious and persistent, letting things go without getting an answer you need only causes trouble for you, and your project or your team. Keep an eye out for people in the know, and get to know them, not only because they may be nice, but they might give you a heads up in case something is coming up that you might need to know about. The more friends you have, the more you know.

Sun Tzu said: Raising a host of a hundred thousand men and marching them great distances entails heavy loss on the people and a drain on the resources of the State. The daily expenditure will amount to a thousand ounces of silver.

Armies are expensive, and complex to hold together and maintain. So are large groups and environments, having them just for the sake of being able to say you have them does not solve any problems. I'm not sure what a thousand ounces of silver costs nowadays, but its probably more than most people have budgeted, so count yourself lucky you don't have to carry all that silver around.

Hostile armies may face each other for years, striving for the victory which is decided in a single day. This being so, to remain in ignorance of the enemy's condition simply because one grudges the outlay of a hundred ounces of silver in honors and emoluments,

As said previously, many times, pre-modern armies would only fight if the conditions were good and they had positioned themselves properly, except of course in surprise attacks. But if the choice came to maintain something large and expensive just for the sake of being able to use it someday, or to pay once for something that would solve the issues quickly, what would you choose? I'd got for the solution I can get quickly, but I hate to waste money and while I can be a packrat, I don't like to do it at work when I can probably use the space for that someday solution for a beer fridge.

Thus, what enables the wise sovereign and the good general to strike and conquer, and achieve things beyond the reach of ordinary men, is FOREKNOWLEDGE.

It's always about information,or at least being able to know, or predict, what will happen. Good Project Managers make this look easy, I still don't know whether its from some sort of psychic ability or some weird sense of things from experience.

Now this foreknowledge cannot be elicited from spirits; it cannot be obtained inductively from experience,

Ok, so much for those ideas!

Knowledge of the enemy's dispositions can only be obtained from other men.

A ha! Direct observation, or at least some good reports. Can you say things like Status Reports or Milestones? I can.

Spies cannot be usefully employed without a certain intuitive sagacity.

Just sending one in without clear instructions or a goal doesn't help anyone. You have to know the information you need sometimes, or look for the gaps in your own knowledge to see what you might need. Or better yet, are there documentation holes that people have brought up, or have concerns on? Those look like good candidates for getting data on.

Without subtle ingenuity of mind, one cannot make certain of the truth of their reports.

Just because you asked a question and got an answer does not mean you have the right question and answer, be sure what it is you are looking for and asking. Sometimes the most important question is the one that has not been asked. Gaining data on projects is a tricky business, and sometimes you need large amounts of data that needs to flow up through various reports, and be paired with other data, to see where things truly are and the real state of affairs. Continually tune the data collection, people may ask for all kinds of data, and often just because someone in an important role asks for that data in a specific form does not mean that they know what they want. Question it, see if something else satisfies, see what they are looking for, it could be worth improving the current data collection to add this, or it could be a complete waste of time.

Finally number 13 done...sorry its taken a long time, I hope at the very least some questions have been sparked, I don't pretend to have all the answers but this was an interesting exercise for me as well.

Thanks for reading!

Testing with Sun Tzu - Chapter 12

In looking back there are multiple avenues of attack that Sun Tzu has mentioned and advocated, some are applicable to dealing with projects, people and resources. In Chapter XII The Attack By Fire he proposes ways to deal with your enemy by an old and, at the time, untamable force. I am not advocating any use of fire, while I admire Milt's conviction in Office Space I would not condone that avenue to anyone who is unhappy with their workplace, but there are some parallels that can be drawn. Fire has been useful to civilization going back in time, from slash and burn agriculture to its use is siegecraft, but its also unpredictable as can be seen by any area that has brushfires. California sees these often, and while there are always attempts at making fire breaks and keeping the flames isolated, any good wind can spread the sparks across large areas easily. While fire can be harnessed in some situations, in others it can be downright dangerous.

Sun Tzu said: There are five ways of attacking with fire. The first is to burn soldiers in their camp;

Nothing like making an opponents army lose everything in a big fire. This takes care of everything in one swoop, and while the army not only looses its supplies but inevitably some soldiers will be lost in either escaping or fighting the flames. Not much to condone here, unless you are looking for a way to sabotage something, and in that case you don't need my help.

the second is to burn stores;

Isolate the damage, removing needed resources not only harms the army in the future but can cause psychological damage as they may lose the will to fight, or at best now need to spend much time foraging. If they are in a land already stripped, then things can be grim indeed.

the third is to burn baggage trains;

The supplies following an army on the march, if these are lost the army is back to losing much of its supplies, except that which is carried, and is again either demoralized or back to foraging.

the fourth is to burn arsenals and magazines;

Removing the weapons from the army and it has lost the means to fight, having the will and the means is important, but without one or the other an army is severely weakened.

the fifth is to hurl dropping fire amongst the enemy.

In pre-modern times this would probably be from flaming arrows, to flaming oil from catapults or trebuchet's or even from Greek Fire. In modern armies its probably going to be from firebombs. Either way, fire in the midst of an enemy is also a good distraction.

So what can fire do for us? Not much in the realm of Testing or Projects. What you would want to do is watch out for fire coming into your projects or tests, avoid anything that can delay you if its placed in your environment. Sharing resources is often a way of life in some companies, but don't let some really new piece of code and its sudden new required installs of software X, Y and Z be placed in your environment a week or two before you get that next big drop. You may not get your environment back in time, or worse, find out that X, Y or Z is not compatable with your project, making you rebuild your environment. A good thing to do with any machine in your environment, if you can, is make a nice basic build of your environment then snapshot it, that way in case something happens, or you need to get back to a starting point, you put the snapshot back and you are set to go.

Fire extinguished.

In attacking with fire, one should be prepared to meet five possible developments:
To be circular about this, let's see what Sun Tzu says about attacking with fire.

When fire breaks out inside to enemy's camp, respond at once with an attack from without.
Use the distraction, and the sudden natural ally to make your assault.

If there is an outbreak of fire, but the enemy's soldiers remain quiet, bide your time and do not attack.

They may be lying in wait, or not even there.

When the force of the flames has reached its height, follow it up with an attack, if that is practicable; if not, stay where you are.

Use the natural ally, or better yet, let them fight it out and when they are exhausted and weakened attack, don't use your resources unnecessarily.

If it is possible to make an assault with fire from without, do not wait for it to break out within, but deliver your attack at a favorable moment.

Choose your time wisely, whenever your enemy is most distracted - pounce.

When you start a fire, be to windward of it. Do not attack from the leeward.

Last thing you want is the fire coming at you, let the enemy run away from the fire into your forces, and don't get the ash and flames in your face.

Hence those who use fire as an aid to the attack show intelligence; those who use water as an aid to the attack gain an accession of strength.
By means of water, an enemy may be intercepted, but not robbed of all his belongings.

By fire you force the enemy to move, and lose what he has, but with water you slow down your enemy or force him into an environment where he cannot attack, but he may not lose his resources.

But a kingdom that has once been destroyed can never come again into being;

Once you have destroyed a project or group, you are never going to get it back, don't lose it and don't squander it.

A short one, but hey its 12 down and 1 to go!

Testing with Sun Tzu - Chapter 11

Just as the terrain can be varied so Sun Tzu then gives more description of them in Chapter XI The Nine Situations. Just as an army can be stuck in certain terrain, or a situation when they are in close quarters so it can be when a project reaches a certain state, and you either need to defend your work or are being attacked for it. Just as you do not want to be in a bad situation during a project, you don't want to be in a worse place afterwards, but just as importantly you do need to learn the lessons of past projects. Repeating the same mistakes time after time does not scale well over time, and while it may work to keep doing the same kinds of projects when companies are small, this does not work when companies are larger and keep trying to consider the strategy of a project is always the same no matter the complexity.

The art of war recognizes nine varieties of ground: (1) Dispersive ground; (2) facile ground; (3) contentious ground; (4) open ground; (5) ground of intersecting highways; (6) serious ground; (7) difficult ground; (8) hemmed-in ground; (9) desperate ground.
Not all directly correlate, but there are lessons to be learned in all things.

When a chieftain is fighting in his own territory, it is dispersive ground.

When an army is fighting in its own territory soldiers, prior to being professional armies, were always at risk of running back home. With professional armies this is not so much of an issue, but just as soldiers ache to see their families for being away from them a long time, keeping unrealistic hours and schedules for long periods of time can have the same effect. I'm not a believer in the maxim that all projects require long hours to complete and that more skilled people take longer hours because they are much better and dedicated. Keeping people away from their homes for long periods can inevitably lead to domestic problems, and while its not always possible to keep home and work life separated, there are times when its always good to go home. When I first started working as a Tester it did take me sometimes 50 or 60 hours a week to understand and compelte a project, now I can do that same work in 40 or less, but I also handle more detailed projects now. So as I learn new things I expect them to take longer, but as I become more experienced I can do the work in less time. This way as I do work that is familiar it is done in less time and I have more time to work on new things, or to go home and see my family.

When he has penetrated into hostile territory, but to no great distance, it is facile ground.

Consider that a project is a piece of territory, there is a point where work is done and completed in such a case and you are committed to the work due to the resources expended. There is a time for change in large projects, but that is before you have penetrated into the territory that gets you out of your "homeland" and into the area where you can see the work. While processes like Agile keep a structure where things can change on a continual basis, not every project works that way, and you have to be careful on what is changed after a certain point. As to the hostile territory there was a time when armies would invade a foreign land and burn any bridges or boats used to invade, this was to keep the army looking ahead and realizing that they were committed and not going to go back.

Ground the possession of which imports great advantage to either side, is contentious ground.

Everyone wants the advantage, whether in life, on others or in a game (when possible). When armies were outnumbered they wanted the terrain that helped them hang on to what they had, whether it was a narrow pass (as mentioned in a previous chapter) or the narrow piece of land that allows movement. If an army outnumbers you, but they can only come to you one at a time, there is no advantage in their numbers, unless they want to wear you down. Mostly this comes down to when people want to play politics, understand the advantages they have and play them accordingly, while its not normal for many mid-sized companies to have office politics in play, many do and it happens even in small companies - play those games at your own risk and when you have the advantage.

Ground on which each side has liberty of movement is open ground.

When communication is open, people are committed and on the right path and things are running smoothly you have open ground as work is moving and going without impedence. Its a balance and a good middle ground, while a project may not always lie here, its going to occupy this space at some point. Enjoy it and when you can, get it to this place.

Ground which forms the key to three contiguous states, so that he who occupies it first has most of the Empire at his command, is a ground of intersecting highways.
In Sun Tzu's time this would be the area where many kingdoms come together, you can play one off against the other getting one weaker so you can invade, or lessen the strength of one if they are greater than you by having an ally. This the location where you command information and the resources of a project, because you have leverage on all the resources you need, its a good space to be in as you can direct things your way when you want. If its in the hands of someone who wants to impede you (see Office Politics previously mentioned) then you are in trouble, as whoever wants to impede you has the ability to get their point of view across to anyone who may want to, or can, help you. On your side this is a great place, against you failure may be imminent.

When an army has penetrated into the heart of a hostile country, leaving a number of fortified cities in its rear, it is serious ground.

The most recent example of this would be the invasion of Iraq by America (I won't go into my own feelings on this in detail, but let me say it was ill conceived and baseless), where many major cities and fortifications were bypassed in order to achieve the capital. This puts a force in a position where it may be strong in the center, but around it are areas that are going to be hostile to it. If you ever get a project into this state, there are very serious issues going on, but let's just say you had better be a good strategist to get yourself out of this situation.

Mountain forests, rugged steeps, marshes and fens--all country that is hard to
traverse: this is difficult ground.
As mentioned before, anything that is a delay will cause problems, avoid these situations. If you are unsure as to how difficult such terrain is to move across, try crossing a river by yourself, or a lake or marsh and see how fast you can move.

Ground which is reached through narrow gorges, and from which we can only retire by tortuous paths, so that a small number of the enemy would suffice to crush a large body of our men: this is hemmed in ground.
Again its all about movement, don't get yourself penned in so that you cannot make your deadlines and are short of resources be sure that you can keep up your speed of completion.

Ground on which we can only be saved from destruction by fighting without delay, is desperate ground.

Another bad spot, militarily this is a place where you can only kill or be killed, if you are in such a place there should have been numerous warning signs long before. This is a spot that it is exceedingly difficult to extricate yourself from.

Rapidity is the essence of war:

For an army to get to where the enemy is not, before him, is a strong goal. While finishing projects rapidly may be good, to do so when they are not sustainable is counter-productive. Make it a goal to finish projects on time, with support and completely, this leaves things complete and sustainable. While this quote seems more apt to Agile processes it can be used in others, so long as things are completed in a sustainable fashion.


11 down and 2 to go.

Testing with Sun Tzu - Chapter 10

Well after talking about armies on the march, and positioning, something I touched upon in the last Chapter was about how to place armies, in Chapter X. Terrain there is more that Sun Tzu says about it. When I mentioned positioning I also referred to how ancient armies would move about on land in order to have the best placement possible, armies would occasionally move around for hours or days until they reached the best place possible to wait. The enemy may come and see the placements and think "heck if I am going up against that!" and just go home, why go against someone who is strongly situatuated when it can only lead to ruin or a waste of resources? That has led to such terms as the "Forlorn Hope" where armies would crash against a strongly situated enemy, in the hope that a crack in the defense might be made, battlefield commissions where made upon these. There is a set of books by Bernard Cornwell set in the Napoleonic Wars where the main character Richard Sharpe becomes an officer through his participation in a Forlon Hope, if you like historical fiction I highly recommend the series.

Ground which can be freely traversed by both sides is called ACCESSIBLE.

Basically what is being referred to here is communication, this was an important trait of pre-modern armies, in addition consider communication to be a supply train; as I said previously if you have no supplies you can often lost the battle before its begun. But consider a project where people communicate, everyone knows what is going on and what people are looking for. A very nice project, no? I would think so. When groups work well there is no blockage of communication and everything is known, processes like Agile work by opening the communication between Development, QA and the Customer (I add QA here, but mostly because I can never really find it mentioned individually in many Agile documents though I think that will change). If people and information is accessible, then things proceed smoothly.

Ground which can be abandoned but is hard to re-occupy is called ENTANGLING.
In groups where communication often breaks down in certain situations and is difficult to return to being Accessible will be arduous to fix. As Sun Tzu mentions upon ground like this;

if the enemy is unprepared, you may sally forth and defeat him. But if the enemy is prepared for your coming, and you fail to defeat him, then, return being impossible, disaster will ensue.
So if you have communication break-downs and they keep reoccurring then this will always happen unless the problem of entanglement can be fixed. You can keep going back and fixing it, but if it will not stay Accessible there are other issues going on that need to be fixed and they will continually thwart you until such a time as a disaster or unfixable issue arises. Avoid the Entanglement, although its not the worst of the lot.

When the position is such that neither side will gain by making the first move, it is called TEMPORIZING ground.

When there is an issue that blocks communication, but the issue itself cannot be moved nor can it be fixed, you have a stalemate. Just as two armies will be at a deadlock in such a situation and a deadlock will occur, there will be no moving the issue out of the way of your communication lines. Its one to avoid, and hard to get around, though its possible to, everything has a solution if you look hard enough and such blocking issues can be fixed or at least brought up as a, you guessed it, Blocking Issue. In the projects I work on these receive high visibility and they become warning signs that things are not moving on the way they should, and deadlines are in peril. So we move to fix them when we can.

With regard to NARROW PASSES, if you can occupy them first, let them be strongly garrisoned and await the advent of the enemy.

If you've ever walked through a narrow canyon, or pass in the mountains, just think what it must look like to an advancing army, a confined space to be in and somewhere up above could be snipers, or people to push rocks down on you. If the army is on the march and someone attacks while its travelling through, there could be a lot of damage, they make it easy to defend precisely because they are difficult to traverse. In the Mexican War in the United States there were times when the Army Of The West came across some narrow passes they needed to go through, but with some fortification and resolve the opposing forces could hold the Army at bay with vastly outnumbered forces. So avoid the narrow channels of communication, if there is a bottleneck to get information on a project there can be trouble, of if one person somehow decides to play politics, or gets in a bad mood, the project can suffer because now there is only a limited number of people to go to and that person can block communication. Make sure there are multiple lines open, have alternative routes or sources, if possible never depend on just one because you can be delayed.

With regard to PRECIPITOUS HEIGHTS, if you are beforehand with your adversary, you should occupy the raised and sunny spots, and there wait for him to come up.

As mentioned previously with trying to run up heights, attacking up a hill is severly difficult, but defending from up a hill is easier, especially if you have time to be situated. Being in the raised and sunny spots can put you in view of the enemy, but it also makes a tempting target for the enemy to come for and draws them in. Placing yourself, or your project, in a position where it is well situated and able to see problems coming, you've got a good spot indeed, but if you need to get a project there later on, there is a fight on your hands. Just don't find yourself fighting uphill, otherwise it will be a long and exhausting battle.

Another part of this chapter is what Sun Tzu calls the Six Calamities, these are not forces of nature or events that occur, but from leadership and they also are very important. Unless you can lead your group or project, you may be doomed to one of these.

Other conditions being equal, if one force is hurled against another ten times its size, the result will be the FLIGHT of the former.
Trying to take on too much with a project is daunting, but expecting the people to just handle it will cause them to break, whether its under the strain or for new employment, you never know. Look at the resources you have and don't be unrealistic with your dates or deadlines.

When the common soldiers are too strong and their officers too weak, the result is INSUBORDINATION.

If a project is being run from the people within it, and not those in charge, its the same effect as too many bosses, but what you also have is no one who is then willing to listen to someone in charge later on. Weak management is bad in the face of strong opposition and usually spells doom if no one is willing to step up and take responsibility.

When the officers are too strong and the common soldiers too weak, the result is COLLAPSE.

In pre-modern armies this usually resulted in mutiny as the soldiers felt they had nothing to lose, but just as taking on projects that are too large with insufficient resources is not a good position, taking a project beyond the capabilities of the group is equally bad. Suit the group to the project, not the other way around. Make sure what is necessary to be done can be done by the people involved, or they at least have the ability and time to get up to speed if its something new and within their capabilities.

When the higher officers are angry and insubordinate, and on meeting the enemy give battle on their own account from a feeling of resentment, before the commander-in-chief can tell whether or no he is in a position to fight, the result is RUIN.

Again it comes down to leadership, if the people managing individual parts of a project don't feel committed or there is no incentive there will be trouble down the line. Everyone needs to feel as if the outcome has something for them, its all about motivation.

when there are no fixes duties assigned to officers and men, and the ranks are formed in a slovenly haphazard manner, the result is utter DISORGANIZATION.
Make sure assignments are known, and the ones doing it are reporting back, checking progress is paramount here, not knowing what people are doing and let them do what they want when they want only leads to disaster. Especially if there is no communication, which usually happens in cases like this, people should know and understand their jobs and what is expected of them by the end.

When a general, unable to estimate the enemy's strength, allows an inferior force to engage a larger one, or hurls a weak detachment against a powerful one, and neglects to place picked soldiers in the front rank, the result must be ROUT.

Again, check the project against resources, don't waste good people doing work they are not suited for or will make them resent the work. Again all about motivation, that will usually keep people happy and will keep them interested in and doing their best at their jobs.

Regard your soldiers as your children, and they will follow you into the deepest valleys; look upon them as your own beloved sons, and they will stand by you even unto death.

This is about management styles, its about how you treat your people, and since there are numerous books on this I won't go into it, but I agree with the concept that if you treat people well and give them responsibility and maturity they will stay with you. To me, I go to a job for the work (that is interesting) but I stay for the people (the management).

Well 10 down and 3 to go...almost there!

Testing with Sun Tzu - Chapter 9

After a long hiatus I am back, and intend to finish this before the end of the year. Good thing I have vacation!

Chapter 9 is about The Army On The March. As many know an army marches continually, moreso in ancient warfare which was about positioning your men in the best place to face an enemy, and usually draw them to you. Once firearms became standard, it was all about where you could place your armaments to make the best effect, firing a cannon downhill was preferrable to firing uphill. The British were known to place men in rectangular formations and use volley fire to take out an enemy, the squares were effective as long as they kept in form, although it also made them easy targets for cannon fire. So you have strength and weakness in one form, but as in earlier chapters its learning how to manage the risks so that your strengths are outweighing your weaknesses.

We come now to the question of encamping the army, and observing signs of the enemy. Pass quickly over mountains, and keep in the neighborhood of valleys.

The idea is, not to linger among barren uplands, but to keep close to supplies of water and grass. Just as importantly an army marches on its stomach. Much as Burgoyne learned when trying to take Albany in the American War of Independence, once your supply lines are stretched, and your army is dwindled by leaving men to keep your supplies secure, you eventually can end up in a situation where you are outnumbered and without supplies. A bad situation for any General or leader to be in. So to put this in terms or a project, what you need is to be in a place where you have support and an ability to move about, do not place yourself in a location where you are alone, without support, and more importantly without supplies if you need them. If you are moving along on a project and do not notice that soon you will need a certain environment set up, or some equipment, do not wait until its too late, keep an eye on the terrain of your project and know when you may need that time in the Test Lab. Or if you suddenly need the Automation Engineer to hook you up with some new tests, do it early, not when they are swamped with other work and unavailable. Schedule wisely, to paraphrase another quote.

Do not climb heights in order to fight. So much for mountain warfare.

Do not move up-stream to meet the enemy.

Movement, as I mentioned, was more important in the warfare of previous centuries, one thing that also determined the outcome of various battles was the condition of the army. Forcing long marches to a battle could gain you an advantage, but if you needed to press it later on, say the enemy retreats, then your troops need to be able to follow. Tired people cannot work continually and as much as some may want to whip them on, there is only so much a person can do. Many battles were considered wins because one side or the other owned the field at the end of the day, the usual decider of victory, but there are occasions when the enemy could have been all but annihilated if the troops were in shape enough to pursue in retreat. Just as you cannot move troops infinitely, giving unreasonable schedule demands onto people for a long period of time will eventually cause work to suffer as people tire and cannot maintain focus. More severely they may leave at inopportune times, putting the whole project in trouble.

Looking at these locations in individual terms.

These are the four useful branches of military knowledge

Those, namely, concerned with

(1) mountains

Taking a group to the high ground only increases distance, this can cause animostiy among groups as well, if there is an attitude of superiority that is causing trouble for other groups or more importantly putting other groups off there won't be much cooperation. Just as bringing an army up a mountain can be tiring, putting yourself on the mountain can only sap the resources of others who may be forced to get up to the heights, which can be bad for resources. Mountains can be anything from unrealistic expectations, entry criteria that is not possible to achieve or any large obstacle to advancement. Just as the view may be nice from the mountain, it can also be a lonely place.

(2) rivers,

Rivers are wet. They can also run fast moving things along with it in a way the river wants, look at white water rafting for example, you can ride the current in your big yellow boat, but you can only go where the river is going to let you go. Rivers can also run deep, swamping you and drowning you. Avoid letting the river take your project along at speeds you cannot control and push you into depths where you feel you are drowning, keep control of what is going on, just as the white water raft needs all the oars going to keep its direction, know what direction is it going in. An oar that is not pushing you in the right direction will slow you down and can cause you to hit that looming rock around the river's bend. Keep the project, and the people on it, focused and moving in one direction and you can get through the rapids and to the calmer waters ahead.

(3) marshes,

Marshes slow you down. Anything that is an impediment, or can cause work to slow, is a marsh. They can be sticky, stinky and slow going. While you can get through a marsh, its a delaying route, avoid them. They are not always apparent, so you need to keep an eye out for them, but anything that can be a delay such as sharing of resources, new items added to a project or some new directive can be marshes.

and (4) plains.

Flat lands are easy for access, and make for quick going. But they can also be barren and without resources, armies depended upon a supply train for various things but they also spent time foraging in the areas they were in. Scortched Earth policies go back centuries. Be wary of coming into the home stretch to find out that something important is missing in the areas you are about to inhabit. Keep a good eye on what is required to proceed, and be sure that it is all as you expect. Be sure the Test Lab is set up with the proper equipment, network and devices needed for testing later on, and that it is in good working order. Just because a machine is there does not mean its properly configured.

If in training soldiers commands are habitually enforced, the army will be well-disciplined; if not, its discipline will be bad.

If a general shows confidence in his men but always insists on his orders being obeyed, the gain will be mutual.

When starting a project don't equivocate on what is required, keep everyone focused and at the same time make sure that when changes come they are voiced one way. Don't let miscommunication enter into it, be sure everyone is aware of changes and what they are, and what they mean. Be consistent with who to go to with questions, or if its a group be sure they speak with one voice. But also be sure that those in charge are approachable, if someone has a question they should feel comfortable asking it, when questions go unasked they answer that someone comes up with that they feel is acceptable, may not be and this can be a delay (or a marsh if you will) to the project. When the project lead is both in command, and the people know what to expect of the lead, and what is expected of them, then leading is easy and the team can move on as one.

In addition, just as an Army moves on its stomach, add in some free lunches or a surprise meal during milestones when possible. If people feel appreciated, even if its just a free meal, they are more willing to go out of their way when needed.

9 down and 4 to go!

Testing with Sun Tzu - Chapter 8

Chapter 8 is about Variation in Tactics. Which is good in a business setting, because we constantly need to determine the best way to tackle a problem, and with things like Marketing Requirements and Business Strategy above us there is a need to be able to see the best way to resolve a problem or conflict. Again I am sort of following business processes and perhaps some Quality Procedures, but much of the lessons are applicable in even the small day to day problems we all encounter.

There are roads which must not be followed, armies which must be not attacked, towns which must not be besieged, positions which must not be contested, commands of the sovereign which must not be obeyed.

Well its not like QA is going to be putting a town, or a set of cubes, under siege - unless you have an office trebuchet like I do - but in some cases its not necessary. There are times when dealing with an issue that comes from above means doing nothing different at all, you could say "hey, that is stupid" and perhaps get into a fight with your boss and be fired. Or you could just say "Ok, we'll look into it" and do. Some requests come from upper management because something escalated to them, if there is a request to look into the problem of XYZ don't just come back and say "well that's not an issue", research it. Make sure its not a problem, there are times when you may be tired or too busy to initially deal with the problem, take some time to calm down and review the issue later on when you have a clear head. If you have higher priorities just check and make sure whatever has been escalated is indeed the higher priority, if XYZ is more important than finishing the latest patch make sure the consequences are understood, it never hurts to ask. Sometimes the person escalating the issue may not understand all the consequences, just present them calmly and rationally and whatever the outcome is, that is the outcome.

The general who thoroughly understands the advantages that accompany variation of tactics knows how to handle his troops.

From a management perspective, this is pretty plain to me at least, and is something that most good managers or leads will know - know your team and know how to apply their skills properly. If you know what the people who you are working with are capable of, then placing them on the appropriate tasks gets a project, and work, done much quicker than someone who may need to learn a new skill in a short amount of time to get a task done. The ability to learn new tasks is a great asset in a team member, but to be able to meet a project deadline that is coming in a few weeks making someone learn a new language or tool is not the best use of time. Do that in the downtimes between tasks, or when the task deadlines are further out so that you can give that person time to study and become more proficient.

In leading teams there are a few mistakes that can be made, if you see your lead making them having a talk about it may not be the best thing to do, unless you are able to do it very diplomatically; but it might on occasion be good to touch on something you see as not working right. Maybe there is something else going on that is not generally known.

There are five dangerous faults which may affect a general:

(1) Recklessness, which leads to destruction;

If work and priorities are being continually reassigned and changed there is a lot of context switching that the team may need to do, this puts everything in danger as focus is not on the task at hand when this goes on for a long period of time. Find a path and stick to it as much as possible, while fires may come up occasionally with released code, if they are continual there are other problems going on early on that will affect the post-release environment.

(2) cowardice, which leads to capture;

If, as a lead, you find yourself unable to make decisions and stick to them, especially in difficult times, then it may be time to move positions. At times you need to rise up to the challenge and make a decision, even if unpopular, and stick to it if you know its right. When things start to go bad hiding in the office or the lab, or in work, does not do well for you, your team or your project. Decisions are risk, and we are in the risk mitigation business, so make the best assessment you can on it.

(3) a hasty temper, which can be provoked by insults;

Never discuss things with your team if you are angry, tired or in a bad mood. As a lead you need to be seen as the calm in the storm, being reactionary and yelling at people especially in public is bad for them, and for you. In the same way, never go to your manager or lead if you are angry and begin venting, if you have the kind of manager who wants you to vent in front of them then fine, but just blowing off whatever is bothering you may not come out like you expect. If something is bothering you, get some time to talk to someone above you, take a walk or have a nice lunch beforehand, be sure you are calm so you can be rational about it and not emotional. Its better to discuss things evenly, and not in the heat of the moment when things can be said that are never meant.

(4) a delicacy of honor which is sensitive to shame;

I'll sort of leave this one as it is, America is not really an honor culture, if you are in one then you know what it means.

(5) over-solicitude for his men, which exposes him to worry and trouble.

What this one refers to, and it needs a little translation, is that you cannot give up an advantage solely for comfort. While there are times I would like to sit around and liesurely read a book if there is an immediate task that needs to be completed and I gain something from doing it, then I take care of it and hold off on my liesure time. But then I do have a tendency to be a bit of a workaholic to a certain point...I do like to see my family sometime.

When an army is overthrown and its leader slain, the cause will surely be found among these five dangerous faults. Let them be a subject of meditation.

In other words take time to do a post-mortem and see where you can improve.

8 down, and I know its taking longer, but work has been catching me up as of late.

Testing with Sun Tzu - Chapter 7

Section 7 is all about Maneuvering.  Well, not completely about moving it is also about gathering disparate elements and blending them together into one, much like testing where you need to pull together different techniques and skill sets.  This is the focus I am going to take, blending, much like coffee can be blended to improve the flavor (if you like coffee that is) or it can become bitter or overpowering if you have too much of one thing.  Tea can be the same way, blend your tea one way and you have a nice calming beverage, another way and you may as well be drinking roots boiled in water.

Sun Tzu said: in war, the general receives his commands from the sovereign.  Having collected an army and concentrated his forces, he must blend and harmonize the different elements thereof before pitching his camp.

Much like in a project, the Program Manager has sent commands to the Test Lead who now collects his team and concentrates them which requires blending and integrating them together into a cohesive unit.  In a test team everyone has a different skill set, way of testing or may be a subject matter expert of different components or a product, blending the team together to get the best benefit requires skills that take time to learn in order to become proficient.  Having a team that knows multiple test techniques, with some better in one type than another, gives a good balance but how do you make use of them to get the project done properly?  That takes planning, if you have people who are strong manual and exploratory testers letting them use an early release can help find some of the test cases that may not have been thought of or bugs due to design flaws.  Maybe there are automation folks on the team, having them sit with the Developers to help write, and perhaps review, test cases will give them an idea of what is coming and allow them to prepare a test framework for the test cycle.  Perhaps there are some good analysts in the group, let them into the early design and spec review meetings, have them go over every spec and document carefully and get the design and functional issues out of the way.  The best thing to be doing once you get your team is to know what their strengths are, plan to use them according to their strengths, putting the analyst who doesn’t know much Perl to work on the test framework written in Perl is a good way to make sure that you don’t meet a target.

Maneuvering with an army is advantageous; with an undisciplined multitude, most dangerous.

To meet your targets, and to be able to finish a project with a team, works when everyone is focused on the same goal.  An army is a force that has a focus, a plan and an enemy that they are to face.  A multitude is a group of people together for a cause, or even as a response to something, but they are not going to be focused.  Always try to have an army under you, a group that will listen to your commands and be focused on the goals that the project requires, when the people under you are listening and following you can do plenty.  The whole is more powerful than just the sum of its parts, and a team that is focused can do amazing things and meet deadlines that to others may seem impossible.  Do not be at the head of a multitude, a group that is there just for the sake of earning a paycheck is not going to help you get your project accomplished, nor are they going to assist each other.  Make sure that your team is working together, take them to lunch once or twice and talk to them outside of work, you can often tell outside of the company if there might be friction.  If you see it, then take care of it as soon as possible, letting that sort of thing fester will cause trouble and eventually will come back and bite you.

We may take it then that an army without its baggage-train is lost; without provisions it is lost; without bases of supply it is lost.

Now that you have a group of people together to get work done, you need a place to get that work done, tools and equipment, maybe even someone needs that ergonomic chair to be able to sit at the desk to get work done.  Find out what is needed and make sure its there, I have said it before, when you do not have an adequate environment to work within, then you only end up hurting yourself.  Having a group of people who are trained and ready to go, working on one or two machines is not going to get your project done, make sure they all have the equipment they need, if you can’t get it then you need to be creative.  If a machine needs to be signed out for each test, then make sure people know this and set up a common area for people to know and look to see if the Database Server is being used by the Functional Test group Tuesday; stepping on each others toes can not only invalidate tests but can cause bad blood between a team.  While a well organized team will communicate constantly, it’s a good idea to have back up methods of communication, not only for people to make sure things are working properly but if there was an issue traced back to a previous test you know what that test was and can go through reproducing the issue.  Also be sure you can get things repaired in a short amount of time, get images made of your lab machines when they are up and ready, that way if you encounter too many issues the machine can be re-imaged to a baseline and you can move forward and attempt to reproduce the issue.  Taking time to rebuild test machines during a project is something that cannot always be afforded.

We cannot enter into alliances until we are acquainted with the designs of our neighbors.

If during a project there is a need in another group that only you can fulfill, perhaps only the test lab has a specific configuration or a certain server, and you need to help out make sure both sides understand the needs and what the “lease” will be.  If a group wants to work with yours be sure you understand their needs, while I will never advocate being “political” in a company it’s good to not get into situations where you are part of someone being political.  While I am not saying you need to distrust peoples motives, being sure what is happening is good for you and your team, if a group comes into help you or thinks they are, but are only impeding the project, then you need to stand firm and clear up the situation.  Priorities will change in a company, even during “critical” projects, but make sure you understand what the priority change is, why it is happening and how you can get back to your project once it’s resolved as you now need to be creative for lost resources.  Again, my view in working in some places is to always be sure you are covering your teams ass, document everything, be transparent and be sure that the Program Manager understands what is happening with your team; that way there can be no discussion or finger pointing later on as long as you have documented and shown the work you have done.

Whether to concentrate or to divide your troops, must be decided by circumstances.  Let your rapidity be that of the wind, your compactness that of the forest.

Creativity with resources is another learned skill, at least to me; I have never really seen this as something that can be taught.  You have to learn to anticipate changes in your projects, know what resources you can move around to resolve the issues, without losing too much against deadlines and milestones.  This is usually something you can learn working for a manager who is really good at it, see how they do things, or if you work with someone who has encountered multiple difficult projects, talk it over with them.  It might even be worthwhile to post it on an online forum, just make sure you describe the situation adequately and what you think might be a good solution, it eliminates unnecessary questions.  There may come a point during a project where part of the team needs to work on a customer issue instead of on the upcoming milestone, don’t hesitate if meeting the customers need is vitally important to the company (and it usually will be) but let the Program Manager know this is happening and why.  Again it’s a learned skill, make sure you are prepared to make a few wrong decisions, own up and if you get called on it you could try to explain your reasoning and try to move on.  This is something that gets easier as time goes on and you encounter it more.

He will conquer who has learnt the artifice of deviation.

Anticipating, that is a very important ability to have.  Once you learn that a project is spelling trouble, that something will not be there when it is needed or that something is going on with the team then you will be well on your way to many successful projects.  Much of this does come from working on many and multiple projects so don’t be afraid if you get some things wrong, learning to see the mistakes we make so they are not repeated is one way of improving yourself and getting better.  Failure teaches more than success at times.

7 down, more than halfway there!  Thanks for reading.

Testing with Sun Tzu - Chapter 6

Section 6 is all about Weak and Strong Points.  This is about finding the places where you can attack an enemy, or to see where the mistakes are going to be, in project parlance this would be equivalent to checking for failures.  A good thing for a person in QA, or QC, for that matter.  It also ties in to the other sections which focused on offense and defensive postures (Section 4), Energy (or direct/indirect measures) (Section 5) and now when there is an understanding of how to position yourself and probe for weakness – you need to strike.  At least in a military sense.

Sun Tzu said:  Whoever is first in the field and awaits the coming of the enemy, will be fresh for the fight; whoever is second in the field and has to hasten to battle will arrive

Exhausted.

A pretty easy one for any person coming onto a project, if you come in from the beginning then you are able to handle the work and can do it at your own pace, come in with 4 weeks remaining to do a whole project-ful of work and you will rush and exhaust yourself.  In one respect this is a good way to think of when QA should be brought into a project, come in at the beginning and you have a grasp of the overview and the work necessary to be completed.  Documentation, or any necessary items that must be done, can be handled with enough time to meet deadlines, or aid in the planning of the project.  Come in late in the project and its all catch-up.  QA available and involved at the beginning can generate a Test Strategy, Plans, Cases, Scripts or whatever is needed; come in just before a release build is made and it’s a rush to get things in place.  Make sure you have the time and resources available and be able to learn about the project, getting thrown in will assure that you will be exhausted at the end, and regardless of all the Herculean tasks accomplished by others, and you may find that it was not your best work or at all something you want to be associated with after.

Therefore the clever combatant imposes his will on the enemy, but does not allow the enemy's will to be imposed on him.

Another reason why QA should be involved at the beginning, or in some cases the way to be sure that you have input into the project and not let the project have input into you.  Impress QA on the project; do not have the project impressed on QA, which will always be a losing battle.  Just as the armies of centuries ago positioned themselves to the place of greatest advantage, putting QA in a position where it is overwhelmed only leads to failure.  As has been said, be aware of the layout of the field, the position of your opponent and see the strong and weak points in order to predict the work that will come.

Appear at points which the enemy must hasten to defend; march swiftly to places where you are not expected.

Think ahead.  Not much more to add to that.  Might be a good thing to keep on my white board, but never let the current situation focus you only on the moment, be aware of what is around you and coming.  That is what separates the men from the boys, so to speak.  Its also what makes a great manager as opposed to a bad one, knowing what is coming into the department after the current project and keeping your team apprised of it while making sure they can do the current work makes their lives easier.  When your team is happy you are happy, and when you are happy then work is a much nicer place to be.

 Hence that general is skillful in attack whose opponent does not know what to defend; and he is skillful in defense whose opponent does not know what to attack.

Basically the Art of War in one sentence.  It’s also a way to think of planning, as I have mentioned previously be aware of all the needs, this reinforces the way to anticipate changes in the project.  Just as there is the need to “think out of the box” for determining a bug, so planning requires similar thinking.  I am a big fan of planning, but its also the process in which the planning is done, I document a lot of the process but this is one area I am always bad in documenting, because I know how I would plan a task, but its not always the same as someone else so why document my personal method?  Because someone may actually be able to improve their own by knowing what I do, but by the same token I am now skillful in planning when the project I am on doesn’t know the plan; or in some cases if the PM is lacking I look better in comparison.

Knowing the place and the time of the coming battle, we may concentrate from the greatest distances in order to fight.

Knowing when the final test effort will be, no matter how long, gives the time to plan.  Prepare ahead of time, everything you need, and keep an eye on those resources.  Plenty of times I have had to pitch in on an emergency situation because the main project is running and something came up but I cannot take a resource away; I’ve also tested multiple builds with different bugs to verify at the same time but I don’t suggest that.  Knowing when you are due for a release and how much work is left, keep milestones along the way; its a good way to have an idea of what is going on, will help in being able to say at any time – we can ship on that date.  I always try and keep a pulse on where things are and how they are going so if I am asked I can give a status, or at least know who needs to give me an update.  Knowledge is a powerful thing.

All men can see the tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.

At the end of a project everyone can see the result, but not the path you walked on to get there.  That path may be a tough thing, and while its great historical data, knowing how many bugs were closed when does not always give you a good idea of resource allocation in testing and its results; I distrust pure numbers in a field where Risk Mitigation often involves some sort of feel for where the project is.

Do not repeat the tactics which have gained you one victory,  but let your methods be regulated by the infinite variety of circumstances.

…also…

He who can modify his tactics in relation to his opponent and thereby succeed in winning, may be called a heaven- born captain.

The five elements (water, fire, wood, metal, earth) are not always equally predominant;

Be flexible, the project plan that worked for the last release may not work for the next, be aware you will need to change strategy at some point.  Just as I said history will not always give you good numbers, so you should be able to look back and still be able to see what worked and what did not.  Did doing piece A before piece B give the result we wanted?  Was there a need that came up for automation that took up time?  These sorts of things should come out in a retrospective or a post mortem, in order to improve the process, but more often than not most companies just jump into the next release.  Being a believer in the power of history its worth taking some time to discuss the project, not with heated emotions but a little dispassionately, to get what worked and what did not out in the open.  Advocate for what is needed after the discussion, but let everyone have a say as to what they thought went well or not, you might be surprised at what some people come up with.

Oh yeah..almost halfway done!  6 down.

Thanks for reading!

Testing with Sun Tzu - Chapter 5

Chapter 5 is about Energy.  Following on from the last blog’s commentary let me pick up a theme I sort of touched on, which was brought out in the comments, testing in a passive or active manner.  Think of that as energy.  You have potential (stored) and kinetic (moving) energy; you also have inactive (observation) and active (participatory) testing.  When performing test-y duties they can be done in a manner where you are actively using code or by having it run and checking results, or the environment, without any real interaction with the test scripts.  I am not advocating one over the other, at times I have run scenarios in either way depending on what I was testing.  While in this chapter there is a lot of discussion about men and moving them into battle, I am going for the spirit of the idea and while I may refer to men in the quotes, I will not talk about them as it won’t really relate; unless I wanted to talk all about managing.  Which I could, but maybe another time, I’m going to be jumping around in regards to expenditures of energy but relate it as I can to the quotes.

Sun Tzu said:  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.

I guess a more current version of this might be not biting off more than you can chew, take small bites, or even manage a large group as many small groups.  On a personal level, if I have a lot of work to do, then doing it in small pieces is much easier to control than trying to complete all of it at once.  When getting a project of work, doing 100% of it, and spreading your time across all of the components that make up that project doesn’t get it done any faster than focusing on one piece at a time.  Baby steps, like we used to say when I was a kid, don’t push yourself until you are ready, just take it slow and focus on what is in front of you.  Same way with a large project or task, take what is in front or needs to be done first and as its done move on, be like water moving around a bunch of stones, the water doesn’t crash into the rocks, well it might if it’s a deluge, but a stream finds a path through them of least resistance and deals with the path that requires the least expenditure of energy.

In some ways a project has an energy balance, or in game terms you have 100 Project Points, pushing yourself across the project you lose points as you move through it.  If you rush then you lose points pretty quickly, and unless you can get time to get those points back you will run to 0 and then it’s Game Over.  If you take time, find the right path, look for the Restore Points, allow yourself time to regenerate then you will get further than just running along the path and trying to reach the end.  Sort of like the tortoise and the hare, the hare may be quicker but may need to rest more, or become too confident at getting there first that he makes a diversion, while the tortoise moves along at a good pace and gets to the end.

The discussion on energy from Sun Tzu uses two terms Cheng and Ch’I, which don’t easily translate well to English, many Chinese terms have a lot of significance behind them which is not really a part of the definition but a part of the ideogram and what lies behind it.  A simple definition for Cheng is facing the enemy, where you march straight to the enemy and keep your face towards them; Ch’I on the other hand is movement, making diversions or changing direction in some form.  Cheng becomes passive as its just movement, a steady flow towards a point, Ch’I is activity where motion becomes part of the movement and the point can then be reached by many pathways.  Pretty much all I am going to do for this one, since it could go on and on, maybe a follow up later on.

In all fighting, the direct method may be used for joining battle, but indirect methods will be needed in order to secure victory.

To get work done in the project requires a path, that was determined within the project plan, to achieve those results occasionally means moving around the point or task and determine if maybe the direction to complete it has changed.  Do you use energy actively or let it collect until the end?  In other words, expend and recharge or use it in a burst?  In some respects using it all at once can be useful, if your culture moves you in a direction where all testing happens at once, or if testing is done over time then alternately saving and expending energy will be the wise choice.  How you move and use your energy in a project is up to you, and will change according to conditions of the project and the company culture.  The important thing is to avoid burnout.

Indirect tactics, efficiently applied, are inexhaustible as Heaven and Earth, unending as the flow of rivers and streams; like the sun and moon, they end but to begin anew; like the four seasons, they pass away to return once more.

There are multiple approaches to the problem, think back to a solution made a year ago, would you make the same results now?  Has experience taught you that maybe a better way now presents itself?  Just as lessons learned are gone in the past, they will come again unless the culture that generated them has changed, just as the problems that arise can be infinite so can the solutions to resolve them.  But just as there is more than one way to plan a project, so there is more than one way to test a project, one may be better than another in a given situation.  A project that has limited resources would be tested much different than one where you have twice the resources, including automation capability, that in itself changes how the project would be handled once it undergoes test.  Still the point I made earlier, there is a certain amount of energy in a project, what changes over time is how that energy can be used and channeled.  A team of testers who are able to do Functionality, Exploratory and Unit Testing are going to be handled and worked differently than a group of Functional, GUI and Automation testers.  Understanding what kind of energy you have, and how it can be used to be most effective will help not only in smoothing a project, but even on a personal level allows better choices in choosing what to do and handle within the time allotted.  Know how much energy you have for a project, then plan it out to get to the end, but remember roadblocks may happen, when they do, be like the water and flow around them eventually they will grind down.

The direct and the indirect lead on to each other in turn.  It is like moving in a circle - you never come to an end.  Who can exhaust the possibilities of their combination?

It’s circular.  Like a point in a circle there are many ways to look at it in two dimensions, 360 degrees of looking actually, but if that point is now in a sphere you have a larger number of ways of seeing that point, use it to your advantage and consider how many ways to test then choose the right one for you.

This one was tough…but its 5 down!

Testing with Sun Tzu - Chapter 4

Chapter 4, I decided upon Chapter rather than sections, is on Tactical Dispositions.  Since this basically means determining where the other army is, and their condition, there is no straightforward way to match this, so I am going to stretch this into my general project planning scheme.

A bit of history.  Before the advent of rapid-repeating firearms, and the British line (the most effective 18^th and 19^th Century force of firepower IMO), armies would march around each other to determine the most advantageous ground.  This did not often end up in actual battles, at times after a day of marching the armies might go home, once gunpowder became part of the war machine this changed.  In the American Revolutionary War when the colonial army fought the British, who would form line, the colonists lost because they could not match the firepower, and shooting speed, of the British army.  The colonists took to hit and run tactics as a way of harassing the British and use their strengths, while the British formed line the colonists would back off and lay ambush somewhere else.  No matter how strong you seem, someone can always find a weakness.

Sun Tzu said:  The good fighters of old first put themselves beyond the possibility of defeat, and then waited for an opportunity of defeating the enemy.

If I am on a project and want to make sure it’s a success, a lot of the failures lie within me (or at least within my own part) if I have an equipment need or a schedule dependency that is critical but I do not raise it as an issue, then its my fault.  My job is to make sure EVERYTHING I need is in place; that my part of the project is on track, following up with other people, making sure they know my schedule and needs helps me get my work done.  In this case the enemy is Project Failure, not something to have on the permanent record.  If I do not want to see my part lose I need to make sure that I have everything I need to succeed, and win, as this says “old fighters would be sure to have their weapons and armies in place then look upon the enemy to see where the weakness may lay”.

I have had situations in the past where I got so bogged down in my parts of the project I did not talk to people and find out where they were, getting blindsided by someone’s late work did not make me meet my deadline.  I was late, and I also had to cut corners, as well as work some long hours, to make up the time, but in the end the blame came down to me.  Learning to watch how other people are coming along, listening in the status meetings for the tell-tale signs someone is not on time, checking in personally and seeing how things are progressing, all things I have learned on the front lines and in my defeats.

Security against defeat implies defensive tactics; ability to defeat the enemy means taking the offensive.

In order to maintain progress you need to know where your supporting documentation is, as well as any dependencies, programmatic or otherwise.  There is the “bunker mentality” of sitting down in a cube and doing work, occasionally popping up “prairie dog”-like in order to check on free food in the kitchen or see who is around.  See my previous example of why this does not work.  As a Manager on a project, the expectation is that you know where everyone is, or at least how to find out quickly what the status is; which also implies keeping people alert and doing their part of the project.  As a person assigned to the project, the better ones will know where other people are, sometimes even those who are not directly impacting the current work.  One of the better people I had working for me in that past knew not only where the people directly affecting her were, but the people THEY depended on, that way she could tell ahead of time what the impact of delays would be.

(Names are changed to protect the innocent….and not so innocent)

Since everything was connected it became easier to know whether Tim would have things done on time if Bob was a little late, by knowing where Bob was Sue could ask Tim where he would be and what Bob’s late work meant to him, Sue could tell where her deadlines would fall.

Sometimes taking the offensive means not just looking at the people and work ahead of you, but the ones behind them, seeing further ahead means being ready for surprises.  Think of how many war movies would be shorter if the man in charge had looked beyond the mass of men before them, or even to the sides, to see the sneaky group coming up that would be the surprise in the battle.

To lift an autumn hair is no sign of great strength; to see the sun and moon is no sign of sharp sight; to hear the noise of thunder is no sign of a quick ear.

Ignoring the part about hair, this fits in with being able to see ahead of you.  Just because you see the sun, doesn’t mean you should ignore the comet hurtling towards you from the other side.  Just because you can hear the thunderclap does not mean that you will hear the people whispering in the next cube.  I just wanted to add this one for effect because I like the wording.  But its also a good metaphor for being able to see the hidden things, and to not just use a talent directly, but indirectly.  Perhaps an early way of saying “think out of the box”?

In respect of military method,  we have,  firstly, Measurement;   secondly,   Estimation   of   quantity;   thirdly, Calculation; fourthly, Balancing of chances; fifthly, Victory.

Measurement owes its existence to Earth; Estimation of quantity to Measurement; Calculation to Estimation of quantity; Balancing of chances to Calculation; and Victory to Balancing of chances.

Who knew you could use math to win wars?  Especially at a time when really it was about numbers of swords and arrows, and I do mean more than just < or > in determining who outnumbered whom; my Algebra teacher would be proud.  Now these five items are interesting, and not just because of the use of them, but by using these five items in the right way there are some good steps of project planning.

• Measurement, originally this seems to be surveying and measurement of the ground, in this case the terrain of the project.  What is the environment?  What will I need to be successful in this environment?  Thinking this through is not only a good mental exercise, but helps in planning the project to its completion
• Estimation of Quantity, Measurement helps very much in estimation. which enables us to form an estimate of the enemy's strength.  In other words by taking measurements of what the project entails, we can then determine what it is we need, how much, when we need it and where we can use it.  In this case Quantity is both physical and it’s the amount of time needed to complete tasks.
• Calculation, and to make calculations based on the data thus obtained.  From knowing what it is that is needed and what time it takes to complete tasks, these can be used together to determine, do we have enough stuff and time to complete by the date?  If not, recalculate, and if so then we can go on.  Sort of a stop in the decision tree; or it may be circular depending upon how you look at it.
• Balancing of Chances, we are thus led to a general weighing-up, or comparison of the enemy's chances with our own.  Now that all the data is calculated, does it look right?  Can this be done, is there a nagging doubt that says step X will probably not work right, no matter how much we want it to?  This is where luck comes in, and its also the point where Guesstimation is either going to succeed or not.
• Victory, if the latter turn the scale, then victory ensues.  So if we guess right, then we are successful, especially if we make the right choices on the way to the end of the project.  Or as I like to think of it, if we get lucky we win the lottery.

Just remember when you live in a deadline driven environment the following is what it looks like when you are behind and the end of the quarter is coming.

The onrush of a conquering force is like the bursting of pent-up waters into a chasm a thousand fathoms deep.

4 down only 9 to go!  If you are enjoying this, or not, let me know.