3 traits of Self-leadership

A colleague of mine Qambar Raza recently shared this great Ted talk with me on self-leadership 👏

🎥 🍿🥤 Great leadership starts with self-leadership | Lars Sudmann

In it Lars describes three behaviour traits to improve your self-leadership:

1. Self awareness
2. Self reflection
3. Self regulation

This is a brilliant way to change any personal trait that you would like to be different.

The key to it is Step 1 by recognising what you do want, how that differs to what you do now and then identifying the incremental steps towards it.

The difficulty comes in Step 2 being honest with yourself everyday about how you are progressing towards your goal and what feedback mechanisms you are using.

Finally Step 3 is recognising that situations outside of your control will still occur where you might default back to your existing behaviour. So instead of trying to repress your response reframe how you look at the situation instead that enables you to look at the situation in a different more positive mindset .

Don’t know where to start yourself improvement journey then start by identifying some of the default behaviours you might exhibit.

Reducing Uncertainty in Software Delivery

I recently attended a half day online event that InfoQ held on Reducing Uncertainty in Software Delivery. The thing that made this half day event different was the underlying focus on testing but without a single tester present in the talks or panel discussions. The majority of speakers where developers and there was even a few Engineering managers, Product people and a CEO or two. It also appeared to me that none of them have come from a traditional testing background. However they all made points that a good tester would and then some. The advantage they appear to have over testers is that they were able to incorporate their knowledge of their discipline to give a much broader view than just focusing on the testing itself. 

A key theme that I’m seeing from these talks is that they are spending a lot of effort on learning from failure. Either by analysing ones that have happened in production or actively encouraging teams to cause failures. It was only the more advanced organisations that were taking this approach but the others were not far behind. Why? To make their systems even more resilient. Their approach appears to be using Site Reliability Engineers (SRE) to work along side their engineering teams to help them do the work but also enable the teams to extract the learnings from it too. This isn’t simply having chaos testing to cause failures or postmortems for production failure analysis but to also help teams with the people side of working with and handling failure productively.

The talks that caught my interests were Building in reliability (SRE at Gremlin), User Simulation for Rapid Outage Mitigation (SRE at Uber), and a panel discussion on Testing in production (with 2 CEOs, Product person and an Engineering Manager). 

Now this is a small sample, the speakers are very experienced and working or have worked at some of the best known web based organisations (Google, Uber etc) and US focused too. But I’m seeing a lot of things that testers could advocate for being pursued and implemented by Site Reliability Engineers (SRE). For example: 

  • testing in production,
  • building in observability,
  • pushing testing earlier in the process,
  • encouraging developers to test their own work 

The advantage SREs have is they already have the technical ability and are now starting to build out the socio-technological skills that they were lacking previously. These organisations have another advantage in that they are heavily focused on learning from their failures. So when they do get things wrong they work hard to make sure they extract as much value from that failure as possible. On top of that some of these organisations are actively causing failures within their systems to further limit catastrophic failures that could occur.  Some of these organisations have never had tester and from the looks of things never will. If you’re pursuing a true continuous improvement strategy testers could look like a bottleneck in the process slowing down information flow. How can testers enable the flow of information and what can they add that makes this information even more valuable?  

I’ve pulled my summaries of the talks I found interesting below 

Talk: User Simulation for Rapid Outage Mitigation

Uber uses an alternative approach to end-to-end testing due to their system being so big that no one person can ever fully understand it. Instead they use composable tests that each team will create that allows that team to tests their part of the system but mix in other parts pre and post steps built by their dependent teams. These are then run in a simulation environment that allows them to see how the system will perform when that change is deployed. To incentives team to build the tests they use a mixture of pain (woke-up at 3AM due to production failure) and mitigation support team (hold their hands at 3AM) to encourage them to build the tests. For example if you had these test you wouldn’t be awake at 3AM trying to mitigate the issue. They also don’t try and solve the issues at 3AM but mitigate them so others can also learn about outages that affect their system.

Talk: Building in reliability

