How We Built Testability with Psychological Safety [External post]

Ben Linders recently interviewed me for my talk at AgileTD on how we failed at testability. That resulted in this InfoQ post about how to build in testability you need developers and testers to collaborate. But to be able to do that, you need psychological safety  

Testability can enable teams to make changes to their code bases without requiring extensive regression testing. To build testability, team members must collaborate and leverage each other’s unique skills. Unfortunately, effective collaboration does not come naturally to people and therefore needs leadership to nurture people’s ability to speak up and share their knowledge. 

To continue reading, head over to https://www.infoq.com/articles/testability-psychological-safety/

13 things I’ve learned from running remote workshops

Over the last 12-18 months I’ve been running a lot of remote workshops and during that time I’ve learned a few valuable lessons along the way. Most of my experience is based on translating and running an in-person workshop to a remote online workshop. The in-person workshop I’ve run 4-5 times and the online workshop I’ve run 8-10 times. The nature of the workshop is to help a team collaboratively create a model of how they work and then use that model to improve their ways of working. So it requires a lot of participation from every team member to be successful. What was my measure of a successful workshop? One that results in a visual model that everyone in the team agrees is how they work. 

With that in mind, this is what I have learned from running remote workshops that require group participation. 

1. Practice your setup if using screen sharing with slides and other apps 

Always check that what you plan to screen share works with your video call tool of choice. I’ve found that it never quite works the way you think so it’s always worth checking out beforehand. I’ve noticed that different apps can behave differently when screen sharing in full screen mode so a dry run of exactly what you plan to do can help iron out some of these issues. I’ve also noticed if you’re switching between apps e.g. Miro and Powerpoint then check that things switch back correctly as sometimes they don’t always switch the way you expect it to. I’ve also started to check with the audience that they can see what I want them to as there have been too many times I thought I was sharing and wasn’t.

2. You need to do more up front planning for remote workshops 

You have to plan for any workshop but with remote workshops, you need to plan for every eventuality.

With in-person workshops, you can experiment with ideas on the fly but this is trickier when people are remote. The main issue is communication. With in-person workshops, it’s really easy to tell everyone what you want them to do and then get almost instant feedback on whether or not they’ve understood it. But when people are remote you can’t see the feedback as easily so often you have to wait for the output and judge from that which can be harder if attendees are in breakout rooms.

3. Factor in extra time for tools

Online sessions typically require digital tools which if the group is unfamiliar with will have a learning curve which eats into your workshop time. But with in-person workshops you tend to use pens and paper which everyone understands how to use and if there are any difficulties in using the tools you can physically see what’s going on and intervene. Unfortunately I’ve found that with remote sessions it may not become apparent that something isn’t quite right until the results of the task can be seen. I’ve started to add 5 minutes of buffer to any group activity as it normally takes them that long to get going on most occasions.

4. Remote workshops can be more democratic and can give everyone a voice 

Remote workshops tend to level the playing field and physical presence becomes less of an issue. It can also be more democratic in giving everyone a voice if tool based signalling is used to indicate you want to say something. In some cases I’ve found using chat features can help some to share their thoughts or approach hard to discuss subjects too. But all these features can take longer so make sure you factor this into the session.  

5. Breakout out rooms of 3 are best

I found that limiting breakout rooms to 3 participants works best. The lines of communication are simpler, people contribute more and the overall result tends to be better. With groups of  4 or more, you start to see the dominant members taking over and the quieter ones sitting back. But in groups of 3, this doesn’t happen anywhere near as much.

6. Remote sessions need more breaks

I’ve seen participants during in-person workshops, while not ideal, quite easily contribute to 2-hour workshops, have a 10-minute break and go again. But for remote sessions, most people need a break almost every 50 minutes to be able to participate in half-day or whole-day workshops.

