Why waterfall kicks ass

I read a blog post about why waterfall is NEVER the right approach and I feel compelled to respond to what’s touted as the waterfall mindset. Here’s a copy of the paragraph, but you can read the whole post on the above link to get a better sense of context.

I actually don’t believe adopting waterfall as an approach is ever a good choice.  Waterfall comes with the following mindset:

  • we don’t need feedback between the steps of requirements, analysis, design, code, test
  • we can hand work off
  • big batches are ok since they enable us to be more efficient
  • specialized skills working only on their specialty is good
  • we can understand the work to be done before we do it
  • written requirements can specify what we need

Putting aside for now, the use of absolutes, lets address this waterfall mindset:

1) we don’t need feedback between the steps of requirements, analysis, design, code, test

I’ve worked in both waterfall and agile over the years. In those ‘bad old days’ where no-one appreciated collaboration, we used to extensively review requirements. This meant that testers offered valuable input into requirements before any piece of code was developed. Since the invention of ‘agile’ almost everyone has discovered the 3 amigos, but honestly, this is not an agile concept, it existed way before agile was even thought of.

2) we can hand work off

Honestly, I don’t understand this sentence. I’m serious. I can think of many reasons why handing work to others is a good thing. For instance, if I’ve got too much work I’m in danger of becoming a bottleneck, and I hand some of my work over to someone else. If that’s a waterfall mindset, its one I like to have.

3) big batches are ok since they enable us to be more efficient

What do you mean by efficient here? Does it mean quicker, better quality, less waste? Efficient in what? Design, Writing code? Testing? Support? If I wish to carry 20 oranges from point A to point B, is it more efficient to carry them one at a time, or do I get a bag and carry them all together?Try delivering to a customer 1/4 of an IC circuit and request feedback? Sometimes delivering something in one batch IS the the more efficient way to proceed.

In waterfall, we did have teams, and work was allocated into smaller isolated tasks. It was rare one person developed the whole product. In fact, when I worked on telecommunication systems in the nineties, the concept of frameworks was being introduced, segregating data from its transportation method, allowing for people to work on separate parts of a system in parallel to each other.

4) specialized skills working only on their specialty is good

When I started working at Nortel Networks in 1994 it was all waterfall, except we didn’t call it waterfall then, we called it software development. Nortel Networks had a policy that encouraged developers and testers to spend time working in each others ‘specialisation’ area. For six months I became a developer working to deliver software. I was taught C++ and object oriented design principles, so I’m uncertain why you think this is a waterfall mindset?

5) we can understand the work to be done before we do it

Why is being able to understand work before you begin considered a ‘bad’ idea? I think this phrase is too ambiguous to be able to discuss with any merit.

6) written requirements can specify what we need

Is it the word requirement, or is it the fact that it’s written that makes this a ‘bad’ mindset? Yes we do have written requirements in waterfall. We also have written user stories in agile, so what is the point? Just because stories are written in confluence doesn’t make them any less written.

In the bad old waterfall days, I facilitated workshops with the business and IT teams to determine and understand risk. Lots of verbal collaboration, lots of whiteboard discussions.  I’ve worked in ‘agile’ teams were little communication takes place, no stand-ups nothing. In fact, one developer spent a week working on the wrong story without realising it.

I’ve worked on some fantastic waterfall projects that blew the socks of some really crappy agile teams I’ve worked with recently. In these waterfall projects, I’ve worked in harmony with great developers and testers, working closely together. We were afforded sufficient time to examine the system as a whole instead of its parts, something that these days appears to be a bit of a luxury. I’ve worked in environments that develop hardware, firmware and software where upfront design and ‘big batch’ systems thinking helped us understand that we were not merely developing code, but we were attempting to solve a problem.

Its easy to conflate poor software development practices with waterfall, just as its easy to conflate an agile approach with ‘good’ practice. To me the biggest change since those days are technological ones which allows us develop, integrate and compile it quickly and relatively cheaply. It’s the technology that has allowed us to develop in these small tasks that we are familiar with today. In the early nineties the concept of layering and isolating according to purpose was coming into play but we simply didn’t have the sophisticated systems that allowed us to develop in a way we wanted to.

A second important change was the conception of the agile manifesto. To me the agile manifesto is a stroke of genius. People who had the courage to espouse ideology that placed people over process, tools or artefacts. For many, this has changed how we think about developing software.

But lets not forget, that the agile manifesto was developed by people who worked in what you call a waterfall environment.  It seems to me these people had quite a different mindset than the one suggested above. It seems to me, those who developed the agile manifesto did so with ideas of collaboration and an emphasis on the ‘humanness’   of developing software. Do those ideas come about as a result of what was done badly in waterfall or because of what they saw was working well?