Interesting talk focusing in on availability of systems within organisations. The speaker walked through how you could go from 99% availability to 99.99% and how it is a learning journey. Used a simple analogy going from crawling, walking and running to get your availability towards what makes sense for your organisation. Essentially can you do it manually, can you script it and can you automate it? I find this slide as a great way to help others understand what the outcomes are at each stage going from 99% to 99.99%.

Panel: Measuring Value Realisation Through Testing in Production

I usually only see these types of conversation from tester focused panels but none of this panel where testers. Tester focused panels typically focus on testers testing in production but this was very much focused on learning from real users in production. Interesting thing from my prospective was they made all the points that I would expect a reasonably experienced tester to bring. In some cases due to their roles being out of testing they focused on the costs and benefits that were outside of simply testing in production e.g. down side of A/B testing or product management mindset shifts that need to happen to embrace learning from users rather then whatever the road map they have decided says.

In some ways testers testing in production almost act like the middlemen of the learning that happens during testing. Could it be that in some cases testers are getting in the way for teams to learn effectively from testing in production?

Scales of Collaboration

Reading time: 3 minutes 

Idea in brief: The scales of collaboration can help you and your teams to work more effectively by improve your collaboration. It allows you to measure how you are currently collaborating and what you can do to improve its effectiveness. But what’s wrong with our current approach and how do you use the scale?

Issues with existing collaboration

Whenever I talk with people who work in teams one of the things I hear quite often is how much they are collaborating. But when we start digging into what they are doing you begin to notice that everyone has a different idea of what collaboration means.

This results in behaviours between team members that puzzles them when they think they’ve done everything right but the other people don’t respond in the way they anticipated. 

Examples I’ve heard of collaboration :  

  1. ‘They should know where to find all the information’
  2. ‘I sent them an email with all the details, they just never did anything with it’
  3. ‘I gave them an opportunity to feedback anything they wanted, they didn’t so it must be fine’

In all three cases the people involved believed they where attempting to collaborate but in reality all they where doing was making information available. It was up to the recipient to decide what to do with the information if anything. 

Scales of collaboration

If this isn’t collaborating then what is it and for that matter what is collaborating? This is where the scales of collaboration could come in useful. Taken from the work of Bruce B. Frey et al 2004,  Measuring Change in Collaboration Among School Safety Partners . Which was originally developed from Levels of Community Linkage Model (Hogue, 1993)*. It was developed as a questionnaire to measure how well groups of people collaborated. 

*Which unfortunately I’ve been unable to find the original paper only references to it

This works on 0 to 5 scale with each level having a defined set of characteristics. Where 0 is no interaction at all and 5 being collaboration. With each level building on top of the previous one.  

Scales of collaboration
Scales of collaboration developed from Levels of Community Linkage Model (Hogue, 1993)

When applied to the collaboration examples above you can see that example 1 is just making the information available which would indicate level 1 – Networking. Example 2 while is providing the information isn’t asking them to do anything which is level 2 Cooperation. Example 3 would welcome feedback but isn’t explicitly asking or providing them with a mechanism to do so therefore it would also be level 2 Cooperation.

Following the scale up towards level 5 begins to highlight what else each example would need to do to improve their collaboration.

Characteristics of collaboration

I have further augmented the scale with a few extra characteristics. This will also help you work out where you are on that scale and what you trying to achieve. This includes 

  • How you make information available to others 
  • Consumer/provider interaction model of this information 
  • Speed of decision making
  • Engagement levels of the people involved 
  • Examples of what each level of collaboration could look like 

I’ve also left off level 0 on this diagram as that would indicate no interactions and possibly not even awareness of one another.  

How to us it?

  1. Establish where you are on the scale  
    • You could do this by seeing if what you are doing fits onto the scale based on its characteristics or if it looks similar to the examples on the scale provided 
    • Once you’ve established where you are on the scale then
  2. Where do you want to be on the scale? 
    • The best way to do this is to identify the aim you are trying to achieve based on: 
      • The information: 
        • Is it just information providing, an opportunity to get feedback or to change opinions/direction?  
      • Decision Speed:
        • How quickly does a decision needs to be made
      • Engagement: 
        • If something needs to change due to that information and/or decision then there will be a greater need for engagement 
  3. How will you move up (or down) the scale? 
    • Use the characteristics on the scale as possible things you could do to move to this level
    • What do you need to do to move in the direction you want to go in?
  4. Share the scale with the people you are trying to collaborate with
    • This would create a shared understanding of what collaboration means to this group
    • Which helps everyone involved understand what is going to be expected of them and what overall outcomes everyone is trying to achieve

