Tactics, Strategy and the Glorious First of June

I am writing this the evening of 1 June – The First of June – On an aircraft flying over the Atlantic.  When you spend time reading and thinking and considering different topics, you find them overlapping – sometimes in surprising ways.

The movie being played on the screens (ahem, really? One screen for everyone to watch the same film?) is Mr Peabody and Sherman.  So, we’re conflating history and science and popular understanding.  Whilst setting aside the whole “George Washington cut down a cherry tree then said he could not tell a lie and admitted it” thing – yet supported the Marie Antoinette thing where she said “let them eat cake” – another myth, except it was to degrade the person instead of showing them as an icon. 

I find the same thing happens with people talking about Test Strategy.  I find many times they refer to items which I consider Tactical, not Strategic.  There is a significant difference.  One describes the purpose of why you are doing something - One describes how you intend to do it.  People tend to  focus on the thing in front of them and not on the most important goal they have.

Simple, right?

Except things are never so simple, I find. 

The Glorious First of June

In May, 1794, Europe was in the throes of reacting to the French Revolution, the Revolutionary Wars and the general mess that was consuming the continent.  The British Admiral, Lord (Richard) Howe, the 1st Earl Howe, was chasing the French Admiral Villaret-Joyeuse, across the sea in an attempt to intercept the French, who were bringing supplies of grain and other necessities to support the French military who desperately needed the supplies.  

On 1 June, 1794, some 400 miles off Ushant, Howe caught up with the French Republican fleet.  

The British fleet of 25 ships of the line, engaged the French fleet of 26 ships of the line - the capitol ships, the battleships of the day - the pride of their navies.  When the smoke cleared, quite literally, some 1,200 British seamen were dead - but some 4,000 French seamen were dead, 7 of the French ships were captured or destroyed, and thousands more were prisoners. 

This was hailed as a triumph for Lord Howe - and it was.  A major achievement.  The fist, and largest, fleet action fought by the British and French navies during the Revolutionary and Napoleonic wars - a clear British victory.

One for the record books. The smaller British fleet engages and does serious damage to the larger French fleet. Except for one thing...

While the fleets were blasting each other with shot, shell snd grape, the transport ships with their critical cargo, were not taken - they delivered their supplies.  Howe had inflicted tactical damage on the French - and failed in the strategic mission.

In our testing - how often do we do the same thing?  We find loads of bugs - except we can't tell our stakeholders anything about the software that is of real value?  Some people make a big deal about the number of bugs found and ignore the critical question of what are we after?  

Is our bug-finding of tactical importance or strategic importance to the organization?

Lord Howe's Action, or, the Glorious First of June

 

 

 

On Shrinking Violets, Anti-Heroes or Failure to Step Forward

Its been an interesting week.  Really busy at the client office and with Spring here, there is plenty of work to do in the garden at home.  This last Thursday we had a great session at the local tester meetup with Matt Heusser giving his "12 Years of Agile" presentation.  Really well received and overall a good night.

Friday night, the lady-wife and I had dinner at our favorite local Italian restaurant.  As we were eating and relaxing with a nice glass of wine, a couple we knew but had not spent much time socializing with came in.  We invited them over and had a nice chat.

At one point, the couple, another software guy, got to talking a little about work.  Not in depth, but a general list of things.  It seems he was worried and was looking to have a bit of a vent.  His concern was something I could relate to.

His projects were doing well.  His boss was giving him decent reviews.  Still, he was not terribly excited about it and generally troubled.  So as the ladies chatted about gardens and the local pottery show the next day, he and I chatted about work.

It seems that a guy at the office resigned and went on to a new gig.  Most of his projects were wrapped up pretty well and moved into production around the time he left.  One was delayed for a bunch of reasons, most were apparently not technical.  So Giovanni, they guy I was talking with, leaked something he probably did not really intend to leak.

He had worked on the project that had not been deployed.  He had done some of the interface work to connect their main system to their customer facing mobile portal.  His work had gone well, and there were no bugs or even annoyances outstanding on his work - but it was a pretty minor piece of the entire project.

OK, I said.  This seems pretty normal from my experience.  This one guy left the company and they need someone to pick up the system and keep an eye on things while its being deployed.  I've seen that happen many times and have been the one to pick up systems fairly often.  How is this a bad thing?

The answer made me blink and take a sip of Chianti - partly to buy a little time and partly to find a better response than the one that popped into my head.  (My lady-wife noticed, I don't think his wife did.  It may be a matter of being together as long as we have been.)

He said - This guy left before the project went into production.  I worked on one small piece and now they want me to be responsible for the entire thing - not just the part I worked on but everything!  Including the stuff other people worked on! 

I asked if that was a bad thing.

"YES!  Its horrible! Anything that doesn't work will be my fault!"

That called for more Chianti - another glass of it at that point.

I looked at him and smiled gently.  I asked if he thought maybe. just maybe, people thought he could take on more responsibility?  Sometimes being asked to take on a project in trouble is one way of 
saying that.  Other times its shown by replacing someone on a project who leaves the company, or, in this case, taking on an application or system that someone else had responsibility for and they have moved on - to new responsibilities or left the company.

Is it possible this is a vote of confidence in you?  An expression that your Lead or Manager think you might be ready to take the next step?

He very quietly said.  "I think they will blame me for anything that goes wrong when it actually goes into production.  If they do that then I will be in big trouble."

I smiled and asked if he really thought anyone who worked on the project would blame him if something went wrong on a part of the system that the guy who left worked on.  I asked if he thought that they product owners and key experts who had been on the project would blame him for things not working - when all the bugs found in testing, including by the same people he was worried about - had been fixed and wrapped up before things were deployed?

He looked a little panicked.  "But if my name is on as the Lead Developer in the release documents when this goes into production, and something does go wrong, other people will think I'm not very good.  I don't want that to happen.  I want this other guy's name there and then have my name listed under him as taking over from him.  They are being really unreasonable about that and saying no."

I nodded with a somber face and agreed that there was definitely a problem.  They
finished their meal and left while we lingered over cannoli and one last glass of wine.  We chatted with the owner, a friend of ours, and enjoyed the light from the setting sun in the restaurant.

So, the lady-wife looked at me and asked what was bothering me.  I said, "I think young Giovanni is making a mistake.  I think he is so afraid of being blamed that he will paint himself into a corner and never advance the way he could.  I think after this he will find himself relegated to supporting roles and never having the opportunity to run a major project.  They are handing him an opportunity to shine and he is refusing it. If Thud, Corp goes through another re-org, like they do every couple of years, I think this may be remembered and he could be out.

They want people who act boldly, not who act like shrinking violets and always want to play it safe.  We went home, played with the cats and watched a little television before turning in.  We both had to be up early the next morning.