One of the patterns I have often witnessed in agile projects is testers really struggling to shift their mind-sets away from relay race thinking. The common problem goes something like this:
“Scrum wastes our time. Us testers don’t have anything to test at the beginning of the Sprint and then too much to test at the end. It is a frantic dash at the end to get everything tested in time. It feels very inefficient.”
Well, that’s because that approach is very inefficient. Scrum is designed to highlight waste and will relentlessly continue to do so leaving you two options – either accept it and live with it or change.
One of the key articles that influenced Jeff Sutherland was The New New Product Development Game” by Takeuchi & Nonaka (1986). In the article they demonstrate how a range of companies were out-performing their competitors by moving away from a relay race approach to product development (Type A below). Instead, they were using something the authors called “overlapping phases of development” using cross-functional teams (Type C below).
While this concept appears simple, it isn’t. Working in an overlapping and cross functional manner requires a significant change in mind set – something a lot human beings seem to seriously struggle with. The concept of processing work in discrete phases is a relic of 20th century management, aka Taylorism. While this approach works for Simple work, it is suboptimal for Complex creative work. The idea that testing cant start until development is complete is a classic example of this thinking style. Breaking this habit usually requires some external influence (coaching) to help establish an alternative context.
Don’t underestimate how ingrained relay race thinking is. When most of us were schooled this was the predominant philosophy. We grew up with this approach. We lived and breathed this approach. We rewarded this approach.
The world is now a much more complex place. The problems that require solving are much more dynamic and classic engineering thinking and individual cognitive power is failing us. Systems thinking, creativity, and team-based cognition, where many different brains each come together to apply a broader range of contexts and patterns is proving to be essential.
So how can we shift the mindset of software professionals away from relay-race thinking to this bold new world?
To me is starts with a belief system. I personally believe that people are born naturally creative, powerful and whole. The answer lies within us all, however has been oppressed by an education system that actively stamps out creativity and narrows thought to just what is required to become a workforce drone, along with a corporate workplace that strongly discourages alternative thought. Thankfully, through the hard and outspoken work of many brave people, this is finally changing. Yes, the ice is melting and the creative people are finally being recognized as essential in our future.
So our starting point is to try to remove our ingrained linear thinking pattern and seek alternative viewpoints on the problem. Lets try walking through a common scenario to demonstrate this.
User Story: As a registered customer, I need to be able to add PayPal as my preferred payment option, so that I can pay for my cart items via my PayPal account”
There are a series of tasks required to complete the story, one of which is “update the xyz module to include new payments stream”.
In the Daily Scrum, Sunjit (a developer in the team), volunteers to work on this item and moves it from “To do” to “In Progress”.
As the tester, what are your options now? Do you have to wait until Sunjit finishes until you start your testing? You decide to be brave and ask Sunjit if you could work with him to help test his work.
After the Daily Scrum, you and Sunjit grab a room with a whiteboard and work through what code will be changed. Together you discuss an approach and agree on small frequent cycles together. First off you run a subset of the existing test suite against that area of the code base to ensure everything is currently working just fine. Then, together you agree you will work on the classes GatewayAdapter and PaymentProcessor. Working side by side, as Sunjit updates a particular method within one of the classes, you develop tests, test data and harnesses to test that method. Sunjit lets you know when he has completed that method and you run your tests. Straight away you notice something wrong and discuss it with Sunjit who laughs and says “duh! I forgot about that!” and fixes it. You run the tests again…
This type of approach is one of the fundamental basics of agile – small, fast and frequent feedback cycles, as opposed to the large, slow and infrequent feedback cycles waterfall proposes.
In the Retrospective meeting you and Sunjit discuss how this approach went with the rest of the team. The team are aware that this approach is quite different and naturally feel a little anxious about this new way of working but can see how well it worked. They are eager to hear more…
So let me ask you to challenge yourself and your teams. Be brave and try something different. Start small and give it a go. Then ask what worked and what didn’t work and either repeat or adapt. Try to build a team culture where exploring new ways and applying some creativity is ok and you might just be amazed at what happens….