If you have already started to work with people then I would also avoid trying to jump straight to where you want to be. The risk being that it doesn’t lead to the collaboration you anticipated. Which could make it much harder to convince those people of your collaborative efforts in the future. 

My personal preference is to use each stage of the scale as a stepping stone to the next. This way you iteratively build up your skills and approaches towards getting more of what you want and less of what you don’t. This also allows more room to tweak approaches as you get feedback and are therefore more likely to be successfully in the long run.

What do you think?

  • What do you think of the scales of collaboration?
  • Where do your teams sit on the scale?
  • Would this help you and your teams to collaborate more or less?

Let me know in the comments section below.

Exploratory and Automated testing: Using the right techniques in the wrong contexts

Reading time 2 minutes

Exploratory testing is about testing in an unpredictable context and therefore detecting unpredictable failures in our software. Automated testing is about testing in a predictable context and therefore detecting predictable failures. The mistake we make with automation is we try to apply it to the wrong context. You can’t use testing methods developed for predictable context in an unpredictable environment.

While there is nothing physically stopping you neither practice is particularly efficient if used in the wrong context. Exploratory testing in a predictable environment would just confirm what you already knew only slower and less consistent when repeating the testing . While automated testing in an unpredictable environment would lead to false negatives.

It’s also not a one size fits all solution either as we work in both contexts. Predictable when initially developing the software and unpredictable once running in the live environment.

The only way you can replace exploratory testing with automation is to make the test environment predictable. But that would then mean you are trying to detect predictable issues. This then negates the outcome you were looking for which is trying to detect unpredictable or complex failures.

Testing in unpredictable contexts

The best way to detect unpredictable failures is to use methodologies that can operate in an unpredictable environment. 

One of the best known methods is exploratory testing (sometime called manual testing) but there are other technique too. Such as monitoring of the live environment. Which is good for issues we can predict in an unpredictable environment. Observability using logs, graphs and other telemetry to see how the system is behaving in the live environment. This is helpful for issues we can’t predict and need to debug in the live environment. Phased rollout of features using techniques such as feature toggles, blue/green deployments, canary releasing etc. Useful for limiting the impact of unintended issues in a unpredictable environment. Basically anything that allows you to slowly enable a feature for subsets of users.

Using monitoring and observability in conjunction with phased rollouts can greatly improve your ability to understand and limit how new code behaves in unpredictable environments. 

Testing in predictable contexts

This is not to say automated testing is invaluable as it can help detect smaller predictable issues. Which if left unchecked could develop into larger unknown failures that only occur with the right mix of other smaller issues. Some issues maybe within our control (software we develop) and some outside of our control (other people’s software). For software in our control (a predictable environment) automated testing is almost a prefect match. For software outside of our control (an unpredictable environment) contract testing, exploratory testing, monitoring and observability and phased roll outs of software is preferable. 

Control and isolation

Next time you’re looking at testing techniques think about how much control (and therefore isolation) you have over your test environment. The greater the level of control then the more automation you should consider, but the less control you have then the more you should consider exploratory testing coupled with monitoring, observability and phased rollouts. 

Testing techniques

The following diagram will help you see how different testing techniques stack up against each other. This is by no means an exhaustive list and is only comparing them on a speed of feedback, value of feedback and testing environment bases. So the next time you get into a discussion about testing you could use these characteristics as a good way to frame that discussion.

Testing techniques plotted on a speed, value and environment axis
Testing techniques plotted on a speed, value and environment axis

Are there testing techniques that should be plotted on the chart?

Do you agree with the axis? Is there another more important characteristics of testing that should be captured?

How would you plot the testing techniques?

What are your default settings?

2 minutes read