One of the main reasons being reported is fatigue. My guess is that in-person sessions do not cognitively overload the participants as you can use a lot more of your senses to understand what is going on and move about the room. But with remote sessions all you have is sound and a small field of view. So you have to listen more intently to what people are saying and generally stay seated/standing (if you have the option). Therefore giving people regular breaks gives their eyes and ears a rest.

One thing I would also suggest is encouraging the participants to step away from their screens during this time. I’ve found that some take the time to catch up on emails/notifications instead and then feedback that the workshop was too long.

7. Ice breakers are a really good idea 

I’ve found on occasions that people have come in from back-to-back meetings so it can take them some time to get into the workshop. Ice breakers can help participants to break out of whatever they were doing before and quickly and easily get into the new workshop/meeting.  It’s a bit like warming up before you get into your gym session.

They can also double up as a way to introduce people to a new tool via a simple game, get them thinking creatively or a way for people to connect before getting into the main session. I’ve found that while it does eat into the beginning of your workshop it can result in a better overall outcome for you and your participants. So where you can I highly recommend doing it.

8. Sessions never start on time 

It doesn’t seem to matter what time the meeting starts, I’ve played with 5 past, 10 past and even 15 minutes past. Some people still arrive 5 minutes after the allotted start time. It’s never many people but some people just have more meetings going on than others and it can be hard to get a comfort break in sometimes.  On the other hand you get some people who show up on time everytime. So it’s worth considering what will people do that show up on time and how will you get the stragglers up-to-speed?

Now you can ask the early arrivals to chat ideally or make themselves a drink but I’ve always felt like you’re punishing them for being on time. Which unintentionally sends the message that it’s ok to be late too. Ice breakers can be a good fit here as it gives the early arrivers something useful to do and if it’s a good ice breaker the late arrivers might just feel they missed out on something so they might try and be on time in the future.  It also means they are less likely to disrupt the main session trying to get up to speed.

9. Remote session can take longer 

Now, this may vary from workshop to workshop but from my experience, the modelling sessions I’ve been running have taken nearly 2-3 times as long. I think this comes down to a lot of different factors such as the participants’ familiarity with each other, tools being used, the outcome you’re trying to obtain and more breaks. So being able to test out a workshop is a good idea to figure out your timings and if it will need multiple sessions.

10. People are not paying as much attention as you might like

I tend to find that I end up repeating instructions during workshops quite a few times so keeping them simple and available in multiple formats can make this easier.

This goes for in-person workshops too but any instructions, objectives (if critical) and information (if complex or new to the participants) should be verbally and visually represented during workshops.  I’ve also found making it easy for participants to find for themselves can be handy too.

11. Don’t expect people to follow your instruction to the letter 

Just because you said use a felt tip pen they might use a biro.  Just because you said to use plain paper they might use lined.  Just because you offered to send them the resources don’t expect them to say yes to them.  Always think about how people could interpret your instructions. What might be significant to you may just seem incidental to them. In this way, in-person workshops are easier as you can give them everything they need and tweak instructions as you see things happening.  So if some requirement for your workshop is important and an equivalent  can not be used, make sure they know this upfront otherwise you might get some unexpected results.

12. You’d be surprised at what a pain it can be to take a photo and upload it 

For my workshops I thought that doing some drawings, taking a photo and uploading it to Miro would be quite easy but in general, it causes quite a few issues. Most people’s photos are taken at quite a high resolution and not everyone is familiar with how to lower it. So when they do upload them they can take a little time and being quite large means they almost always need to be resized – taking more time. Getting the images onto your PC can be tricky too as there are quite a few ways to do this and I was surprised how few people knew how to do it. While none of the issues are a major problem when you have enough people experiencing different issues at different times, the easy job of uploading a photo becomes a real time drain. I’m sure this will get easier with time and/or using dedicated apps but be sure to factor this in if you want people to upload images.

13. Always summarise what people have been doing and why 

