Category: videos

My biggest takeaways from AgileTD 2020: The future of testers isn’t in automation or testing

I was lucky enough to speak at AgileTD this year and also attend some of the talks. These are my main takeaways from the conference based on the talks that I was able to make.

My confirmation bias sense is tingling with this but…  

The future of testers is not in automation or testing – it will play a part but not as big as – helping teams build quality-in.  

Most teams see testing as either bug hunting or just another cost centre that needs eliminating. Therefore testers (at all levels) need to get much better at communicating the value of testing.

As testers we need to start shifting our skill set from doing the testing to advocating for testing within teams.

The skills we need to develop will take time to build as it’s not a matter of just attending training but having hands on experience of using and applying the skills.   

Otherwise testers risk becoming irrelevant in teams that begin to form without the need for testers if (or when) the next shift happens.

What is working in our favour is the slow shift to adopt new development ideas such as those expressed in Accelerate. But also teams figuring out how to really collaborate and not just cooperate. Think of the dance of passing tickets around that happens in a lot of development teams.

Which talks should you take the time to watch?

So which of these talk further lead me to believe the above. Let me break it down:

The future of testers is not in automation or testing

That is not to say it will go away, but it will not be the main objective of our roles.

Is not automation: Automation Addiction by Huib Schoots and Paul Holland (Day 1)

  • A lot of people’s addiction to automation appears to come from automation tool manufactures marketing (promising the world) and sunk cost fallacy (making it hard for people to stop once they’ve started). I’d also add peoples job spec also asking for automation with no rational as to why they want it
  • It is good for some things, generally things we know how they should behave and especially when we can isolate them from the UI.
    • UI’s can behave in unpredictable ways so not always the best place to put automation that needs to be consistent and reliable
  • So what do you do?
  • Focus on teams and start small: 
    • (Focus on) exploratory testing,
    • (Start small with) a good test strategy that includes what is and is not to be tested
  • Automation should be focused and isolated

Is not testing: Let it go by Nicola Sedgwick (Day 3)

  • We as testers need to let go of testing and start focusing on how we help teams understand what quality is and how they build it in
  • Nicola does this by being a Quality Coach and using Quality Engineers embedded in teams to help them mitigates the risks
  • This was a great talk and something lots of others have been advocating.
  • I think we still need to better define the Quality Coach and Quality Engineer roles but we have to start somewhere
  • I’ve written a little about what testers could do next
  • You can also learn a more about Quality Engineer from my TestBash Manchester talk (paywalled)

Also see

  • Testing is not the goal! By Rob Meaney (See below for more)
  • Beyond the bugs by Rick Tracy (See below for more)

Communicating the value of testing

How to pitch and value testing properly in the age of DevOps by Bjorn Boisschot (Day 1)

  • A fairly simple and affected approach to getting the test team behind a testing vision that they can then use to describe what it is that they do.
  • Rather than the typical dry approach of traditional testing (test scripts, reports, bugs) which all reinforce the bug hunter viewpoint of testing
  • This gets testing focused more towards what the organisation is trying to do (think company mission statement) and focuses the testing vision towards that
  • This helps others understand that it more then just bug hunting but about helping make decisions on the quality of the products and how they affect end users
  • His approach was to create a testing mission based on the company vision statement. With a focus on the why of testing and not the what or the how (see Simon Sinek: Start with why). From there they created a number of goals that would help them achieve that mission. Then they used the goal, question, metrics technique to make it measurable.
  • For some in the org this approach made testing much more accessible and greatly improved their view of it.
    • But for others, well, they still didn’t care 

Beyond the bugs by Rick Tracy (Day 3)

  • As senior members of the test team we need to help our testers understand what value they bring to teams. Then give them the tools (verbal and written communication skills) to make their value relatable to other roles. Otherwise they are very likely to be seen as bug hunters and a cost that can be eliminated.  
  • Really fascinating talk where he showed how everyone outside of testing views our roles (bug hunters that cost money). He then showed how we need to cover three main arguments for others to see the value we bring. These being conceptually (does it make logical sense to them) practically (how can they/others use it) and monetary (what does it cost and what’s the ROI). 
  • He then applied these three arguments to different testing scenarios from doing no testing at all to shifting testing as far left as possible and doing it earlier and earlier in the process. Through this he showed how the initial investment in testing increased but would dramatically decrease the costs later on in the process due to issues being found earlier and therefore easier and cheaper to fix.
  • This all reinforced the idea that testers do much more then add costs to projects and finding bugs. Such as 
    • Manually finding issues that would otherwise affect users 
    • Testing earlier on in the process before code is written by testing requirements and designs to prevent issues entering into the systems earlier
    • Raising levels of team understanding in the product, the processes they use and potential issues that is could be introduced 
    • Types of risk that could affect the team and acting as a type of insurance of that risk 
    • Making testing relatable to non testers 
    • Providing sources of information for innovation and improvements within the teams ways of working 
  • But all of this doesn’t just happen. You have to invest in your testers (and them in themselves!) for them to be able to do this such as their technical skills, improving their awareness, understanding risk, alignment with the org etc. IMO: If you keep testers ‘dumb’ and just bug hunting then that is all you will get 
  • He then linked this investments to potential measures so you can see if your investments was paying off and a way for testers to see improvements. Cycle and lead times where two areas that came up quite often 
  • These measures where then linked to business value. Two main ones being faster time to market and improved customer trust in the product. 