I recently read Enlightenment now by Steven Pinker which I highly recommend reading. Among the many ideas within it he talks about some of the bugs that creep into our ways of thinking and reasoning about the world. If you’ve ever read Thinking, fast and slow by Daniel Kahneman or watched any TED talk about reasoning and decision making you’ll be quite familiar with some of these bugs. 

This got me thinking that a lot of these bugs are kind of like our default settings and it needs conscious self-awareness to switch them to something else. The default approach being fast and automatic (System 1 style of thinking from Daniel Kahneman) and more towards conscious self-awareness being the slow and deliberate (System 2 thinking). 

While this isn’t an exhaustive list and not everyone is affected by the same defaults to the same extent. I think we can all find examples within ourselves and in other situations where this default approach has influenced our thinking. 

I’ve grouped these into

  • Thinking in generalities 
  • Focusing on self-interests
  • Believing in magic 

These break down further into specific behaviour and thought patterns, see image below

What are our default settings?

I have also tried to include citations and research evidence, see the grey source boxes in the above image. 

I know I have fallen foul to these bugs and I bet there is examples of it throughout this blog. So what can we do?

One approach that I think could help to override these defaults is by developing our self-awareness about them. 

  • Firstly by understanding what they are and what they mean to you. Can you think of any examples of you being affected by this way of thinking, believing and focusing? 
  • Secondly recognise that they do affect you just as much as other people but you probably spot them in others more than yourself. Focusing on evidence that confirms our beliefs while dismissing evidence that contradicts it.
  • Thirdly slow down and work backwards though your thinking.  What facts, observations, correlations and feelings are you using in your analysis of the situation? 

This is by no means fool proof and whenever you end up in fast modes of thinking you’re likely to fall prey to one or more of these defaults. So should you even try? I think we should and with plenty of time and practice I believe we can start to alter these defaults.

In the meantime one of the best ways to check yourself is to work in groups. Especially within groups that you believe you can take interpersonal risks* with. This will help with getting feedback in an open and honest way so you can start to make better decisions and more reasoned analysis of situations. This will also help with starting to understand what is influencing your thinking and if it is one of these defaults at play.

I strongly believe in incremental improvement and finding good sources of information about yourself is a great place to start that personal journey of self-improvement.

* You can learn more about interpersonal risks from my why do we need psychological safety in software teams post. 

Tips

  • A lot of these defaults can affect us in such a way that they are interconnected and can be quite difficult to pick part    
  • I’ve found that being able to recall the defaults from memory to be really helpful. This helps when you’re being mindful and looking at your thinking to see if one of these defaults is at play. If you need to keep looking them up it not only slows you down but makes it less likely to happen. The easier something is the more likely you are to do it

What do you do to stop your default thinking taking over?

Have you come across any other defaults that you or others use?

Why is psychological safety important to software engineering teams?

4 minute read

Update: Scroll to the bottom for a video of what is Psychological safety and why should you care in under 10 minutes.

Before you can answer this question you need to know what psychological safety is. Amy Edmondson in her book The Fearless Organisation describes it as: 


The belief that the work environment is safe for interpersonal risk taking

The Fearless Organisation

The best way to understand what this means is to break down the three key areas.


Interpersonal risk

Interpersonal is defined as relating to relationships or communication between people therefore interpersonal risks are issues that could affect relationships or communication. This can be thought of as others perceiving you to be: 

  • ignorant – when you share you don’t know something
  • incompetent – when you make a mistake as you don’t know how to do something
  • negative – when you highlight mistakes, issues or potential problems
  • disruptive – when you make suggestions that are different to others or generally asking questions that no one else is

The most effective way to counteract these risks? Staying silent or limiting what you do say to just the bare minimum.

The problem here is that those very risks are some of the best ways we can learn from each other. By not taking those risks we slow or even limit the innovation opportunities for ourselves and others.

Work environment 

This can vary from situation to situation but typically the group of people you find yourself working with to accomplish some goal.  For software teams this is usually the team in which you work in day to day. But other working groups could also exist such as your peers across the department or the leadership team you are a part of. 

Belief 

