Are we actually managing bias?

 I have worked with a fair number of awesome developers. I was always stuck by how they had a deep understanding of not only what they did but the business area they worked in. They often saw things that others didn't due to that unique perspective - which you only get when you are 'in the weeds'.

With the tendency to strip things down, it would make sense that the ultimate outcome would be developers performing all the 'support' roles too - which would give them full autonomy on what they build and how.

And yet, this is not the norm. Or even fashionable.

This has been written about for decades and is a core part of Extreme Programming where the developers are customer facing and take on whatever role they need to create software be that as BA, QA, UX or UI developer or whatever acronym is currently popular.

When I think about each of those roles, I actually think of the bias they have. Each has a strong lean, which is core to that role - business analysts do lean more to business requirements and process, QA lean towards software that can be verified as working etc.

When I think about all those roles being covered by one person I realise that it's not fair. 

It's not that a person can't do that but asking someone to balance all those areas and apply bias fairly or consistently is not something that we should ask from people. It can only lead to internal conflict, which we might not see or be aware of.

So yes, it's a pain to have those discussions with people. It's difficult and time consuming to find a compromise between the different members of your team, all of whom have excellent points and competing contexts.

But it's probably better that all that is out in the open. That we realise that our bias for our context is valuable in that discussion. 

It might not feel like it but by having those roles, we are actually managing the biases that compete when we create software that people love to use. No right, no wrong just perspectives that need to be balanced.

Asking person to do that is unfair - only a team of people who respect each others perspective and value the context it brings to our own can figure that out. Somehow.  

Vote with your fists

If there was a single tool I use more than any other with teams it is Fist of Five voting.

If a session with a team does not feel right, at the end I ask the group to provide some feedback. I create a scale from 1 (or 0 if you like) to 5 and give a description for the highest and lowest. I make these up every time, something like "Where 1 is 'please never ask me to do this again' and 5 is 'can we do this every day, it was so much fun'" seems to work well.

You can vary the description to fit what you are looking for. You could choose to describe the scale in terms of effectiveness or return on investment, for example.

Every one then gives a score using their fingers, allowing us to get some insight what people are thinking.

I follow up by asking anyone with a score of 3 or less to suggest one thing we can change that would improve their score. As a group, we quickly decide which ones we will try and then we call the meeting to a close.

This is such a simple mechanism but it works for a couple of reasons:

* The feedback we get from the group is at the same time as the problem they observed, making it easier to act on
* Changes are often small so they are easier to implement in the next meeting
* We encourage group ownership of our ceremonies and meetings which helps people engage and take responsibility for their success

An obvious place to try to this is in you standup. If it feels wrong, this would well get some instant feedback that you can put into practice the next day.

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.

The important features of a great team

There is a game we play at home that I would like to share.

The rules are simple:

Given you are alone in a dark room or corridor
When you hear someone else approaching
Then you have try jump out at them
  And scare the c**p out of them

There is some skill to this game. Once you have played it a few times everyone knows what is going to happen. In anticipation, everyone goes very silent in order to detect where the other one is. Inevitably, people stop breathing but start laughing - first one who does has lost.

None of the kids play this game. This is something myself and Mrs A do, which is most unbecoming of some 40 year olds.

It is something that is uniquely ours. Something that does not really make sense in another context. It is special to us but probably completely dumb to others. It was not planned but was spontaneous and if it was copied would not be the same.

But this is where the good stuff is.

Teams also have these special bits too. They come from working closely with each other and letting your guard down enough to reveal our human selves.

This does not happen immediately. I often does not happen if there conditions are not right, if there is not enough freedom to express who we are and explore our relationships with one another.

Often unprofessional, usually silly and totally unique to each team, these are the special features that make teams great both to work in and with. Love them or loose them.

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.

Why Scrum teams between 3 and 9?

We all read the Scrum Guide but have you ever wondered why the band of sizes that is prescribed?

Recently, I have been working with a large team which was 10 people (8 developers and 2 QA). It was interesting to see the problems that came from this size team so I thought I would jot them down.