The skills we need to develop

These skills are not limited to just these talk but are great examples of what they are

How to keep your agility as a tester by Ard Kramer (Day 1)

  • Great talk about how he uses the 4 virtues of stoicism to be a better testers. I actually think this would help a lot of people within development teams so if you’ve not heard of it before I recommend checking it out. 
  • This looks like a good resource https://iep.utm.edu/stoiceth/ but this talk focused on just the 4 virtues of wisdom, courage, justice and moderation 

Also see 

  • Extreme learning situations as testers (Day 3)
  • How to keep testers motivated by Federico Toledo (Day 3)
  • Beyond the bugs by Rick Tracy (See above)
  • Testing is not the goal! By Rob Meaney (See below)
  • Introducing psychological safety in a tribe (See below)
  • Growing Quality from Culture in Testing Times by Tom Young (See below)
  • Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

Adopt new development ideas

Testing is not the goal! By Rob Meaney (Day 2)

  • From  testability > operability > observability and his journey with his learning with these techniques and how teams have be able to make use of them.
  • I think one of the really interesting points he made was understanding where your team is in their development life cycle.
    • Are they just starting out or are they an established team and product.
    • Depending on where you on this cycle will affect to what level you will need testability, operability and observability.
    • As the three things are about managing complexity and when you are starting out complexity isn’t the problem, product market fit is. 

Also see

  • Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

How to really collaborate and not just cooperate

Growing Quality from Culture in Testing Times by Tom Young (Day 1)

  • Great story from Tom Young on how the BBC news mobile team have grown over the years and how focusing on their team culture has been one of the best ways to build quality into their product. All they way through the talk Tom shouted out to how the whole team help deliver their product

Faster Delivery teams? Kill the Test column by Jit Gosai (Day 2)

Introducing psychological safety in a tribe by Gitte Klitgaard and Morgan Ahlström (Day 3)

  • Hearing how other people have tried to address psychological safety in organisation was very interesting. There was a lot in the talk that I recognised from Amy Edmundsons work (Teaming and Fearless organisation). They didn’t use Amy definition of what psychological safety is but from what I’ve seen all the definitions are almost the same. Simply put are people willing to take interpersonal risks within group settings. If so they have psychological safety if not then they are considered lacking it. 
  • The things that stood out for me was that all these types of initiatives take time and constant work. They are not things that you run a workshop, take a few questionnaires and you have the safety.
  • Also psychological safety is very personal thing so what one person feels is not the same as another in the same team. 
  • There is also a lot of misconception around psychological safety in that people feel that in psychologically safe environments will no longer have any conflicts and is all about everyone being comfortable. This is not the case.
    • PS environments are about being able to share your thoughts and ideas without the worry that it could be used against you in some way.
    • The main reason for PS is to establish environments conducive to learning from each other – which is what is needed for the knowledge work that we do 
    • But to learn effectively your need some level of discomfort
    • Too much discomfort and it can tip into fear which causes the flight or flight response  
      • and you’re not learning anything other then self protection 
      • The best way to protect yourself? Don’t say anything that could lead to a situation that causes conflict… 
    • So PS environments are about people being able to work through conflict productively that can lead to new insights and ideas

There was many, many more talks at the conference (perhaps too many) that I wasn’t able to make and thats not including the workshops so it is worth looking through the programme and seeing what stands out for you.

Think I missed a talk that should be in the list above let me know in the comments.

What is it about that particular talk that makes you think it should be included?

What above do you disagree with?