This relates to the individual within a work environment and is what they think about taking interpersonal risks.

What does a psychologically safe environment look like? 

Based on the above definition a work environment would be one that allows individuals to speak up and take interpersonal risks by asking questions, saying they don’t know something, pointing out problems, admitting to making mistakes or make alternative suggestions without other people thinking less of them for it. In fact it is actively encouraged and rewarded to speak up in this way. 

A point to note is that psychologically safe environments don’t mean that there can never be any conflict. In fact it’s quite the opposite and that conflict is almost a characteristic of psychologically safe environments. In an environment like this individuals can have different views but, importantly, can work through them productively without resorting to stalemate.  

Complexity in the work environment 

A lot of work done by software engineering teams can be thought of as complex. Complexity arises from a number of factors such as uncertainty in what needs to be done, how best to do it and if the outcome is even obtainable. On top of that no one person can understands all the intricacies involved with the work due to most systems being larger than any one person can fully understand. This leads to high levels of interdependence between team members while they carry out the work and learn more about the system as they go.  This all needs highly effective collaboration between teams members to work out what needs to be done, how they will do it and how they will know it’s been successful.

These are some of the core reasons why software teams adopt agile delivery methods as they take into account this complexity and allow the people involved to learn as they deliver the system. 

Effective collaboration for group learning 

Effective collaboration between team members isn’t simply each person completing their part of the work and then handing this off to the next person like a production line. All this requires is effective cooperation between team members and coordination to fit all the pieces together*. The problems with this production line framing of the work is that it misses the interdependence that exists between team members due to the complexity in the work environment. 

With effective collaboration individuals are able to learn from each other much more effectively as they are able to speak up and take the interpersonal risks without needing to second guess if their fellow team mates will think less of them for it.

*learn more about cooperation, coordination and effective collaboration using the scales of collaboration

Why is psychological safety important to software engineering teams? 

Creating software systems needs people to share information due to the complexity involved with the work. One of the best ways to make sure that information can flow freely as possible is for the people involved to feel it is safe for them to take interpersonal risks. While this does not guarantee success, teams that do are more likely to identify issues, come up with solutions and implement them much quicker than teams that don’t.

Psychological safety is a characteristic of highly performing teams and is a prerequisite for effective collaboration which is fundamental within software teams. 

Video: What is Psychological safety and why should you care?

What do you think?

Do teams need psychological safety?

What else can they do to help smooth the flow of information in teams?

How have your teams addressed collaboration?

Three things of 2020

3 minute read

Below are three things that when I reflect back on 2020 that stand out to me. I’ve purposely not mentioned COVID because I think this is one thing that all of us would have on our list so didn’t think there was anything more I can say on this that no one else is already thinking. I’ve also included my three things from 2019 at the end which I still think are important. 

🌳 You can’t stick your apples on other people’s trees

  • Something that Sarah has been trying to tell me for some time but it never really clicked until this year 💡
  • I’ve learned a lot this year about how we learn and what we can do to enable more or it
    • My apples…
  • But there is one thing that keeps coming back
  • It doesn’t matter how many different ways you find to engage people with the content
    • Unless they really care about it they may never have the insights that you think they should have 
    • They may never see the benefits you do or incorporate that that information into their ways of working 
    • This is all about trying to stick your apples on other people’s trees…
  • Usually they are just too busy to even be able to give it the time 
  • The best approach is for them to find ways to incorporate into their own learning 
    • To encourage them grow their own apples…  
  • This takes a lot more time than simply forwarding a link to read or even sending them on workshops/training courses… 

Speaking of apples…

🍎 Informal Relationships

Informal Relationships between team members is the key foundation for high performing engineering teams

  • Most teams members can work with each other quite efficiently but the level with which we do makes the difference between low and high performing teams 
  • We can cooperate and coordinate quite well as can be seen by how well teams can slice up work into tickets and hand them off to the next stage (cooperating). Some teams take this further and begin coordinating their actions using information from their step in the process to inform the next stages (coordinating)
  • But coordinating with teams members isn’t enough we need to be able to collaborate because of the level of complexity we work in means no one person can ever know it all. This essential and often forgotten detail makes team members interdependent 
  • It’s the level of how well we can collaborate and work through problems that gets teams towards higher levels of performance. This performance can be measured by how sustainably the team can deliver end user value (throughput)
  • Psychological safety plays a big part in this interdependence and collaboration and can be characterised by how well people in the team can “just talk to each other” 
    • Psychological safety being the belief of individual team members that it is safe within their work environment to take interpersonal risk 

