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 :
‘They should know where to find all the information’
‘I sent them an email with all the details, they just never did anything with it’
‘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 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 interactionmodel 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?
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
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
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?
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?
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?
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.
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.
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
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.
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
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
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
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?
📻 How Can You Stop Comparing Yourself With Other People? If you manage people then this podcast is worth a listen. Having a better understanding of why we compare ourselves to others (social creatures living in hierarchical structures) and what issues it can cause (de-motivation, decreased self-esteem and confidence) can help you from stop doing it but also help you help your reports from falling into the trap. They also cover some biases that can lead to it such as casual inference and narrative fallacy.
💪 How Resilience Works The post calls out three traits for resilience: 1. A grasp of reality 2. Life has a purpose (for you) and 3. An ability to improvise. I’ve not see resilience called out like this before but there are some good anecdotal stories in there and in broad strokes I agree with it. But like a lot of things with the mind its easier said than done. Especially when you’re in the thick of things going wrong. (Book to add to the reading list: Mans search for meaning)
🍏 How Apple controlsthe App Store and therefore the end users How Ben explains the App Store Integration in stages is really interesting and key to understanding how Apple has so much control over developers and users. This is a long read but worth it to understand Apple’s almost unbelievable control of developers and users. If you want to access Apple’s users then you almost have no choice but to do as they say otherwise they can revoke your certificates and cut you off in a instant. The thing is this integration is so complicated most people are either not going to understand it or take the time to figure it out. This is very different to how Microsoft controlled Windows.
17th August
🗺 Things Jobs said I’m no Steve Jobs fan (in the literal sense of the word) but no one can deny he helped create some incredible products. Every so often I read these quotes from him and depending on what’s going on in my work life they take on a different meaning. But one that always stays with me is this one: “You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something–your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
🏌️♀️The Beginner’s Guide to Deliberate Practice What is it? Deliberate practice requires focused attention and is conducted with the specific goal of improving performance, while regular practice might include mindless repetitions. But its not that simple deliberate practice requires that you break down the task into small sub-sections and practice each one till you get better. This is easy if the domain you’re trying to learn is well known, but if it doesn’t have any existing training that you can make use of or you don’t have access to trainers that can help (e.g. mentors or coaches) than you might struggle. I believe this is why it is always a good idea to learn from multiple sources when skilling up in something new that pushes you out of your comfort zone in different ways. If you’re learning something just from one source then keep in mind that it might be one sided…
10th August
🎼 What software teams can learn from music masterclasses Via twitter from @katrinaclokie. Feedback is by far one of the best ways you can learn and Helen makes a great point in that software teams can learn a lot from music masterclasses and studio classes too. Both are great ways to get feedback from more established artists, peers and teachers. But also from peers in different disciplines who can give a viewpoint that your own peer group might not be able to. Another key point Helen makes is that giving and receiving feedback is a skill and as such needs to be practiced to really help people. I don’t think we do this enough in software teams and when we do it’s not always the best. There is a lot we can learn from artistic masterclasses as an industry which I guess reflects the maturity of their professions and the relative youth of ours.
🚽 Code Coverage Best Practices This post from Google testing on the toilet series makes some great points on how code (or test) coverage can be a useful metric for teams to use. The biggest one being about how it highlights code that isn’t covered by tests. This is the perfect opportunity for teams to discuss if it should or shouldn’t. Also the advice on using it to inform on conversations topic for code reviews per commit it also a really good idea. But as the articles points out going straight in with “We should use code coverage!” is probably not going to get you very far. Most engineering teams have been burnt pretty badly by it in the past with developers just trying to hit numbers or it being used to measure the effectiveness of them. Both of which lead to the wrong incentives of number gaming rather than productive conversation starters on what are good and bad tests for your context.
🐦🧵 Everything you needed to know about 2+2=5 Kareem makes a great point that it’s all about context. If you’re thinking just about raw numbers then 2+2 =4 but if the context was say a male cat and a female cat give it some time then could quite easily be 1+1=8. Numbers are an abstraction of the underlaying reality therefore context matters when you’re looking at numbers. One to ponder the next time you’re looking at statistics 🤔
📹 What is white privilege? Via BBC Bitesize from psychologist John Amaechi. This short 3 minute video does a really good job of explain what privilege is and what white privilege in particular means.It’s not that white people have it easy or struggle any less than people of other races. It’s that their struggles are not going to be about their race where as race can be an additional limiting factor from people in the BAME community. In short white privilege means your skin colour will not be used against you.
At the intersection of software, technology and people
Things I’ve been reading this week that I’ve found interesting or intriguing.
“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 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.
At the intersection of software, technology and people
What is this?
Things I’ve been reading this week that I’ve found interesting or intriguing. Sharing because I thought you might like them too. Most of the links will revolve at the intersection between software, technology and people – with the occasional testing slant. I aim to update them weekly, with some commentary on my thoughts and findings. Feedback always welcome 😁
📬 Latest post what do testers do next if the risks mitigated by manual testing can be reduced through other means? Is it about moving more towards creating a quality culture and if so what do you need to know?
📝 My notes on Kind and Wicked learning environments and how they affect your ability to pick up skill.
Some more notes on a really interesting idea from Eugen Wei on Invisible asymptote. See July 10th below for more or head over to my notes on the article that pull out some of the bits I found interesting.
31st July
❓ Four-Level Training Evaluation Model some useful ideas on what to look for when trying to get feedback on your training or other presentations. Another question that comes to mind: Is the training for the learners or for you to accomplish/be recognised for something… 🤔
💭 10 signs you’re an over thinker While thinking is obviously a good thing overthinking isn’t. But how do you know when you’re doing the good type of thinking? Simple rule: overthinking is focusing on the problems (by either ruminating about the past or worrying about the future). Good thinking is problem solving by focusing on the solutions and self-reflective thinking is looking at situations from a different perspective and finding new insights.
👷♀️ 3 things that motivates us to work From Dan Pink’s RSA lecture based on his book Drive. The three things being autonomy, mastery and purpose. Autonomy is about being self directed over what and how you do something. Mastery is having the ability to get better at something that challenges us and making a contribution. Purpose is the reason for being or why are we doing the thing we do. The interesting thing is this is about individual motivation to work. Does it still apply when working in teams as we do in software?
27th July
A model of what could happen if you dropped the ‘In Test’ column…
👷♀️ From ‘In Testing’ to ‘In Progress’ columns on team boards: This has a very narrow focus on just dev and test relationship. This model helps illustrate how improving their relationship and getting them to actively collaborate to improve confidence that the code changes work as intended is going to start having an affect on work in progress (WIP). Which as @johncutlefish shows high WIP can lead to a whole host of other problems. The grey lines are what it was previously with the ‘In Testing’ column broken out into it’s own section.
👯♂️ Don’t Mock Types You Don’t Own This happens more often then you realise and leads to lots of other problems the main one being you now have to maintain a mock of a service you don’t own or fully understand how it works. Therefore you’re testing against your assumptions of that service you’re mocking. This could lead to a false sense of confidence that everything will work when you go to production. Ideally you want to be using a stub with little to no logic e.g. little to no assumptions and any made are obvious to other developers. Contract and consumer driven contract testing particularly can help here. The other issue is people use the word mock to mean a whole host of other types of Test doubles (fakes, stubs, spies etc) which leads to more confusion so check what they mean when they say mock before assuming you’re talking about the same thing.
🎓 Accountability vs Responsibility This has been really useful when thinking about who is accountable within teams for tasks and who is responsible. I found others (and myself included!) mix these up. Accountability can not be shared and means you are answerable for your actions where as responsibility can be shared and you must respond when someone questions your actions. Having these distinctions can be really helpful in making sure people understand what they are accountable and responsible for. The comments are worth a read too…
20th July
😱 Programming is not acraft from Dan North in 2011 and I have to say I agree with his take even from back then this still stands. I think this really sums it up “Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work”. By putting programming at the centre (by treating it as a traditional craft) and not the value you are delivering you risk building what you want and not what users want/need/care/value. Thats not to say the that the code can be shoddy far from it, but just like the plumbing it needs to work but does it need to be gold plated with silver fixings?
📻 How to make your own luck (podcast) the frame with which you look at world (people, events, things that happen etc) are going to have a big impact on the opportunities that you’re going to find. So what frame are you using when making decisions? The world is a wicked learning environment (slow feedback hard to tell which variable caused the outcome) while poker can be kind learning environment (fast environment, low number of variables, easier to identify mistakes and learning from them) therefore helps you to understand your decision making easier and then possibly translate over to the real world.
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, chess and poker 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
13th July
🤩 Invisible asymptote (AKA The Invisible glass ceiling of testing) Excellent (and long) read from Eugen Wei and a must read for anyone working in product and software development in general. Brilliantly articulates that all products have an invisible glass ceiling and that by recognising your total addressable market it can help you understand when you’re going to hit it and actually do something about it.
Why should testers care?
This is a great way to understand how your product owners might be thinking (or should be if they are not). In terms of product quality this could be one of the lenses from which you should look at your products to understand what is valuable to product owners. It’s also a great way to start understanding what value your product is potentially bringing to your users and what cohort that it is and isn’t addressing. My notes on the article pull out some of the bits I found interesting.
In terms of analysis this hits two of the three domains that testers should have a grasp of: business and users. From that angle we can help the third domain (teams) understand how this affects them.
Remember testing doesn’t always look like testing
🔈 How do you handle criticism Getting feedback is by far the best way to get better but not all feedback is equal. You need to filter out the valuable parts from the things that sting the ego. One way to get better at receiving feedback is to rate yourself on how you respond to it. 5 being excellent and 1 being poor. Did you respond positively and thank them (4 out of 5) or did you try and talk them out of their opinion (2 out of 5). This will help you get better at hearing feedback but also more likely to do something about it.
👩💻 Develop your culture like its software Interesting post from 2017 from the ex-engineering manager of The New York times. They used a google doc to make it collaborative and to start iterating on it. Culture is something that either just happens and evolves in a direction out of your control or you try and be deliberate about it. My preference is towards deliberate because then if it starts heading in a direction you don’t want you’re in a position to do something about it. Otherwise you find out when something hits the headlines. At which point its too late to do something…
🏚 Extreme testingCool video of what IBM do to make sure their mainframes can handle earthquakes. Makes you wonder what type of testing AWS/Asura/GCC do for all their server farms
…when you are doing something in a recurring way to diminish risk or doing it in the same way as you have done it before, it is clear why professionalism is not enough. After all, what is required in our field, more than anything else, is continuous transgression. Professionalism does not allow for that because transgression has to encompass the possibility of failure and if you are professional your instinct is not to fail, it is to repeat success. So professionalism as a lifetime aspiration is a limited goal.
🥾 New employee bootcamp really interesting approach to getting people (product owners in this case) up to speed quickly and productive within their work. I really like the concept of “put your own gas mask on first before helping others” in terms of helping them figure out their own career paths. What would this look like for on boarding new testers in a team?
🧫 What is culture? I was doing some research on this and it turns out (unsurprisingly) that its not that easy of a question to answer but the Centre for Applied Linguistics at the University of Warwick (UK) has some really good resources. In particularly this doc which tries to answer that very question in a way that is approachable and can actually help you understand what it is. They break it down into 12 key characteristics but I think this explanation from Spencer-Oatey (2008) does a pretty good job:
“Culture is a fuzzy set of basic assumptions and values, orientations to life, beliefs, policies, procedures and behavioural conventions that are shared by a group of people, and that influence (but do not determine) each member’s behaviour and his/her interpretations of the ‘meaning’ of other people’s behaviour“
🤑 What is value? Interesting way of thinking about what value means. In this model there are two focusing areas: revenue and costs. How does something sustain revenue, increase revenue, avoid cost and/or reduce cost. By applying a monetary number to these you can then discuss them in a way that everyone understands and can hopefully agree on. The other reason for relating this back to a number is having a discussion on what assumptions people are making about those numbers.
Thanks to Duncan Nisbet for his intriguing blog series on cost of delay Vs cost of poor quality which linked me to the above post. In Duncans post he does a really good job of showing why trying to answer that question is really difficult and is setting up a framework in trying to do just that. I’m looking forward to seeing how this works out!
I’ve been thinking a lot recently about what the future of the testers role could look like. Especially in teams that not only fully embrace CI/CD or DevOps but actually get some way towards implementing the ideas behind the approaches.
I’ve broken up my thinking into two posts with the first about whats could happen and this follow up on what testers could do next…
Raising quality awareness in teams
Raising quality in teams isn’t about banging the drum of “We need to make this a quality product” or showing how the product failed some quality criteria e.g. raising a defect. It’s about helping the team understand what quality is and what that means for their system. To be able to do this testers need to be able to articulate what quality means and then apply this to their teams context.
For each tester this context will be unique to their environment. But in a large part, this will be based on how their team works, what their organisation expect that team to produce and who their end users are. Simply put, testers will sit at this intersection of teams, business and users.
Teams
This view point is all about understanding how the team works through their combination of tools, processes, technology, the people involved and what the resulting output is. How does the team do what it does but also why does it do it the way it does.
Business domain
This viewpoint is about understanding the organisation that the team works in. Why does the business exist? What is it trying to accomplish? Yes you can argue that pretty much all businesses are trying to make a profit but how exactly is it trying to do that? Is it by selling advertising, software as a service, access to some physical world good? What is your companies unique selling point? How does it compete against other companies? What external factors affects its ability to achieve its mission? How does the organisation expect the team to contribute to its mission?
Users
This viewpoint is probably the one most familiar to testers as this has been a view they’ve almost always considered. Who are the systems users and what do they expect from it? But they should take this view and expended it further. Why do the users take their time to use your product over others? What do they find valuable about it? Why do some users stay but others leave? Are these the intended people that your organisation expected to use it? Are the users the actual people who pay for the product or does someone else? Who is that someone else and why do they pay for it? Testers should take their time to build, broaden and deepen their understanding of the users, intended users and future users.
At the intersection of teams, business and users
Due to the subjective nature of quality, tester need to understand the reasons behind others views of what quality means to them. These three core areas give the testers the foundational knowledge to do just that.
Now armed with this knowledge and the why of their stakeholders quality measures they can begin to translate this into something their teams can understand and incorporate into their daily work. It’s within this translation/incorporate that you can begin to create a quality culture that isn’t about demanding quality, but creating the understanding of what it means within your teams context.
I’ve been thinking a lot recently about what the future of the testers role could look like. Especially in teams that not only fully embrace CI/CD or DevOps but actually get some way towards implementing the ideas behind the approaches.
I’ve broken up my thinking into two posts with the first about whats could happen and the follow up on what they could do next. So what could happen to testers?
For a lot of software teams the testers role is to assess the quality of the work being produced by the developers. This is usually done by manually testing the software using techniques such as exploratory testing to find any issues that may impact the end users. Any issues found will be raised with the developer who did the work (as defects or an informal chat) to fix if the team deems necessary.
Some teams found this process to be one of their biggest bottlenecks in releasing software so attempted to automate more of this type of testing using UI tests with varying levels of success. Others meanwhile started to look at the testability of what they where producing and started to build quality in.
In both of those scenarios the testers role looks obsolete. With the first supposedly replacing the work they did through automation and the second by removing the role as issues are mitigated before they have end user impact. In both cases what they alway assume is that a testers role is just that, to test.
If the perceived value of testers is just to test the changes made by the development team then the future of the testers role looks bleak but could it be more than this?
Some testers are starting to repurpose the old QA acronym to mean Quality Awareness. What they are doing is shifting the perceived value of their work from purely a testing activity, which was to assure the quality of the system to that of raising awareness of the quality of the system.
This may, at first, look as if they are still doing the same work under a different name, but on closer inspection it is a vastly different role.
I’ve always found that tester representation at agile conferences to be lacking. It’s a bit like it doesn’t have the word test in the titles so it’s not for me. Personally I’ve always found a treasure trove of information from talks that are directly or indirectly related to software testing. Remember testing doesn’t always look like testing you sometimes need to change the frame with which you look at things to get the best out of them.
Below are the talks that I attended with a brief summary of the talk and what it could mean for testers.
Summary of the talk Good talk covering all the basic with keeping your system update and why. Well delivered and really useful for less experienced team members and a good recap for “they should know better” members.
For Testers For testers understanding what needs to be updated when can help them understand how that change could affect end users. Be proactive what do the release notes say for X, how do we use system Y. Building this knowledge takes time but can be really valuable in the long run. Start small and work your way up. Developers can help you but try and help by having specific questions for them.
Summary of the talk: Forecasts will always beat estimates for non-deterministic projects (think all software projects). As they help you understand what could happen with a confidence rating. You’ve probably already got most of this data but knowing your lead times and throughput can help with this and some spreadsheets. The key thing to remember is you need to talk to your stakeholder and make sure they understand what the numbers mean and how it affects them. Don’t just give them the spreadsheets and expect them to understand.
For Testers: If quality means value to someone then value to people working in delivery roles is greater predictability with delivering our software systems. Understanding what these metrics are, how they are used and what affects them will not only enable you to have more productive conversation with delivery but also understand why they are important to that group. This will help you articulate risk better within your teams as you will be able to tailor the message to that specific audience. This will not only help you help them understand risk better but increase your value from just being the person that finds all the issues. This elevates you from being just a tester towards a test analysts.
Summary of the talk Really interesting talk by @cj_smithy at #agilemanc focusing around the book Crucial Conversations but bringing in ideas from the Chimp paradox, 5 dysfunctions of team, Radical Candor and generative cultures by Ron Westrum. Conversations within agile software teams are incredibly important (remember individuals & interactions over process & tools) so being better skilled at them is a great thing.
For testers We have conversation with team members all the time. Whether that is to find out information or to inform others about whats going on, its a core part of our skill set. Getting better at communicating verbally should be part of our personally development as testers. The resources mentioned in this talk would go a long way to help you build up that skill and help keep it sharp.
Leading an agile organisation through hyper growth
By Patrick Kua
Summary of the talk The company Patric was a CEO for went through some really fast growth over a very short period. The model he used was simple and acknowledged that it wouldn’t work forever so they kept iterating and scaling the organisation. Useful to benchmark your company against to see where you are in the growth of your organisation.
For testers Understanding how a company develops from startup to enterprise is really helpful in in seeing what types of problems you’re likely to face. This can help you help your team understand how quality is likely to be affected when scaling and what they can do to mitigate it.
Improve your agile coaching skillswith a Training from the BACK of the Room
By Sabine Khan
Summary of the talk: Its called back of the room as you’re not using slides decks and you presenting but getting the participants to stand and present instead. Hence coaching from the back of the room. Really interesting approach to learning and using coaching skills in teaching others. The 6 learning principles are really quite easy to apply and can make almost any session interactive. This combined with the 4C’s gives you a framework to turn any learning topics into something more than just sit and listen.
For tester needs updating: Need to help team members understand what exploratory testing is then why not do something interactive instead of just another slide deck. Teach them through doing and the key points might actually stick.
Culture + Code ≠ Delivery
By Vimla Appadoo @thatgirlvim
Summary of the talk: Vim makes a great point in that just delivering through code and a good culture isn’t enough as this misses how that delivery affects users. Especially if the system has biases built in unintentionally. She says we need communications as well. Communication to be able to link together all the parts of the culture of the organisation, systems, processes and people + the code can help us deliver the right things.
For tester: Testers help raise the awareness of quality within systems, but for them to be able to do that affectively they need to take into account the team, the business and users as well. The key skill to be able to do this is communication and helping to link together all the parts to understand the other. This is not to say that testers are the key to culture but on a smaller team scale they can have huge influence over what direction that culture moves in. Do the teams care about how their systems affect users or wait to see what happens?
