Friday, 13 October 2017

Diversity in thinking about Diversity

There has been a lot of talk of diversity in tech. This has been building for a while which is awesome, specifically around women in tech. I can still remember when it was inconceivable that you could be a software engineer without a degree of some kind. Although the movement is glacial, there is movement which is one reason to be cheerful.

I had a pause to think about diversity recently. I have worked in all male teams and there is definitely a different energy. When there is a mix it feels different - it's not something that I can explain but I can recognise it even if I can't explain it.

What I am a little worried about is that thoughts about diversity seem to stop at gender. What about other types of diversity, which we seem blind to?

How about age? How many 50+ do you have in your team or organisation? Given that we will be working into our 70's, what does that say about our industries view on experience? Where do all the 'old' developers go? If you were to band your developers by age, what would that look like? Are we happy with the diversity of ages that we would find?

I am currently working in a team which speak over 10 languages between them. Lots of people have a different cultural background. This is a great bit of diversity to celebrate! Each person has a different way of communicating, thinking about problems and working with people. I can see differences in how people pair, discuss and even get annoyed. We can all learn something from differing ways of interacting with people.

Where I really started to think was when I thought about neurological diversity, covering conditions such as Autism. I think these are currently labelled incorrectly under disability in most organisations.

Neurodiversity helps us understand that people with Autism, who see and experience the world differently to most people, have natural variations in their physical neurology. I don't identify this with disability. By pulling these into the light of diversity, we quickly see problems with our workplaces.

From the outset, neurodiversity is hampered by our recruitment processes. We typically have a process and for most with Autism this would be a big challenge. There has been some fantastic thinking about by Microsoft, which is well worth a look.

Is it 'the' way it should be done? Probably not - but it's represents people thinking about the barriers in place that are stopping a more diverse workplace. There is a beautiful saying that if you have met one person with Autism, you have met one person with Autism... each person is different so no one approach will work universally.

Most of us find interviews stressful, so thinking this same process would be fit for someone with Autism feels very unfair. At worst, could it be purposely shaping our workplace by stopping certain types of people from being able to join our organisations in the first place?

If we make it though that barrier, I think our workplaces are actually quite hostile. We often work under time pressures, in noisy environments which you cannot control and mandate ways of working that some people may find hard or even distressing. For people who are stressed out by the workplace alone, is it fair to add commercial pressures? What does our responsibility as people manager look like in this scenario?

Taking this further, what about career progression? Do our current methods of assessing people for promotions in an organisation work in a workforce which is purposefully neurodiverse? Certainly matrix style assessments could be so explicit that they effectively rule out career progression for certain people, obviously taking us away from a fair employment culture.

So the next time you hear about embracing diversity, maybe ask a few questions about what people think this is and where is stops for your organisation.

Friday, 6 October 2017


If you have the pleasure of working on a big programme of work, which involves many teams you will have probably encountered a status meeting.

For those from the 21st century, this where a collection of people get together on a regular frequency to share their status with the rest of the group. This usually forms some sort of rag ("RED AMBER GREEN") status which is usually in a huge spreadsheet which is usually accompanied by some words to explain why your status is not green.

If you cannot get rid of this then how about changing the way we deliver the news.

My favourite so far is by dressing in the colour of your status, so you proudly show everyone as soon as you enter the room.

The person asking for this will be able to focus immediately in people wearing red, forget about people wearing green and selectively pick on the more nervous looking oranges.

Who knows, if you all end up wearing green the encounter might only last for minutes freeing the meeting space for less fortunate souls.

Friday, 29 September 2017

Bulk Estimation at Speed

So, today I faced a new problem. The forecasting I have been using for a while has been throwing out some dates that 'feel' very pessimistic. I want to trust them but they look wrong so I find myself with a dilemma of how to test the forecast in a sensible way.

A previous observation was that whilst asking people how big something is gives a wide range of results whilst asking them if something can be done in a set amount of time is easier to answer and is just as easy to use and interpret as a number.

So given I have a backlog of about 50 things I need to test, I welded these 2 things together and came up with the following session that I ran with my own team.

The only prep you need to do for this is to prepare 2 question cards. The first question is based on the ideal time it should take to do a story. At time of writing, my team want every story to be 5 days or less. So the first question card would be "Will it take 5 days or less?". The second question card, is the opposite extreme of that. So for us, it has gone terribly wrong if it will take 2 or more sprints which is what we have on the second card.

There should be a gap between these which is your middle ground. The observant among you will realise these options look like T-Shirt sizes - which they are! We don't ask that question - we ask is it bigger than X or larger than Y giving a wide difference. If it neither then it must be in the middle ground.

So here's how we ran the session:
Print out your backlog with title and maybe a narrative (as a... I want... so that)
Stack them in the same order as your backlog, highest priority first
Grab a selection of developers and include some QA
Put the question cards and middle ground card on the table
For each card and ask the questions
Expect discussion but keep it short:
* Encourage listing assumptions if that would make it easier to answer, document these if you can
* Re-iterate the ranges using days ("So if you started on Monday, it would be finished by Friday")
* Use comparisons ("Remember that piece of work on X that took 2 sprints, is it as difficult as that?")
* Watch out for unknowns which drive up estimates, mark these for later investigation/refinement
* Use timeboxing if you think it makes sense
Stack the card on the relevant answer card