🎓 Learn more: Fundations of great teams? Start with relationships

🍏 Manager or Leader? 

Understanding the difference between the two can be really helpful  

  • One of the things that has really stood out for me this year has been the difference between management and leadership
  • I always conflated the two and never really appreciated the difference
  • Since then I’ve not looked at software engineering teams the same again
  • Do other make the same mistake? 
    • Leading to confusion on when we should be leading our teams and when we should shift to a more management style 
  • A Hybrid model may also be workable 
    • especially the closer you get to where the work is happening 
    • With a heavy slant towards leadership then management 
    • But the further you get from it the more a leadership style works best 
  • A simple heuristic: 
    • the less experienced a member of staff then a more hybrid approach 
    • but the more experienced they are then a more leadership style is appropriate  

Three things 2019

Teams

  • Working as a team will accomplish more than just working alone 
  • I’ve tried and accomplished some things with some good results 
  • But nothing compared to what I’ve contributed to as a team
  • But it starts with trust… 

Trust 

  • that people really do know what the best course of action is
  • They just sometimes need help thinking things through 
  • Which needs people to listen…  

Listen

  • And I mean really listening
  • This has by far been the most important thing I’ve done this year
  • Just asking very open questions and listening to what people say 
  • I’ve learned more about people and what is happening in our teams from this than any other way 
  • The interesting thing is the people I’ve listened to seem to get so much more out of it 
    • I think this is because not many of our team members get a chance to be listened to… 

What are your three things for 2020?

Let me know in the comments below

Foundations of great teams? Start with relationships

4 mins reading time

tl;dr: check out my miro model to get the key points.

Model of who do we prefer working with https://miro.com/app/board/o9J_khGWgWc=/
Good informal relationships are they key to better collaboration https://miro.com/app/board/o9J_khGWgWc=/

Over the last couple of years I’ve started to see that relationships between people appears to play a big role in how successful their teams are. The better the relationship the more willing those people are to share ideas and learn from each other. Which generally leads to much better results for those teams in the long run. Not only that they get those results a lot faster and are typically happier too.

But this is work so shouldn’t we be leaving our personal feelings at the door when it comes to getting things done? What do relationships have to do with anything?

Who do we prefer to work with?

One thing I have seen is that when people like each other they tend to be more likely to work together then people who don’t like each other. Generally for people who don’t get along their interactions tend to be the bare minimum usually resorting to asynchronous methods of communications like email or other group message systems (Slack, Teams etc). They pretty much do anything they can to avoid face-to-face contact.

The problem here is that this can leave messages more open to interpretation and further exacerbate poor relationships. Not only that sharing information this way can at times be slower than simply speaking face-to-face.

But how much do people have to like each other to work together successfully and is there anything we can do to make sure people who do have to work together can get along? 

How much do people have to like each other?

The amount tends to be quite subjective but these types of relationships are usually characterised as work colleagues or sometimes work friends.  They are essentially informal relationships between people who work together where they are very likely to say that the like each other. Multiple informal relationships lead to informal networks which can make working in teams much more productive and enjoyable for the people involved. 

The benefit of informal networks is that they are more likely to lead to collaborative behaviour that enables learning from each other. This in turn can lead to new ideas and innovations. Which all successful teams need.

What can we do to help people get along more? 

By helping people to find more common ground with each other tends to lead people to think of each other as we rather then us and them. This common ground can help people to see that they are similar to each other which can lead to familiarity. Both of which can help towards more positive reciprocal behaviours towards each other. All three of these (similarity, familiarity and positive reciprocal behaviours) benefit us psychologically by making us feel good.

Feeling good to think and collaborate

