Friday, 10 November 2017

Can you really manage people?

My wife says I get hung up on words a little too much, which is probably true. She often tells me I am reading too much into the word itself and forgetting what it really means.

Of all the words I hear every day, 'management' is high up on my list of words I don't like. This is speaking as a line 'manager', with line 'management' qualifications who 'manages' stuff as well as people.

Here's how I found a happy place for my 'management' responsibilities.

I like to swap things around. So here's a simple test - has anyone,ever come up to you and said "Manage me"? How about "Please manage me?"

No? Doesn't that seem a little weird. If it was something that people wanted or needed don't you think they would ask for it?

Whilst the settings on my computer might need management I think that people do not.

How about the following:

* Help me
* Teach me
* Guide me
* Coach me
* Listen to me

My wife would argue that the word 'management' really symbolises these things, the word itself is not important. And she is probably right (as always).

Wednesday, 25 October 2017

Do yo' Dojo?

One of the major bits of my personal development has been through coaching dojo's, which were first run by Helen Meek from RippleRock.

Taken from martial arts a dojo is a place for practice. How we use them is not much different - it is where we practice coaching.

Just like a real dojo a coaching dojo is a special place and it needs to be cared for. In a coaching dojo:

* We create a safe space - nothing is judged, nothing is shared with others
* We are all learning and mistakes are inevitable
* We turn up on time!

The setup works best with one host and 3 participants, 2 is OK as well. 1 hour sessions work well, you can expect to be pretty tired at the end of one!

We often focus a session on a particular coaching method. Starting with GROW feels right and is a simple method for people to understand and use for the first time. We usually include an intro for first timers to help them understand what coaching is and is not - discussing the difference between coaching, teaching and mentoring often helps people understand.

Through multiple sessions, once people have enough practice in one method you can then introduce more: SARA, OSCAR, CIGAR, 5 Whys etc.

We ask people to come with a problem. Ideally this will be current and real, something you need help with. Alternatively, you can go back to a situation you have already been through and maybe had some sort of resolution to. The key thing is that it is real for you. You can role play but it is just not the same, you are welcome to have your own opinion.

In a timebox of your choosing (7 - 10 mins) you have a coaching session. Someone volunteers to be the coachee (the one with the problem) and someone to be the coach. Everyone else is an observer, writing notes is a great idea allowing you to play back your observations in sequence. It is important to feedback both good AND bad since both perspectives are required. Suggestions are always welcome.

You allow the coach to complete their session and then the host gathers feedback. We ask the coachee for their perspective as well as the coach and the observers, including the hosts. It is somewhere in these perspectives that you learn what works and where you can improve.

Swap the roles round and repeat as many times as you can in your session.

In running these sessions, we have found there is no one type of person who benefits - everyone who has attended these sessions has found them useful irrespective of role. There is a lot that can be said about people taking the time to learn how to listen and ask 'powerful' questions....

For me personally, I have a tendency to solutionise. This led to me asking closed questions very frequently which is not helpful for the coachee. I was also pretty terrible as listening, often steering a conversation to where I wanted it to go rather than where the coachee needed it to go. Had I done this with a 'real' person I fear I would have done more harm than good.

True Story: In an effort to show me how many closed questions I was asking, Helen once simply responded 'no' to each one. It was brutal. Having said 'no' for most of the session, it was pretty obvious what I needed to improve. It was only through coaching sessions did this happen even though I had read several books and been to several meetups about coaching.

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

Dre-status!

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.