I suspect it was a little of both.

Don’t get me wrong. Lots of mistakes were made pre agile days. There was an idea of segregation between developer and tester in an attempt to avoid bias from developers. I’m glad we’ve gotten over that idea. But many of the mistakes we made in those days we’re still making now. Most software teams fail to understand testing and attempt to measure it using means that appear to have no direct correlation to quality. Many teams use measurement to lock down estimates as opposed to using them as a source of information for change. Go to an agile conference and count the number of talks on process and methodologies and frameworks. Look at today’s obsession with continuous delivery as a process. What happened to the people folks?

It’s easy to understand why. The agile manifesto is bloody hard to implement. Its much easier to point at a tool or a process and say “thats what we do” because its explicit, it’s easy to see. Programming & testing are human activities and are much harder to identify and talk about. It’s hard to describe and transfer these skills. The best way I know of is to actually perform the tasks.

We need a little more humility in acknowledging the great shoulders that agile stands on. Its simplistic to identify in hindsight a ‘waterfall’ mindset. Such a thing did not exist. Instead lets view them as the agile manifesto encourages us to do, to view them as people attempting to deliver quality software just like we are attempting to do today.

Crossing the bridge over no-man’s land

Indiana Jones in the Temple of Doom  has a “moment of indecision” when half way across a bridge he realises he’s been cornered by Mola Ram(the baddy) and his henchmen.

He looks back and there’s a hoard  of lusty savages baying for his blood, no luck there. He looks ahead only to find an equal challenge ahead. What is poor Indy to do?

Anyone who has introduced change into a corporate environment will empathize with his situation. You know the decision to break away from the past is the right one, you run eagerly and embrace change, only to find half way through the journey, your path to success becomes blocked.

I’ve been working with my test team for a while now moving from a process driven approach to a more of an Exploratory one.

Its not been without its challenges. Some concepts I’ve introduced have been welcomed warmly but the reception to others has been a little icy. In particular I’ve tried to move the team away from a test case management system. This was met with real concern and there was quite a resistance to the idea.

This troubled me as while I understood their concerns, I knew the system was limiting the generation of new testing ideas.

But how could I overcome this resistance? And really was it worth it? Perhaps the changes I had already made would be enough? The company was already more than impressed with the changes I had made so far.

I felt like Indy at the foot of rope bridge, how the hell was I going to solve this one?

So I stood at my crossroads and dithered. Oh God, did I dither. I ummhed and ahhed and pondered what to do. . But worse, I  knew my indecision was making the situation worse, and that the more I dithered, the harder it would be to rid ourselves of the dust bag of tired and well worn ideas.

Indy at this point, decides his only move is to cut the bridge leaving everyone to hang on for their lives.

Fortunately, unlike Indy I had a reliable and trustworthy sidekick.  Together, we setup a task force within the team to attack the problem. After some discussion we decided our approach needed four cornerstones. They were:

1) Creativity.

However we tested, our approach needed to enable us to foster and encourage creativity. With creativity comes new ideas, new models, new tests and so discover new bugs.

We’re covering this one with a number of approaches. One is to improve tester skill through practice and coaching. I’ve also created a folder of ideas for people to draw upon to help trigger new ideas.

2) Visibility

We wanted to be able to provide reporting on any testing we do. The reporting has to be simple yet with sufficient detail to ensure that our stakeholders understand what we have tested and why.

We have our trusty whiteboard which mostly hits the spot. We need to be able to pull up our actual testing including results in an easy to manage way. We’re looking into BBExplorer to handle that.

We will also track any essential test results on wiki in the form of a test report at the end of each iteration.

3) Coverage

We wanted to have some way of ensuring that key functionality/key features are always tested.

We most likely will rely on our test case management system for this, but we’re cleaning out all the dead wood and making the tests lighter and less authoritative.

4) Knowledge

We wanted to create a knowledge base. Our system is complex and it requires in-depth knowledge to test some areas. We want to store that information and knowledge. We also have a serious amount of test data we want everyone to be able to access, modify and improve.

We’ll use our internal wiki for this.

What I really like about what’s happened here is that the team came up with a solution to solve the problem. It’s a team decision which has got to mean easier implementation.

I think a couple of really powerful things have come out of this. I’m listing them here:

1) Change can be scary. Not changing is worse. Get on with it.

2) Use people around you to help bring about change.

3) Never lose site of your goal. This reminds me of Scott Barber’s email signature: “”If you can see it in your mind…you will find it in your life.”

I feel good. I hope my team does too. We faced a challenge. We examined it, questioned it and overcame it and we’ve all come out sharper, enlightened and positive about the changes ahead.

Now that’s what Exploratory Testing is all about.

 

Rediscover your inner tester

