But.... Where do I start?

I have been with a few teams now and I was reflecting on how I deal with each transition. I also paused to think how the teams I work with feel too, given we are both in a new unfamiliar situation.

So what have I learned?

1) Pause and think about where your team has been (and what they have seen)

Joining a new team, I am always interested in what they are doing. I think we should be more interested why they are doing it.

We often use the word journey and that's what I'm interested in more than the outcome. If we take time to understand how the team got to where they are, we can often understand more about what drives them, what scares them and how we might be able to help.

One team had a whole load of history which resulted in some seemingly odd behaviors. It all made sense once you understood their journey. This cannot be told by any single person - I heard several versions from several people and somewhere in there was what really happened.

Being sensitive to what the team has been through has been a key learning point for me. It has helped me tailor my own behaviors, language and coaching to get better results from the groups and individuals I work with.

2) Assume the best at all times, especially about people

Despite everything I can see and observe, I have to assume that people are doing the best they can, given the situation they are in and what they know. This is liberally taken from the Prime Directive, which is often used as a kick off to retrospectives.

To me, this applies at all times. It should be our go to place, even with people and teams we have only just started working with.

In one interview, we were doing an exercise where we show a board and ask the candidate what they can see and what questions they would ask of the team. There was an obvious issue where the same avatar was on 3 cards in the development column. The candidate went to great pains to say what the developer is doing wrong and it was not helping other problems they could see on the board.

They never once thought about why the person was doing that and that maybe they are doing things for the right reasons, given their own situation.

What if they were a contractor who was really worried about their renewal and wanted to show how productive they were? What if they had to pick up extra work because someone was on holiday and their stories had not been completed? What if the person really was working on these 3 things by putting in a load of extra hours because they were trying not to let their team down?

3) Make it all visible. Even if it doesn't look good.

At first things often look OK. It's only with transparency do we start to see the problems. Issues are often hidden away and need a bit of coaxing out so we can see the causes.

This takes some guts as people might not like what they see. It is the start of how we adapt ourselves and our processes - without being able to see the problem, you cannot start to fix it.

Transparency not only shows this to the team but also to the world outside the team. This is both a blessing and curse since you may have to deal with attention that you would prefer not to have. In my experience, the benefits definitely outweigh the problems.

4) It not about 'the' process it's about 'a' process

I like scrum. I also like kanban. Some teams need one, some teams need the other. Some teams need something else. Sometimes we need to start with 'something' so we can start to own it.

If a process is intended to evolve, when does it cease to be what it started out as? What makes Scrum, Scrum or Kanban, Kanban? If we embrace being able to adapt, our process will change as we solve problems and find new ones.

The right process is the one that helps the team build software in the best way for them. Often this is dealing with the situation they are in and the problems they face internally as well as externally. It changes over time as our situation changes.

Key to this is encouraging the team to own the process, to be invested in it. For me, a sign of a mature team is owning actions from retrospectives with the same responsibility as they have for building quality software. They are invested in both equally because combined they allow them to achieve their goal. This is built slowly over time with enthusiasm, retrospectives and responsibility.

Resist the urge to replace what the team have. Work with what you have and remember point 1.

5) Give the gift of consistency

In my experience, most things have already been tried by teams who have been around for a while.

Just because something did not work in the past does not mean it will never work. It might be that the time was not right. It is more likely it was not given a chance.

The difference between trying something and using something is consistency. You need to consistently do something for a while until it becomes habit.

These can look like rules and my goal is that these are owned by the team not mandated by myself. You know they have become habits when individuals would defend them if they were taken away.

Being consistent about applying something new is the enabler that allows this to happen. I was pretty terrible at this but I have seen the benefits of being rigorous in applying something new, so I had to learn how to do it. You know you are getting somewhere when others uphold the consistency too.

All worship Board God

The use of boards by teams is nothing new, every team I work with has some way of visualising their work. Many teams seem to stall at changing the board, leaving ownership to some individual (maybe the ScrumMaster or the most vocal member of the group).

This is a shame. Since the board mirrors the teams process, which is owned by the team.

I was in a situation where the board was being dictated by a single person and the team looked too scared to change it. People would compain about the board by not try to do anything about it.

In a moment of frustration, I thought "Fine, you fix it".

Enter the 'Board God'.

If anyone ventures a strong opinion on the board you can appoint them as 'Board God' for a week.

The Board God can do anything to the board they like and the team have to follow their direction for that week. At the end of the week, the team decides what they will keep and what they will reject. Stripped of his or her powers the Board God must accept their decision.

If I hear someone grumbling about something on the board, I usually appoint them 'Board God' to see how they will solve the problem they are grumbling about. Eventually, people will start to ask if they can be 'Board God' to address a specific issue that they can see.

This can trigger a spate of change, where different 'Board God's' mess with each others changes. This is a positive thing since people are getting involved with the board and ultimately the process itself.

Teams that have learned to embrace changing the board often evolve their process outside of the retrospective, shortening feedback to days or even hours.

When used in conjunction with scoring stand-ups, a team can inspect and adapt quickly. I have seen stand ups of 20+ people go from train wreck to useful in under a week using peer feedback. A score of 3 or under means you have to share what was wrong for you and the team agree corrective actions for the next day there and then.

'Board Gods' provide a solution to a problem that is then inspected by the team. The process adapts to the use the good bits and things that do not work are discarded in a safe to fail way. One team I worked with even versioned their board to help them understand when a lasting change was implemented.

This idea started as a punishment but has turned out to be a useful tool to remind teams who owns the process and encourage them to get involved in shaping it.