When we feel good we are more likely to think freely rather than when we feel threatened and are looking to protect ourselves. When we are threatened our brains actively limits resources from working memory. Working memory is a key component for analytical thinking which you need for creative insight and problem solving.  

The level of collaboration is also improved as when we feel good we are also more accepting of people’s differences and more willing to take interpersonal risks with other people.  Interpersonal risks are very personal to the individual but can typically be classified as:

  • Looking incompetent because you don’t know something when you think you should 
  • Thinking you are being disruptive by wasting someones time by asking questions or needing things to be explained in more detail
  • Looking ignorant because you don’t know something  

All three of which can have perceived negative consequences to your reputation.

All these risks need people to be vulnerable in front of others so that they can learn from each other and therefore collaborate more effectively. But if they are unwilling to do this then they are not going to share what they do and don’t know which leads to less effective teams. Essentailly everyone has to figure things out forthemsevles instead of learning it quickly from someone else.

Feeling good means better innovations?

Better team member relationships, feeling good, collaboration and learning from each other doesn’t guarantee that the team will come up with best and most efficient solution to a problem. What it does do is create the right conditions for those solutions to found and implemented.  

Not only that a team that enjoys working together and is able to work through their differences is more likely to keep doing this repeatedly and get better at it every time they do. Therefore leading to more ideas and increased likelihood of the team finding alternative solutions to problems. One of which might just be that innovation your organisation has been looking for to give them the edge over their rivals.

What are the trade-offs to all this harmony?

There is a risks of overly harmonious teams though. This is that they are less likely to challenge each other and are more likely to go with the flow. Which could actually lead to less innovation and creativity. As they are more willing to just accept the first idea rather than challenging it which could risk the team harmony. So some level of “creative abrasion” is needed to help people productively challenge ideas.

But again good working relationships will help stop challenging situations from causing so much tension that people begin to refuse to work with each other.

Is there data that back this up?

Research by Tiziana Casciaro and Miguel Sousa Lobo for their 2005 paper Competent Jerks, Lovable Fools, and the Formation of Social Networks backs up a lot of the ideas above. Their data was based on surveying 4 large organisation and collecting over 10,000 data points on work relationships.

You can find my notes in this model.

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?

Why do we respond the way we do in social situations?

A colleague recently shared an article with me called Managing with the brain in mind. It argues that the workplace is experienced by employees as social structure first then a workplace and that keeping this mind might lead to better employee engagement.

It uses (some) neuroscience research to help explain how people are likely to respond in certain social situations and identifies that people’s brains tend to view situations in terms of threats and rewards* .

It then goes on to detail 5 social qualities abbreviated to SCARF (status, certainty, autonomy, relatedness and fairness) that you could use to help you understand how you could apply some of the research to yourself and your teams.

I found some of the ideas quite compelling and wondered if it would be easier to consume modelled as a mind map.

People perceive social interaction in different ways. The research carried out over the years suggests that they may view it as a threat or reward. If the threat response is too serve then this is likely to limit their brain’s ability to function and therefore limit behaviours that can lead to rational outcomes. If it is a mild threat response then it might be enough to provoke curiosity, free up brain resources and motivate them towards rational behaviours. A reward response is the most likely to lead towards a rational behaviours as they have more brain capacity to take on additional information.

The key point is you will never know fully to what extent someone is experiencing a situation – they may not even be able to articulate how they are feeling themselves. Unless they are responding in a way that is very clear e.g. angry/fearful most likely a threat response, happy/joyful most likely reward response, but most work situations are likely to cause a neutral response with no obvious outward emotion.

Therefore approaching a situation that is more likely to cause a reward response in an individual is most likely to produce behaviours that can lead to better outcomes.

What do you think about the ideas behind the SCARF model?

How would you use the model?

Is there another way in which we can can help people in social situations?

Let me know what you think in the comments below.

*I have to admit this point is a little tenuous as they make this connection by viewing brain scans of how people respond to pain and how they respond to social situations. They found that similar pathways in the brain where invoked whether it was a negative social situation or physical discomfort. But a lot of the ideas expressed in the article fitted in with what I’ve seen.