Problem 1 - Capacity
If you have a large team, you end up with a large capacity. A 2 week sprint for 10 people means an epic 540 hours (6 hours a day for 9 days, after taking out 1 day for ceremonies). That's a lot of work to prep and get ready! Most sprints we found it difficult to prep enough for a commitment against our full capacity, forcing us to bring more in mid sprint.

Problem 2 - Prep
Having mentioned prep, the larger the team the more difficult it is to get everyone focused. It also has the side effect of you sacrificing over a days development for each hour you prep. This is obviously scaled up, you cannot escape this - but the larger the team, the slower the prep felt which means the losses are amplified. We had an additional problem that our team area was not really big enough for everyone to see the ample 50" screen we used to access our backlog.

Problem 3 - Crowd Control
Prep and retro's were interesting times for the Scrummaster. Getting people focused and keeping them there was challenging. Finding a space which we could work with was a challenge. Prep sessions were either silent or we had too many voices at once, which we needed to work harder to bring everybody under control.

Problem 4 - Visualisation
Large capacity means lots of stories. We found it difficult to visualise the work simply because we could not get it all on the wall. This meant we often had stories 'waiting' to make it to the board. This made if difficult to see the full picture for both the team and the stakeholders.

Problem 5 - Ceremonies
With more people we needed more time for pretty much every ceremony - this ate into our sprint window. With lots of work the planning sessions often turned into epic half day marathons that everyone hated and retro's would take about 50% longer just because it took a bit longer to coordinate the team for each part of the retro.

Problem 6 - Sprint Composition
We had to be more careful about what tasks ended up in a sprint. With so many people, we often ended up with stories that blocked each other since they were in one area that shared code, unit or integration tests. This stopped us from being able to work in parallel on them. One sprint contained only stories for a single component, which caused us a multitude of delays as we tripped over each other repeatedly.

Counter measures we tried:

Split Prep - We did 2 rounds of prep, allowing us to sanity check the requirements and do investigation using the bare minimum of developers, minimising the impact on the team. Our desired outcome from this round of prep was that the developers involved would present the story to the rest of the team, replaying allows the PO to confirm solid understanding. By the time it got to the team we knew it could be done and had any investigation/spikes covered so it was all about spreading understanding of the story.

Timeboxes - when we had the full team at any session we enforced 1hr timeboxes. More than that and people were too fidgety to work with. If we needed longer we broke up for a 15min break to get refreshments and repeated the time box.

Diverge and Merge - in planning we asked the whole team to task out the story. There was obvious duplication but the differences were the interesting bits that leverages the teams different thinking on the problem - some people thought of things that others did not. We then had a game to see who could keep the most stickies on the board. This worked better than allowing one person to drive but was not always liked by the developers. Main benefit is you get everyone engaged.

Two Boards - for a while, we had 2 different boards for different classes of work. This allowed us to visualise everything but also meant we had 2 stand ups. Not going to lie, it was weird.

Two Retro's - we did 2 retro's for the first sprint so we could keep the groups small. Universally hated by everyone we did not do it again. The split was based on the classes of work we used to split the boards BUT people worked across the boards so it was very odd. Not recommended.

Huddles - we often had 2 standups a day to coordinate work. With a larger team, they can burn through tasks quickly when working in parallel on a single story. This meant more coordination that a single stand up was needed. Wasn't a bad lesson to be honest and we do this even now when tasks are not moving or causing problems.

In conclusion, the 9 boundary is probably arrived at from trial and error. We were only 1 person over the 9 but we saw some interesting effects - I would guess team 8 and up might see some of these issues.

We had 2 BA's as well as the PO and myself making the full Scrum team a whopping 14 people at the majority of the ceremonies. Although the Scrum guide only considers the development team, you might was to think a bit broader and how that might effect your ceremonies.

One question I was asked - why not split the team into 2? This team worked on a single product. Splitting the team would have meant extra coordination by the team to make sure that what they were working on was known about by the other team. The team were also concerned about knowledge transfer, which they had worked hard on in the last couple of months leading to much better product knowledge throughout the team - splitting the team could have set back this progress.

My sweet spot seems to be around 6 - large enough to deal with holidays and sickness but small enough to enable knowledge transfer. This also feels about right in all the ceremonies.