Linda Wilkinson in a recent post called on ‘Experts’ to come down off their ivory towers, and get back in touch with the rest of the ‘hoi polloi’.

Ivory Tower

Ivory Tower

It got me thinking about how in one way or another, we all have an Ivory Tower in testing which we can brag about. Your Ivory Tower (if its anything like mine!) is a nice place to be in. 



We can sit back and feel comfortable there, we know what we are doing and people treat us with certain level of respect.  No-one decided in advance to build these towers, but over the years, as we have specialised, it has become an area we have decided to call our own.


Some Ivory Towers I’ve come across in sofware testing are:

  • The Methodology Tower

    Over the years one process or methodology dominates and closes our minds to  new approaches such as Agile or Exploratory Testing. Or, we are so won over by Agile, that we fail to explore other avenues that may be of benefit.

  • The Trainer’s & Speaker Tower

    After many years of testing at the trenches, the experience acquired is used to help other testers by training and speaking in conferences. Gradually, the speaker/trainer looses touch with the tester on the front and starts finding it hard to identify with issues testers face on a daily basis.

  • The Management Tower

    Climbing up the corporate ladder, the Test Manager spends most days, managing people and projects. Their goals and challenges differ from the tester on their teams. They too start to loose touch on the real issues that testers face.

  • The Manual/Automation Tower

    As a tester, perhaps  whilst performing other tasks, perhaps you have decided to specalise in only certain areas? Manual testers, when did you last try out automation or performance testing?

There is nothing wrong in specialising, or having a niche. But in building these towers, how far have you wandered from the path of testing? You know, the actual testing, where you sit down in front of an application and well look for bugs?

In narrowing your skillset, I think you narrow your mindset, and consequently loose out on all the benefits that testing have to offer.

Puzzles and writing articles are good ways keep up your cognitive skills, but really nothing beats testing a product to remind of the real issues everyday testers face. Try getting your teeth stuck into a good testing problem, and remind yourself of the pleasure and heartache that testing can bring.

Puzzles and forum discussions will never replace or use the sheer number of skills you require in testing such as communication, negotiation, cognitive and written skills.

So, if you really want to get in touch with your inner tester get out and test. That doesn’t mean you have to give up your training or test management or what ever area you have chosen to specialise in, but there is no reason why you can’t contribute to some opensource testing, or volunteer to assist a charity in their software testing. If you can’t see your way to doing that, try keeping  the tester in you alive by going for the many testing challenges that seem to be popping up. I really like the Weekend Tester’s created by  Ajay Balamurugadas. They set themselves challenges and applications to test as a way of improving their testing skills. Matt Heusseur is another person who set a challenge on his blog.

Go on, I dare you to step outside and sniff the air outside your Ivory Tower and rediscover your true inner tester.

I’m glad I’m not a piece of software

I joke about my personal development lifecycle (PDLC) as my work in test management often requires consistency & repeatability in the form of a test process. In comparison my own PDLC is often very erratic and ill behaved. In fact its not really a typical lifecycle at all except perhaps that I was born and one day I will die.

My family and I have recently decided to spend some time in Ireland. In November, we are uprooting our family in Melbourne, Australia and dumping ourselves back into a very sodden, albight green sod of turf known as Ireland.

We are doing this without any certainty in jobs, schools, long term accomodation etc and its making me extremely nervous. To make it all the more uncertain, the world has decided to have a global financial crisis. My faith that all will work out is being severly challenged!

As I  continue along my PDLC, my outlook on life has changed. What would have once been an adventure is now looking like a torturous test.

So I repeatably breath my mantra, “it will work out, I will find work in Ireland” . Who says life is dull?

Anyhow, back to software testing and lifecycles.  I suppose the difference between software and people is that we own our lifecycle and thankfully we get to choose how our life turns out.  We can choose to make it unpredictable and we can behave outside a given setup of expectations.  So even though my life at the moment is in turmoil, its my turmoil. I’m glad I’m not a piece of software that has to follow a rigourous testing process, in order to live up to someone’s expectations.

Celebrate your wins in software testing

Too often software testers are the bearers of bad news:

“There is a major defect that will stop us rolling out to production on time”

“We have to increase the budget to ensure that the system is properly tested”

The more I roll software testing concepts to companies, the more I’ve realised the importance of celebrating your wins.

If you don’t who else will?

Small wins are just as important as big ones. I don’t wait for a software testing process to have all the bells and whistles of metrics before I start shouting about the great benefits that testing has provided.

For example; I was rolling out a software testing process that was new to the client.  At every meeting (in particular the senior ones), I declared:

“In addition to completing the system testing, we found seven existing production defects”

I wanted people to know that we have good testers in their company, and also that they were providing a good service.

As testers I think we need to be smarter about how we promote our services.