I am going through some notes I will need for a project meeting. I am struck by something in them that makes me think that the world is as cyclic as we really sometimes would wish it was not.
When a project is starting off we always have certain assumptions. Well, we may have a bunch of things that we write down and put in notes as being "truths". Or something.
We KNOW certain things. They may be about the project or they may be about the application or they may be about what the business intent is or the market forces or reasons behind the project.
We also have a way of dealing with things. A process that is used to get done what we need to get done, right? We can move forward with some level of confidence that we will be able to do what we need to do.
We have decisions to make. We have to get moving and get going so we can show progress and get things done.
The issue, of course, is that we have based our decisions on things we knew some time ago. They are not wrong, but are they current? If we based our initial estimates on the last project or the one before that, does it have any real relevance to this one?
Now, you're probably saying "Pete, we don't just take the last estimate and run with that. That would be foolish." I've said that too. Except, even if we introduce variance or some "outside analysis" then we can safely make some assumptions based on previous experience, right?
What if our recollection of that experience does not exactly line up with the documented experience? What if our estimate is based on the previous project's estimate and not on the actual time spent on that project? What if things have changed and no one thought fit to pass those "little details" along, because of course you know everything that is going on. Right?
We always are operating on current, up-to-date information, and the assumptions for the project always reflect reality. Every project is this way. If that describes your organization, I'd be very interested in observing how you work, because I have not seen that to be true on a consistent basis.
June 18, 1812
So, if you went to school in the United States and took American History like I did, you learned about the War of 1812. You learned about how HMS Leopard had fired on, and forced the surrender of, USS Chesapeake. You learned about how the British Navy was stopping American ships and impressing sailors from them to serve in the British Navy in their war against the French. You learned how the British supplied and generally encouraged the "Indians" to attack American settlements.
You then learned about the USS Constitution defeating HMS Guerriere and HMS Java. You also learned about the Burning of Washington DC, the defense of Fort McHenry and the writing of the Star Spangled Banner. You may have learned of the American victory at the Battle of Lake Erie and the American surrender of Detroit to the British.
You probably were not told the Chesapeake surrendered to the Leopard on June 22,1807. You also were probably not told that American ships going to French ports were being turned away as part of a declared blockade of France. You also probably were not told that Britain did not recognize the "right" of British subjects to become American citizens, and those fleeing criminal prosecution, for example, for desertion from the navy, could be seized anywhere they were found. You probably were also not told that Lord Liverpool, the Prime Minister, ordered the repeal of the Orders of Council, which covered pressing British-born sailors into British service from American ships.
Thus, the War of 1812 was actually fought after all the official reasons, save one, had been addressed.
That one reason, inciting Indian attacks against American settlements, was also true of Spain and France, until France sold the Louisiana Territory to the US in 1803. The simple fact is, the Americans themselves were breaking the treaties with the various Indians, or First Nations, who responded in kind.
Now, some Canadian versions will tell of how the US wanted to expand into Canada. The American version was that if the US were to invade Canada, they would have a strong bargaining point with Britain. The Northern part of the US was predominantly the stronghold of Federalist Party supporters. They were generally opposed to the war, and opposed to the idea of invading Canada in particular.
A funny thing happened though.
The Farther Removed From the Situation You Are, the Easier it Appears.
The farther south you went, the stronger the support for the war could be found. The Democratic-Republican Party was generally pro-war. Some politicians spoke of how American troops would be welcomed as liberators by the people of Canada and how they would be greeted with cheers and flowers.
Except that a large portion of "Upper Canada" was inhabited by "United Empire Loyalists": the people who moved to Canada from the United States after the Revolution. These were the "Tories" you learned about in school and were cast in the role of "the bad guys." They had no notion of welcoming Americans as liberators or anything else.
People who were farther removed from the reality of the situation did not comprehend how difficult that situation was. How many times have we seen software projects like that?
So invading Canada seemed like a better idea the farther away from Canada you were, And when American militia with a handful of regulars crossed the Niagara, they ran into a mix of British regulars and Canadian militia who gave them a solid thrashing at Queenston Heights. Several hundred captured, many dead, a complete route as the American invaders fled across the Niagara River and back to New York.
The hero of the day was General Brock, who was killed in the action. He had just come East to deal with this invasion threat by soundly defeating another invasion threat to the West - at Detroit. By capturing the town and forcing the surrender of the would-be invaders.
Know What the Situation Really Is Before You Make Commitments
How many software projects have boss-types said "Oh, this can be delivered by this date." Thus setting the date in stone. Then you find out what needs to be done.
No one ever runs into that, right?
Projects where the rules are mandated and the "customer needs" are all "captured" in a three-ring binder a three inches thick and these are "simplified" to a seven bullet-point list and if you have questions they need to go through the "single point of contact" who will relay those questions to the appropriate expert who will get in touch with the person who may have had some input into the bullet list however.... ummm, yeah.
Translated, you have no real way of confirming or getting clarifying answers around questions you may have and no real way of finding what needs to be done or what is involved or what is going on or... what you are in for until you are in it.
The myths told to American students mask the reality of what the country encountered when the decision was made to go to war with Great Britain. No one knew what they were going to encounter, but they had definite ideas, plans and goals. And the summer of 1812, near Detroit, Michigan, then near Queenston, across from Lewiston, New York those plans were quickly shredded.
They walked into a situation where they had no concept of what was involved. The handful who did and spoke out were accused of disloyalty, and not being committed to "the cause." Whatever that meant.
Software projects run by fiat can encounter the same problem.
Fortunately for the Americans, the British forces were extremely limited the first two years of the war. British land forces were committed to fighting Napoleon's forces in Europe... until April, 1814 when Napoleon abdicated. Then the full weight of the British Empire would come to bear.
Making Use of Found Opportunities
The American military learned from the initial, disastrous battles, and those that followed. While American Naval Forces could hold their own. Single ship actions and small squadrons actions helped buy time, for both sides. Privateers wrought havoc on both sides, but the American ones tended to disrupt the British ships to and from the Caribbean. The Battle of Lake Erie (September, 1813) isolated British forces North of Detroit by cutting off water routes to the British positions.
In the meantime, the American army trained and trained and trained. Regulars and militia trained. A small cadre of young officers drove the training, based partly on their experience facing the well trained British forces. At places like Chippawa and Lundy's Lane the training proved its worth - The American forces did not run away. Really - I'm not making that up. Until those battles, they tended to do that when facing British Regulars, or even militia.
As testers, when we're in the middle of something we did not expect, we have a variety of options. We can "inform management" and "let stakeholders know" that we are encountering difficulties and wait for instruction. Or, we can look for ways to over come those difficulties and maybe learn something new.
In late 1813, a bright young officer of artillery named Winfield Scott saw a collection of challenges and boiled them down to a few common ideas. He saw symptoms of a single large problem. He then proposed a solution. His opportunity was unplanned. He knew the army could not take effective action, and his opponents did not take action. He used the time then to teach his soldiers to be soldiers. In the middle of a war, one that his government went looking for, he turned the organization on its ear.
As testers, our war is often not of our choosing. The engagements we are in are not ones we typically go looking for. As leaders, we need to look for opportunities to improve.
I know that being deep into a project that is floundering is not the best time to learn a tool or new technique. It might be a good time to do some research on your own - to dig into questions around what is blocking you.
We need to determine what the problem is we are facing. Now, it may not lead you to a resolution. It may do something else - like allow you to step away from your immediate block so when you return to the problem, you are looking at it with fresh eyes.
What is the PROBLEM?
It may help you think about your problem differently. You may be attempting to address symptoms, instead of the actual problem. AS you find a solution to one "problem,"three others appear. Are you fighting isolated, individual problems or are these actually aspects of one greater problem.
Problem: Troops are not firing as rapidly as their British counter parts.
Problem: Troops do not execute field maneuvers properly, let alone quickly.
Problem: Troop morale is low.
Problem: When facing organized opposition, even in inferior strength, troops withdraw in confusion.
Are these four problems?
Winfield Scott said they were not. He said the problems described above was actually one problem:
American Regular and Militia troops do not have the proper training to be able to fight against a modern, European army.
Scott was promptly promoted to Brigadier General and told to "fix" the problem. He did not intend to teach an army how to teach itself, but that is precisely what he did.
His solution: "Camps of Instruction" where for 10 hours a day, every day, he trained troops. They in turn trained others.
He then saw that officers needed training as well. Those that were incapable of leading troops, he replaced. Sometimes with non-commissioned officers he promoted on the spot.
He then saw that to maintain this level of activity, he needed to make sure his men had good, healthy food - and made sure they got that.
As morale improved, he noted something else - each sub-unit (sometimes companies in a single regiment) had a different "uniform" than the others troops. He ordered enough uniforms for his entire command to be turned out in what looked, well, uniform.
Learning to differentiate symptoms from problems is really, really hard. Ask anyone who has tried to do that. When you're deep into it, taking a deep breath and stopping to think is hard to do - it is also the one thing that sets great testers apart from the "anyone can test" type of testers.
And so...
The nature of projects have remained the same for... ever. We find ourselves in situations we did not intend to be in.
Think clearly, then act precisely.
How do you learn to think? Some suggestions
Attend CAST - this July in San Jose, California ;
Attend Let'sTest - a conference new this year that was a smashing success from all I have seen (next yer's should be good too!) ;
Attend PSL - Problem Solving Leadership - come on - just search for it, you'll find it ;
Find a Meetup of testers near you - and go REGULARLY;
No Meetup near you? Start one.
In general, hang with smart people and talk with them Don't be the smartest person in the room - ask about things you don't know or are looking for insight on.
Then act on what you have learned. You may not achieve the "great things" the spin-meisters would have you achieve - or would tell people you have achieved. Sometimes status quo ante bellum is the best you can hope for.
For that, one must know the costs of what you are doing and what the risks are around stopping or continuing.
That is a topic for another day.
re: "We always are operating on current, up-to-date information, and the assumptions for the project always reflect reality. Every project is this way. If that describes your organization, I'd be very interested in observing how you work, because I have not seen that to be true on a consistent basis."
ReplyDeletesomewhat yes: http://www.systematic.com/about+systematic+website/profile/the+way+we+work/innovative+methods+generate+results