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).

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.

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.

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.

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

Scoring a story whilst telling the story

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 :)

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?

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.

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.

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.

Agile with Mum: MVP

Working with a range of people, you end up with a growing list of things you steal. One of my favourites is from Helen Meek who often asks people to think of explaining to their Mum. So if we are saying we want a 'simple' interface, we might think of our Mum using it. This means no long words, no technology, no three letter acronymns - you get the picture.

Just recently, I was trying to get across the thinking behind an MVP and eventually imagined this metaphor which I thought I would share. This also covers the basics of Story Mapping and I hope it can be explained in under 5 minutes.

Imagine we are planning our ultimate holiday. This is our once in a lifetime, no expense spared, lifetime-memory-creating sort of holiday. This is important and very expensive and you have decided to plan this a little so that everything goes according to plan and gives you the best possible experience.

You realise there are certain stages to making sure this goes off without a hitch. You start to write them down and you end up with something like this:

Preparation -> Journey Out -> Enjoyment -> Journey Back

Each of these are not just one thing, they are each a series of things you need to do. So you start to list them out. Some of these are really important and some are not - this is the ultimate holiday so you want to remember everything that will make it awesome. We want to remember and think about all the little details.

You write your list of things and then order them so that the most important are at the top and the least important are at the bottom:

Preparation
Check Visa Requirements
Tell neighbours and give spare key
Change Money
Stock up on sun tan lotion
Buy beach books
Buy new swimsuit

Journey Out
Turn off heating
Remember Passport!
Remember Wallet!
Book Taxi
Pack Suitcase
Charge Phone

Enjoyment
Book excursions
Get Trip Advisor Recommendations
Tell Hotel about fish allergy

Journey Back
Book early wake up call for flight
Money for pressies at airport
Charm stewardess for seat upgrade
Book Taxi

You then start to look for your holiday.

The unthinkable then happens. You find the deal of the century. I mean a true "oh my god it can't be true" sort of deal that is totally legit. It's got everything, the ideal location, a superb hotel, all inclusive booze, transfers - the lot. All for a teeny tiny price.

But there's a catch. You have to leave in 15 minutes to get the flight.

Fortunately, you have your plan and you realise that since you have already ordered everything by importance to the ultimate holiday goal, you can use this to work out what you need to do to make that flight.

So you go down each list and stop at something you can leave out - everything above it is a must have. So in Preparation, you stop at "tell neighbours and give spare key" - don't need that, so everything below it must be not required too. In Journey Out, you stop at "Book Taxi" - we are just getting out of here right now so that's not required either. In Enjoyment nothing makes the cut, all that will have to wait until we get there. Journey back doesn't make the cut either since it doesn't effect the minimum we need to go on this holiday.

So what are we left with?

Check Visa requirements
Turn off heating
Remember Passport!
Remember Wallet!

This is the minimum viable product.