I have always underestimated how often it’s worth repeating the aims of a workshop to the participants. Just because they have accepted the meeting invite and you have personally explained it to them it doesn’t mean they will remember why they are doing what they are doing.  One of the things that I’ve regularly gotten in feedback is people not being sure what the outcome of the workshop is.

I think this is because most workshops are completely new to attendees so they are taking on board a lot of new information. So they tend to miss the details and instead focus on the current task. What they tend to remember is the beginning, any significant events during and the end of the session. Also significant events might not be what you want them to remember as it could be someone making a joke or how a tool failed. So make the best of the start and end if you want them to take something away from your sessions.  

Which is best, remote or in-person? 

From my experience, I’ve found that both have their strengths and weaknesses. Remote sessions can allow people from anywhere to participate and usually involve digital tools which means the outputs are much easier to share and reuse. But the downside is you lose that person-to-person connection and the energy that comes from that. They can also take much longer and may need to be split up over multiple workshops depending on the type you are running.

In-person workshops on the other hand can be much more dynamic. By allowing you to change things on the fly, have a lot more energy which can be motivating and keep people engaged in the session for much longer. I also find they can become a bit of an event especially since we’ve all been working remotely which could work towards helping people engage in the process.  However, they can favour the more confident participants and making the outputs sharable and reusable can be tricker.

So which is best? Well, it depends on your context. If getting together is difficult then remote might be best for you but if the team is still new or you’re experimenting with an idea then an in-person session might be better.  I still prefer in-person workshops as I find that the social element of getting people together and working on something as a group still produces better ideas, faster and in my opinion builds stronger and longer-lasting bonds between people. Which all contribute toward a more cohesive team. 

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?

The difference between leaders and managers

3 minute read

Tl;dr: Hybrid Leader-managers could be one of the keys to successful software teams but first you need to understand the difference between the two. 

A higher quality version of the model can be found on my Miro board.

The default style for most leadership within the software teams is towards a management style which caters for managing complexity through process and routines.  But by understanding the differences between management and leadership we can better create hybrid leader-managers. This approach is beneficial for software teams as the work they do can at time be highly complex. 

Complex work can be described as work that has an uncertain outcome due to the many variables that can affect it. These variables can be known or unknown either before, during and after the work is completed.

Leader-managers styles are best suited for leads that work closely to where the work is happening as the hybrid model takes into account that some work is routine, and therefore a management style is suitable and some work is innovative and therefore leadership approach is more appropriate. The further up the hierarchy you go the more a leadership style is suited as this enables the organisation to better handle change. 

Being able to adapt to change is a now a feature of almost all software teams and ones that a better equipped to adapt to it are more likely to succeed on more dimensions of success other than just delivering what the users want. Successful dimensions could be sustainable team performance, team member satisfaction and delivering end user value consistently. 

What does this model illustrate? 

Based on a HBR article what do leaders really do by John P. Kotter it shows that management is about reducing complexity through standardisation and making work efficient. This heads organisations towards certainty. Leadership on the other hand is all about creating change within the organisations and embracing the complexity that exists. They do this through communication and motivating the organisation towards that change.

Management

On the left are the management styles for handling complexity within organisations through three distinct approaches. Managers communicate what needs to be done through planning and budgeting. Create networks of people and relationships to do the work by hiring and organising them. Finally making sure the work happens by managing complexity and solving problems.

Leadership

On the right are the leadership approaches for creating change within organisations. Leaders communicate what needs to be done by setting the direction the organisation is heading in and letting the employees figure out how they get there. They create networks of people and relationships to do the work not by telling them to collaborate but by aligning them through that direction. Leaders make sure that the work happens by motivating those people to solve problems for themselves instead of handing them solutions.

Which is better?

As is clear from the model management and leadership do have their differences but it’s not about one approach being better than the other but that they are complementary to each other. It is almost like they balance each other from the extremes of just following one approach.

Do you see a difference between management and leadership?

How have you been led or managed in the past?

Does this model change your approach to leadership and management?

Let me know in the comment below