Planning for when cows attack

A picture of a cow
A picture of a cow


A few weeks back at one of the testing conferences I was lucky enough to meet a very interesting man, let’s call him Mr F. He was small, stout and incredibly beardy. He was a fascinating man who had some truly incredible stories to tell. A charming man with a razor sharp wit and incredibly strong opinions. I didn’t agree with 99.9% of what he was saying, but that’s beside the point.

Mr F was telling me a rather long winded but entertaining story around the old saying: “He who fails to plan, plans to fail”

Mr F had worked in the financial industry for most of his career but had recently moved to a big brand web company and was leading the testing of the latest version of this companies new website solution. Mr F explained to me how he planned for everything and anything. He told me, with great pride, how he refused to start the project without a risks and issues register. He even chuckled at the stupidity of the project team for thinking they could start without these crucial documents.

He also explained to me how he set up a team wide calendar entry for everyone to check the risks and issues register daily. He also, with some gusto, explained how he had a wealth of action plans he could refer to when the risks became issues or when the issue was becoming a real showstopping problem. (Note: When I refer to issue I mean an issue that is present and affecting the team/project, not an issue in the software or a defect).

He explained how he spent the first one month iteration finalising the documents ensuring each team member had input to the list of possible things that could go wrong. He had plans in place in case the first release of software was below the quality gate set in his test plan, in case any member of the team was off ill, for power failures, for the loss of test environments, for scope creep, for office security breaches, for testers not achieving 10 test cases per day yada yada yada. He listed very many more. It was a really fascinating (but long) story and I have to say, I was impressed with how much planning had gone in to it. I was also incredibly impressed with how passionate Mr F was for planning for the known, unknown, known unknowns and unknown unknowns.

The problem was that Mr F wasn’t a happy man. It turns out on day three of the second monthly iteration three testers threatened to hand in their notice because of Mr F’s insistence on planning for everything and anything (which, by the way, is an endless and impossible task).

Mr F was then removed as test manager and effectively given the boot. Something I’m not entirely sure he had planned for.

Mr F explained to me how he had never understood that there were different ways of working and that some teams simply didn’t need to plan for everything. He seemed genuinely surprised that different industries used different ways of working and that he faced so much resistance when he asked the team to plan. He said they kept saying things like “let’s just get something done” and “let’s build software, not write pointless documents”.

He’d heard all of the stories of teams just “doing” things with low cost, high efficiency tools and frameworks with only enough documentation and how some teams just seem to get stuff done but he’d  never experienced them first hand. He told me how he had shaken his head in anger at how misguided and misplaced these teams were with their “just do it” attitude without truly realising that there is a world outside of *his* testing domain.

Mr F was still a naysayer of many ‘new fangled’ techniques and approaches like Exploratory Testing, Test Driven Development, automated acceptance tests etc but he was beginning to realise that there are other ways of working and that planning too much in advance was pointless for some teams. It was a hard lesson for him to learn; that there are other contexts out there.

He was a fascinating man but it highlighted to me just how many people simply have no idea there are other ways of working. There were a few others at this same event where I met Mr F who simply couldn’t comprehend that teams are releasing software each month to a high quality without the need for massive plans up front. And this is not agile versus waterfall, some of the stories were of waterfall teams just getting stuff done – and some of these teams were more agile than most.

Planning, it seems, is something many testers love to do. And I believe all testers plan, after all “He who fails to plan, plans to fail”. But there is a point in which that extra planning buys nothing. It is waste. There are always things we will never plan for. Things we will never think of. There are always things we will plan for that will never happen. That is life. It is the way of the world.

Finding the right balance is tricky. Some plans are good. Too many can be bad. None may be very dangerous indeed. What works for one team might not work for another.

I do a fair amount of running and (maybe because I’m a tester) I’ve got a plan for various things happening whilst out running. Like if I fall and break something (the joys of having brittle bones), if I’m attacked by some Hoodies (the joys of living in the UK), or chased by a skulk of foxes (the joys of living in rural Hampshire) or hunted by a massive driver less truck (the joys of watching Duel too many times) but I have never ever planned for being mugged by a rabbit.

But sure enough, one day a rabbit the size of the England Rugby team tripped me up whilst I was running and I swear it tried to steal my MP3 player and new running shoes. I would never have planned for this. I still struggle to believe it even happened. And apparently it’s not that uncommon to be attacked by animals. It was in the news a while back about a man who was surrounded by cows and forced to jump in to the River Thames. And another story about a man being chased home from the pub by an angry badger. But do we plan for these things?

Anyway. I digress. But the point is there are too many variables involved in software development (and life) for us to effectively plan for everything we think we will ever encounter so we need to find that line that exists between careful and necessary planning, and time wasting processes that don’t lead to anything useful.

There are just some things that happen that you simply cannot plan for. So why try? Plan for the basics but don’t spend too long planning for the unknown, for the low probability and for everything you could ever think of. Most of it might not happen and I can guarantee there will be bigger problems you’ve never thought of.

So instead, be ready to accept new ideas and concepts, and be prepared to be flexible in how you approach a problem. But most important of all, be open minded to new ways of working and flexible in how you deal with problems.

And I leave you with a perfect quote:

“One should not respond to circumstance with artificial and “wooden” prearrangement”