How Falling Behind Can Get You Ahead

 📹  15 minutes TEDx talk from Manchester 2020 How falling behind can get you ahead some highlights: 

  • “Jack of all trades, master of none,” the saying goes. But it is culturally telling that we have chopped off the ending: “…but oftentimes better than master of one.”
  • In a society hyperfocused on headstarts, we are told to choose our paths early, focus narrowly, and start racking up our 10,000 hours of deliberate practice. But a mountain of research shows that, among people who end up fulfilled and successful, early specialization is the exception, not the rule.
  • Winding paths and mental meandering can be sources of power, not disadvantages, but we rarely hear those stories. David is trying to change this.

Specialising may not be such a great thing and references an interesting theory  Kind and Wicked Learning environments. 

Kind Learning environments  

  • Kind give lots of feedback as you progress which aid deliberate learning 
  • The rule of the system don’t change either so what it is today is the same tomorrow 
  • Golf and chess are such environments 

Wicked learning environments  

  • Mixed levels of feedback as you progress
  • Rules of the system keep changing 
  • I think software engineering maybe a wicked environment
  • But need to do more research  

The biases called out in the paper could be really helpful when thinking about decision making that affect learning in these environments. I’m also certain I’ve been influenced by survivorship, censorship, selection and the ‘hot stove’ biases.  

How to break the rules?

Dan North gave a really interesting talk at last years GoTo Conference called How to break the rules.

He takes Eliyahu Goldratt 4 steps of how technology is adopted which he presented in a series of lectures he gave on why people didn’t take on his ideas of theory of constraints (TOC) from his book The Goal.

Eliyahu stated that organisation need to go through 4 steps before a new technology can be successfully adopted:

  1. What is the power of the technology
    • What does it do for you?
  2. What limitation does the technology diminish?
    • What will it make better
  3. What rules enable us to manage that limitation presently?
    • And how much are we wedded to those rules
  4. What new rules will we need?
    • For the technology to succeed

Dan than takes these 4 rules and applies them to real companies that either succeeded or failed to take advantage of new technologies. The interesting part is for the companies that failed what rules (part 3) they needed to break to make use of the new technology.

I’ve made my rough notes on the talk available below but I highly recommend watching it.

 

My notes from the talk:

Talks about The Goal (book) and Beyond the Goal – lectures by Goldratt

  • Series of lectures about 20 years after The Goal was released
  • He tries to attempt to explain why people didn’t apply his Theory of constraints successfully if at all.

First two lectures are: How to adopt Technology?

What is technology: The application of knowledge

For it to be adopted then answer these questions:

  1. What is the power of the technology
    • What does it do for you?
  2. What limitation does the tech diminish?
    • What will it make better
  3. What rules enable us to manage that limitation ?
    • How much are we wedded to those rules
  4. What new rules will we need?
    • For the technology to succeed
He then goes on to apply these questions to real companies.
  • MRP – first application of computers in a business situation
    • Calculated cost of materials for manufacture DuPoint
    • Which allowed them to ship faster then others
    • But when the competition tried it they couldn’t compete as to take advantage of the system you need to change the rest of your business
  • Goes on to apply to ERP and
  • Cloud computing (orgs moving to it)
  • But also Continuose delivery

Interesting: Dell becomes as big as it did because it could work in smaller batches then the competition . All the others companies offered you a fixed machine. Dell changed this by going online only and allowing you to customise your PC and could ship faster than the competition.

Swedish  saying: When talking to farmer use farmers words
  • Commenting on how we collaborate across divisions
  • If you want to collaborate successfully you need to either be speaking the same language or use words the other understands

A lot of organisations are failing with Agile/Kanban/Scrum etc because they still have all the exiting rules in place (see point 3 earlier).

To be able to adopt the new technology you need to move to the new rules (point 4) otherwise you’re still doing the same thing.

Used the example of Amazon not doing Cost accounting and moving to throughput accounting and flow of value

  • Cost accounting is what each department cost
  • Through put accounting is what is being produced by the department and what value does that provide

The problem with step 3 is that it eventually becomes the culture of the organisation and trying to unpick it then is really hard.

So How to break the rules?

  • Understand the power of technology
  • Recognise the limitation the technology will diminish
  • identify the existing rules we use to manage the limitation
  • Identify and implement the new rules

Summary

Another great talk from Dan and goes to show a lot of our problems in software development have been issues in other industries.

Not only that they have been solved  but we tend to overlook them as they don’t look like our industry. What has manufacturing  got to do with writing software? In all don’t take my word for it go watch the talk and start having a look at Eliyahu Goldratt body work. He was onto something…