I was quite surprised as how fast my team did this - 52 stories in 1hr. We can then visualise the backlog in order and colour code the cards to show us the sizes from the team. You would expect first stories to be all green and then progressively turn orange then red as we head further way from the top of the backlog.

That's not what we found. 

We found a mix across the backlog that we needed to verify. We discovered that this showed what the team did not have a good understanding of, allowing us to focus our time on refining the cards that were big because we were scared or confused by them.

As far as validating the forecasting, we could now model a series of sprints based on how long they might take which looks a little like a gant chart but is throw away so I will allow it. More importantly it allowed us to see how we might reduce some of the risk in our delivery but tackling the unknowns upfront and ensuring we only develop the smallest stories we can, which are far more predictable.

More importantly, the team found this useful as a confirmation of what we would be doing and in what order allowing them to spot things that had been overlooked. They did this by telling a story of what the system would look like as they developed each story. 

They checked the system by also finding places where a demo would make sense and the system would provide end to end functionality that could be seen and understood by stakeholders. We found having a system diagram very useful in this as the developers can point to what they are talking about and everyone understands the context.

They even asked if they could do it again, which is surely the sign of good times :)

Friday, 26 May 2017

The Non-Verbal Stand Up

I wondered what would happen if we limited the conversation and turned it around - so you were asked for information rather than giving what you thought people wanted. So let's add a simple constraint:

"When we are talking about your story, you are not allowed to speak but people can ask you questions. You can respond in anyway you wish as long as it does not involve words being spoken or written"

You should observe some interesting things:

  • People often don't know where to start because they are used to justifying what they did yesterday, which is really hard to do if you cannot speak
  • People tend to start using really complex hand gestures until they realise nobody can understand what they are trying to say
  • The team might try to play sherades to get the same level of detail from speaking only to discover it takes way too long!
  • People's questions need to be really simple so they can be answered non-verbally
  • Focus will be wholly on the person when they are responding - if you are not concentrating, you won't know what they are trying to tell you
  • The same questions tend to pop-up from people for each story - could these been the most important things we need to know?

Questions you might like to ask the team:

How did it feel not being able to talk about your story?
What did people want to know from you?
Were any of the questions surprising?
Did we get the all the information we needed as a team, even though we could not talk?
Did it take more or less time than usual?

Monday, 24 April 2017

Agile with Mum: Vertical Slice

Mum, sorry to say that you have been cleaning your house all wrong. Let me explain what we have learnt when we develop software....

Most people (you included) will set about tidying a room at a time, often starting with the wrong rooms. The problem is that if someone turns up before you have finished the rooms they will go into, it just looks like you have a untidy house.

Further than that, what are they coming around for? Very few people will come around that will need to go into every room in your house.

If they are just coming for afternoon tea, what will they experience in your house? Probably the hall, one other room, maybe the kitchen and possibly the bathroom. They will probably not open cupboards or closets but will definitely come into contact with a tea cup, sugar, milk (I know you go all out with your tea set) and a plate for biscuits.

If I were strapped for time, I could combine this with Story Mapping to reveal what the minimum amount of tidying might be. If you are short of time, this allows you to focus your efforts on what is absolutely required.

Since we know the customer is going to require tea, we sort that out first. We make sure it's all clean and we have all the ingredients for tea (don't know about you but we always seem to be low on milk). Since this is the focus of the visit, it's the most important part of your guests visit. You can always cover, with "Sooo sorry about the mess, the grand kids have just left...." or similar if they arrive early and you have not finished the cleaning.

Next we nail the basics - put away stuff that makes the place look untidy. Yes, this may include moving Dad to another room but the key thing here is not by room but for only the rooms that our customer will need to access. You start from where your guest comes into the house and clean back to where they will spend most of their time, focusing on the what they will do.

Next, we could start to clean the floors, again following the guests movements. We might notice that some things don't quite look right and we just sort those things right away. If they only take few seconds then it's worth doing there and then - we always try to leave a space better than we found it, as long as it makes our guests experience better.

Once you have your basic tea time experience nailed, you can think about those other rooms.

This focused way of thinking is what we would call a vertical slice. At any point, once I complete everything for a vertical slice I an review what is left and decide if I need to do the others or if what I have is good enough.

Tuesday, 11 April 2017

Experiments with Emergent Leadership

My self and a colleague recently attended Tobias Mayer's Emergent Agile Leadership workshop. Part of the corporate sponsorship deal we have at my current place is that when you come back you share your notes or what you learned.

I added the acceptance criteria that whatever we did should be something interactive with the community we have, since I think note taking is subjective and nobody really understands the context. That and I hate writing notes - I am terrible at multitasking!

Then we went on the course and realised what an enormous challenge we had set ourselves. Tobias guided us through 2 days of very thought provoking discussion, mixed with some games and interactive exercises. At the end, he left us with this closer:

What is your intent on leaving here? This workshop has supplied no formula, no model, no process.

