Debugging Team Dysfunction - Safety

I recently got told that the cycle of depression goes something like this

1. You feel like you should be doing something
2. Not having done it leads to you having negative thoughts (usually about yourself)
3. So you promise that you will do the thing which may also involve negative thoughts
4. goto 1

The point behind this is that not doing things and also feeling bad about not doing things gets into a cycle that leaves people feeling depressed.

There are probably other ways to get depressed - anyway i am not a psychologist.

To be brutally honest I find people who take biology and to an extend scientific method and then tack ‘and thats why we feel how we do’ onto the end to be suspicious and greatly reductionist.

But some of these ideas make quite a lot of sense - I recently have been reading a lot about Polyvagal theory and feel suspicious about it being a vast oversimplification, but then if it wasn’t it probably wouldn’t fit into a book meant to be read by most humans.

The thing that sort of scares me about it is that I realise that what it is talking about is exactly what I am debugging when looking at teams - collections of people instead of individuals.

Polyvagal talks a lot about freezing, the nothingness that comes when not managing to do something. In polyvagal the idea of freezing is underpinned by a nervous system response that says that the person does not feel safe (nothing to do with actual safety, more an internal autonomic reaction to stimulus that sits below the level of consciousness). So it is fight, flight and freeze.

Its interesting, don’t quote me on it.

Signs of a dysfunctional team

The primary sign for me is that the team is following a process internally that has been defined outside of itself internally.

This is a team that cannot change, and so cannot learn and so cannot improve. I often cannot help this team - i have to go and pick a fight with leadership in these situations. But lets ignore that, and instead focus on insurrection - if you meet a team that has this you can still show them how to change. There are lots of teams that would be allowed to change - but they simply haven’t tried because people are simply too scared of missing their accountabilities to risk their predictability changing (despite it being low). If they are responsible for a change that reduces output then they will be accountable.

It is one thing to have a contract of behavior - we will have artifacts x,y,z.

Its is a very different thing to have ways of working defined by ‘the central process’.

It is a lack of imagination and will to work differently internally, but still look the same externally. Creativity has been shut down - this is a state of fear.

When I join a dysfunctional team I identify it by looking for a few things

1. It won’t have retros - and if it does it will be a complaining fest with people who feel like nothing changes (and in dysfunctional teams they are right). It’s worse often if they used to have retros. Those that do will have same host and same style of retro every time
2. Daily meetings will be a check box exercise and will center around lots of different peoples work rather than a core problem being prioritised and solved.
3. People will be having work assigned to them by somebody else
4. They won’t be releasing code into production at the end of an increment
5. Lots of work in progress - they will be using a burn up chart and a scrum master will be sad
6. Siloed roles with hand offs, PO -> BA -> Dev -> QA -> PO (because this system produces high defect rates)
7. Showacases that don’t involve a demo of actual behavior and a statement of ‘and this will go live tomorrow’
8. Fear of releasing on Friday (usually because it takes hours/weeks/days to release) - good teams will release many times a day

The typical team that is suffering will have at least one of the following - but it is surprising how much this clusters into all of them

• a delivery lead that is trying to run it - their focus will be on stopping engineers analyzing, writing tickets and structuring work to make it easy for them and instead getting engineers to write code like good little monkeys (After all they are paid more because its hard to find good engineers - so best to keep them typing, not thinking). Instead of asking experts how to get somewhere they are telling them to get there
• a product owner (or manager if your org got product owner wrong and now needs to invent a new role as a band aid to wrap the organisational chaos of multiple teams that don’t actually own anything) agreeing to work for the team and committing to things with little input. Instead of bringing people in they have to do the work because everyone is so busy trying to hit a deadline.
• probably some BA’s to write the tickets for the devs, because everyone so busy. This takes their time from going and discovering what the real problems are that nobody has thought about yet - you know, the analysis rather than the paperwork.
• engineers, who are paid the most money but are not allowed to do any analysis of the upcoming work into chunks that make sense for the current state of the code base (That only they know). Engineers in these teams will carry strange beliefs like ‘its ok for someone else to test my code works and find defects or missed requirements’, or that code reviews and squashing commits are desirable things rather than band aids for other problems.
• probably an external QA team who come along once the work is finished and ask ‘So what does this do? I need to write tests for it to see if it works’ - this will be after the showcase to stakeholders when the developer finished, after which it should of gone to prod.

Without Safety the lowest energy state is isolated roles handing work to each other

Nobody likes their time being wasted, nobody likes to do work that is ultimatley a waste. So why so we get into these patterns?

Its almost as if this is a natural state of balance that if we don’t exert energy to keep things organized to a higher state everything regresses into.

There are some organizations who are incredibly proud of this way of working and think they are performing best in class practices - because they have all of the practices.

It often feels like the architecture conversation where an architects defends an architecture by saying ‘It must be good, we used all of the patterns!’

Real Safety leads to high performing teams

Now its massive step to say it is causative. But it is definatley unconditionally required for a high performing team.

In all of these teams there is a massive focus on finishing work - not on building a safe environment. But the waste in these teams is in excess of 90%, the investment into safety and so the teams ability to change itself to improve is well worth the effort.

Everybody is behaving like there is a panic, like its urgent and this puts everybody into a survival mode. It blocks learning, creativity and our ability to work well with each other.

Because of this we end up in a situation where we isolate into hand offs

This then inevitably leads to all of the above set of behaviours.

All because the managers cannot manage to isolate the teams and keep them safe - because they let their fears leak into the teams.

How do you fix this?

Honesty, integrity and courage.

Simply start with a conversation, talk about it. Nobody is happy, that is something everyone can agree on.

Acknowledge that safety is the ability to express a contrary opinion, be listened to and see people change. Challenge that after listening that there should be change, and because there should be change it constrains what we should be talking about to things that we think we can change. Asking people questions and asking them to be honest about things, and then not effecting change is fundementally undermining to the feeling of being heard. It is an acknowledgement that the environment is not in fact safe.

We can easily build small safe exhibitions of this by simply organising little things for teams together, but most importantly by clearly define what is in control and out of control of the team and then starting to plan some small changes inside the team.

EG Why not get the tester to be involved with the developer to define the tests before the developer starts work.

Does this image feel unsafe? It does not to me. This is what safety looks and feels like - it is also what high performing teams look and feel like.

Someone earlier today said the test team used Selenium they didn’t know it. We walked through a trivial example of a page that would be tested. The result is we defined id’s for some fields, we discovered that maybe we needed specifically names classes on others. We discovered that a button might need to be accessed by a screen reader and so needs a test hook for that, we realised that the navigation to the next page might take time - and there is likley an SLA to test for that. Does the next page immediatley load or is it javascript and client side. What was the change in state associated with the command and can it be seen anywhere (yes becuaes its a change for a customer and so must be some feedback)

The result is that the ticket for the page ended up with a whole raft of requirements that had been lost. The QA, the dev and the BA all ended up being involved, and the tickets the BA wrote ended up not being in the sprint, instead a new ticket was written by the developer with the PO and BA bought into it that referenced the other tickets.

Everyone was involved, everyone was happy and in the space of an hour a ticket was written that previously would of taken weeks, the code was written and because it was already tested QA passed straight away.

We saved time on the front, we saved time on the back and we built the right thing with everyone present.

The result is people are suprised and now hopefully, maybe next time will choose to talk to one another earlier next time.

Can’t wait to talk about this in a retro and see what people want to try next time.