And do you know who said that? The legendary Kung Fu master Bruce Lee.



16 thoughts on “Planning for when cows attack

  1. Hi Amit,Thanks for commenting. I probably used to be like Mr F for a long time until I realised I was not being effective and instead starting spending more time on actual value added tasks.ThanksRob..

  2. Very interesting. In some conditions is hard to plan and planning makes it worst. Mr F looks also a great person with some limited views I guess but maybe is the effect of environment? Many QA Managers are overwhelmed by position especially the inexperienced ones and they try to apply something familiar to them like extra-planning. This doesn’t mean that no planing ever should be done but its good when we have learned and enjoy to adapt and bypass

  3. Hi Sebi,Many thanks for the comment. I think you are right in that many managers are overwhelmed and resort to planning as a way to control things.ThanksRob..

  4. Well said Rob. There’s a danger that planning in too much detail too far in advance will create the illusion that we know more than we really do, that we can be more confident about what will happen than is really the case. A huge amount of time is then wasted because of the inevitable gulf between what was “planned”, ie documented in pointless detail, and the reality. The presumption is that the plan is right, and there’s a problem with the reality. That way lies madness! I wrote an article for Testing Experience about standards, IEEE829 and the dubious assumption that planning and hugely detailed documentation are synonymous.

  5. Hi James,Thanks for commenting. I read your post a while back and thoroughly enjoyed it. It does indeed smack of madness. I like how you mention that the “The presumption is that the plan is right, and there’s a problem with the reality” – superb. I’ve seen this far too many times.CheersRob..

  6. My failures in the past (and present) are similar to that of Mr. F.I failed because of lack of understanding of organization culture and how to advise appropriate actions that fit. I think that even if I were less technical but culture aware and people-oriented I could make my point across.Again, it has nothing to do with wrong or right. Mr. F course of actions could be embraced and even applauded in other organizations. IMHO…..

  7. Hi Sameh,Thanks for the comments. You are indeed right, Mr F’s actions could indeed be embraced and applauded in some organisations which is the very environment Mr F came from. Thanks for commenting.Rob..

  8. Also, I think this can be part of transition from traditional management to Agile. In an environment which values Gantt chart, schedule, measuring deviation and even task assignment people use these docs as indication of healthy project. They’re driven by compliance and regulatory rather than business value.Thank you for this thought provoking post about Mr. “F”:)

  9. Hi Rob,I recently started managing a small team of testers (which you would have sensed from my upcoming article in STC Magazine ;)). I enjoy leading and mentoring people, but I don’t seem to enjoy managing people. What I mean is I hate the planning and estimation part of testing and software development in general. The basic plan should suffice as we always go haywire more often than not. I don’t see this dirty numbers doing any good, but we would have wasted half the sprint in coming up with numbers.Its sad that management finds this as a strategy to be in control of people and processes as much as possible and hence metrics barge in. Thanks a lot to you for this post. All this while, I thought I sucked at management. This post made me realise that I suck at planning and estimation (which is OK to me).Regards,Parimala Shankaraiah

  10. Hi Parimala,You so elegantly hit the nail on the head. “All this while, I thought I sucked at management. This post made me realise that I suck at planning and estimation (which is OK to me).”I think too many testers are beating themselves up about this very same thing. Planning and estimation is not test management. 🙂 There’s more to it than that. Good test managemers often don’t over plan and certainly wont hold a team to an estimate. Thanks for commenting.Rob..

  11. We all suck at planning and estimating, to varying extents. I actually rather enjoy it, but what I can’t stand is the pretence that we know more than we do, and that our plans and estimates have validity and accuracy just because they’re detailed. There’s a great reluctance to be honest about this. We estimate and plan, the reality is chaotic, and we shrug our shoulders, move on and do it all again next time!I keep on banging on about this point. When we haven’t a clue, the right answer is “I haven’t a ******* clue!”. The trouble is that confident nonsense is rewarded, and honest uncertainty about the unknowable is punished. 🙁

  12. Should have added that where you can make reasonable guesses based on experience, or some reasonable assumptions, then do so. You do have to make some sort of guess at the future. But don’t dress your guesses up as anything more than what they are, and don’t let other people portray them as precise estimates.

  13. Hi James,Excellent comment. Thanks for that.Couldn’t agree more. The whole fact that we plan for things we know nothing about is both clueless and wasteful. We should be honest like you say and make it clear we simply don’t know. do some experimenting or research and come back with a clearer idea at a later point.It’s as though businesses sometimes can’t move forward on anything without a piece of paper with a plan on it. Accountability at all stages with proof to back it up. For some environments it’s essential, for many it’s just “how it’s done”. Thanks for the commentRob..

  14. Hi Rob and James,Thanks for your valuable comments. I am taking away one great lesson from the post as well as the comments here about planning and estimation.What I am currently struggling with is when people wear a sorry face just because I don’t give them numbers. How many test cases can Robert execute in 1 day? How long will the build set up take? Oh, and its a broken build by the way. The story continues. Unless the team as a whole matures, it becomes hard for one person to bring in a change. That is where I am looking to create awareness among people one step at a time. To some extent, I have convinced the scrum master that we cant say we’ll take exactly 6 weeks to test this build for various reasons. And please don’t count weekends!Thanks again,Regards,Parimala Shankaraiah

Comments are closed.