The workshop was a journey of discovery. Not something that you can shrink wrap. It was something that you can only experience. Leaving us with a lot of head scratching to do - how do we introduce some of these ideas to our community? How do we get 2 days worth of thinking into an hour?!

We started to think about how we could re-create elements of this. We wanted to create a little discomfort and we wanted people to engage in deep discussion, which was something we realised we did very little of but got a lot out of.

I also wanted a bit of quirk! So, here is what we did.

We came up with a game. In separate teams they all had to cross a river (one side of the room to the other) using only the stepping stones (a3 pieces of paper). The goal is to get everyone across, racing the other teams. There are rules but they have to uncover them. A judge will let them know when they have broken a rule - the whole team has to start over if that happens.

"Maybe, we all need to be on a stone at the same time?"
The judges are told the rules away from the group. There's actually only one - don't let them all cross! Essentially, they randomly get the team to start again. I know it's cruel.

This is to cause the team to communicate and experiment. We suspected people would jump forward into a leadership role and some would follow. We also wondered if the leadership role would be with a single person or would move through the group as they fail miserably to complete the task. Would leaders step back when others stepped forward? Would the leader help at all?

At the end of the game we asked everyone to point to who they thought was the leader. We then separated the leaders and asked them:

Were you aware you were the leader?
Why do you think people saw you as the leader?
Were you trying to lead?

The others, we separated into groups and asked them these questions:

Why did you see them as the leader?
Did you choose them or did they step forward?
Was there more than one leader? How did they share?

We then explored some of the themes from the groups. We noticed that in some groups there was no dominant leader - so it was emergent and moved around. This allowed us to explore leadership as an energy that anybody can bring on demand. We also talked about how participation is a central part of being a good citizen.

We then re-created a discussion session from the workshop, using Tobias' own content so they had the opportunity to explore and think about a specific theme. We finished up with asking the community how they would like to proceed and if they would like to explore some of the ideas a little more deeply.

Although this cannot replace the workshop we went on, we think it did get people thinking a little differently about leadership in their own teams. Many thanks to Tobias for helping us 'see it' a little more clearly.

Tuesday, 14 March 2017

Bad Story Spotting

Today, I was having a chat with a few others. It was long and rambling but the conclusion was kind of nice. We realised that every single issue we were talking about really started with how we prepare our stories. We often have bad stories that make it through and then we have to deal with the problems in the sprint, which is terrible for everyone concerned.

So we came up with 3 ways of spotting a bad story rather than trying to decide what a good one would look like. All have to pass for this to be a story that we should do. The vision was that the team can 'test' a story before allowing it to be worked on ensuring the team have the final call on responsibility.

1) Does it have any assumptions or risks?

No.... none? Don't believe it. It would be a truly exceptional story that has neither of these. If there are no risks then I would bet that this is either too small or there is no value in the story. Neither are good. The most common reason is that we simply didn't think or come up with any, which is not the same as there not being any.

If there are some assumptions and risks then we should find out if we are happy with them. Can we mitigate the risks we have identified? Are there any experiments we can run to find out some more? Are the risks worth it and we are happy with the trade off (which will probably be longer delivery time)?

Spotting assumptions in a discussion is actually very easy - "Well, IF we did this...", "What about..." or the clanger "Assuming....". Stop, ask for it to be a sentence and write it down!

Risks require a little more effort. We have some questions we can asks "What is likely to take the longest?", "What have we not done before?", "What is only known by a few members of the team?". Using Liz Keogh's scale for estimating complexity is a nice tool too which should help you uncover the risks of key parts of a story.

2) Do we all see the same thing?

I was introduced to a great game in a workshop with Tobias Mayer. You create a character by each person in your group adding one feature at a time. When you can no longer 'see' the character, the next person has to explain how the character makes sense to them - this is to help you see it.

At the start of your story or during planning, you can call out what you need to do for a story in order one person at a time. If anyone does not see the same thing you can challenge by saying that you cannot 'see it', allowing you to spot if things are missing. When we cannot think of anything else to add, we can check that we all 'see it' and move on.

You can also do this using diverge and merge if you task out stories. This where everyone creates tasks and then we merge these together to see where we agree or have different ideas. Both are valuable - similarities suggest something we should definitely do whilst singular tasks merit conversation since we might have missed something.

If we don't see the same thing, we need to spend a bit more time making sure we do. Doing this with the people who will actually develop the story is absolutely required. Extra points if you are using the 3 Amigo's for this conversation.

3) Will this take longer than...

Yes, estimates suck. This isn't quite that. You pick a line in the sand and you decide that stories should not take longer. This is your stories delivered and everything that entails. For my team, at time of writing we are trying to get everything into production in 5 days or less. We are miles off but that is our line in the sand.

To reach the hallowed land, our stories need to be smaller and the line in the sand helps us recognise stories that do not fit the goal.

You need to take constraints into account. We know our path to live is not a super smooth highway so we take that into account and ask, "Will I be done with development in 3 days?". If not, then we need to break this story down, it is too big.

You can also use the awesome "No busllsh*t" cards from Lunar Logic, which approaches this from a different angle.