I was recently lucky enough to speak at DDD2020. I spoke at DDDNorth last year, but this was a completely online and very different to anything I’d done before. The organisers did an amazing job and created an amazing virtual event.
Personally I hope they consider doing an online version of the conference even once the shadow of covid has gone.
If you would like to watch my talk you can find it on youtube along with dozens of other talks from the day.
The guys were kind enough to send me a shiny certificate!
I hope you enjoy the video. If you have any questions please get in touch!
I’m very proud to say that I’m going to be giving a talk entitled “A Geek’s Guide to People” at DDD2020 on the 12th of December. I’ve loved being involved (both speaking and attending) at the DDD conferences for many years and am glad I can contribute this year. It’s going to be interesting doing it virtually!
I recently listened to the audiobook version of Matt Skelton and Manuel Pais’ book Team Topologies. It was so good I bought the kindle version while I was still halfway so I could make notes and highlight the good bits (most of the book it turns out).
The book takes several principals such as Conway’s Law and really applies them to business teams. This is something I’ve seen first hand. When several teams work on one large product the codebase becomes decoupled if the teams are given ownership of particular components. However, if teams are expected to work across the codebase the solution becomes monolith and the teams become a super squad.
In the book the authors argue that there are actually a very limited number of team types in a modern organisation. I don’t want to list them because I’d strongly recommend you to buy the book and read the descriptions for yourself. However, if the various types it was the concept of platform team which intrigued me the most.
I actually think Matt and Manuel underplay the huge value of a platform team. They discuss brilliant ideas about consumable APIs and documentation for product teams which consume them. However, a data driven business like mine I believe we should run far more platform teams and far fewer product teams. If we want our Product Owners to be able to innovate and prove the value of ideas quickly we need our data sources and components to be as plug and play as possible. This allows any product or concept to be built and tested very quickly. If all these services were owned and managed by platform teams, instead of falling down the gaps between product teams the solutions would be more robust and the lead times far lower.
If you’ve never given any thought to how teams are created and assigned areas of ownership then this is a brilliant book to read. If you’re not sure how your teams communicate and share information then this book is essential.
I’ve written quite a lot over the last few weeks about Safety in team discussions. What I haven’t really discussed is how to detect when the safety is starting to fail. Imagine you’re in a conversation with someone, at work or at home and they’re starting to feel unsafe. We know that this means they will stop sharing and will result is poorer group decisions. But how do we know if someone is feeling like that and what can we do to prevent it?
If you haven’t read it already I strongly recommend picking up a copy of the book Crucial Conversations. In it, the authors discuss that people generally go one of two ways when they’re feeling unsafe. They either go to silence or violence.
When someone goes silent they often stop talking or become very monosyllabic in their responses. Perhaps they want to shut down the conversation or move onto another, safer topic or maybe they’re only sharing certain parts of the story – the parts which support their argument rather than discussing the potential problems with it. However silence manifests it’s usually because the person doesn’t feel comfortable with the topic and wants to move on or gloss over the real issue.
Other people tend to go to violence. I’m not talking about physical violence (at least I hope we’re not making people so unsafe they have to lash out). I’m talking about attacking an idea or, even worse, a person. Comments like “that’s the stupidest thing I’ve ever heard” or “only a moron would say that” are attacks. People raise their voices and try to dominate the conversation through shear volume rather than calmly discussing the topic with someone else.
It’s important to realise that both of these are natural reactions when someone feels insecure discussing something. It may be that you’ve said something which has upset them, or it may be that they’re worried about the whole topic of conversation.
In the example I gave a few weeks ago the developer had an idea which he refused to share with the group because he didn’t think the team would listen to his opinion. However, he could equally have turned to violence and tried to force his point on the group by making them feel unsafe challenging him. Both of these are defense mechanisms. It’s our role as colleagues, as human beings, to look for signs that someone is starting to feel unsafe in a conversation and to look for ways to reassure them so we can resume constructive dialogue.
Collaboration is hard, if we really want the best decisions then we need to hear all viewpoints and listen to everyone’s experience. We can’t do that if we bulldoze our view too firmly. The next time you’re passionate about an idea take a look around you and see how others are reacting to you… are they going to silence or violence? We cannot change other people’s behaviour but if we try and support other people’s confidence then we’re likely to get ideas and suggestions presented which we’d never have considered ourselves – after all, isn’t that the point of a team?
I’ve been posting a lot about communication and safety recently and I want to give credit to the book which kickstarted my renewed interest.
Crucial Conversations is by Kerry Patterson, Joseph Grenny, and Ron Mcmillan. In the opening chapters the authors explain that a crucial conversation is any exchange where the stakes are high and emotions are running rampant. They describe how avoiding these conversations or handling them badly can leave lasting repercussions on our wellbeing.
Over the following chapters they describe how to recognise safety, how to reinforce it, and how to reach a positive outcome. It’s really strong stuff, in fact I’ve incorporated many of their ideas in my own style and recent talks.
The book isn’t targeted to a work environment, in fact many of the examples are close to home and personal scenarios. Asking for a raise or disagreeing with someone over a design choice will seem like small fry compared to some of the issues the characters in the book face.
However, I believe strongly that by using these techniques teams can communicate more effectively. By using some of the ideas Kerry and his fellow authors use to monitor safety in a conversation we’ll have better retros, planning sessions, and general collaboration.
If you’ve not read it then I strongly suggest you pick up a copy – it’s one of the few books I’ve rated 5* this year.
I mentioned last week that I’d been to an interesting meeting discussing (and challenging) a few of the Scrum ideas. One of the questions we asked was about Backlog Visibility.
We all agreed that by making the backlog visible to our customers would invite feedback and reduce the likelihood that we’d spend time developing features which gave little value to our clients (see last week’s post on exactly what “value” is). But we couldn’t shake a distinct unease at making our plans visible, it took quite some discussion to articulate why this was.
Many customers and businesses work to project plans (ours included), they have long term visions of where they want to be and what they want to achieve. We realised with some trepidation that by sharing a fluid and ever changing backlog list of ideas with these customers it would create an expectation, which upon the next meeting would lead to disappointment as we had to admit the features we discussed were never in fact developed.
In an Agile environment we want to encourage this change, we want to update our backlog to remove unnecessary items and reorder the list to put the maximum value items at the top. However when presenting this to a client it could undermine us, particularly if the customer liked several of the items we ultimately decided to prune.
We decided that this is where clear communication is key. We talked about making it extremely clear that these were items we were considering working on and not a definitive product plan. A Development Forecast we suggested, after all – no one blames the weatherman if the reality turns out to be slightly different to our expectations!
What are your thoughts, do you share your Product Backlog with your clients? How do you handle their expectations that some work they are hoping for may still be cut?
Driving Technical Change is a great little book who wants to understand how to influence different people in a technology organisation.
If you’re expecting a book on mind control then you’ll be disappointed. If you’re looking for a book which will explain why people react in particular ways to new ideas and technologies then that’s exactly what you’ll get.
Terrence Ryan discusses a series of personality caricatures. These are a little extreme, but you’ll be amazed at how closely they match up with people you know!
Then, the book discusses why these people may resist change or disagree with your proposals and how you can help to win them around.
For example, one of the characters in the book is “The Overworked”, this guy has far too much to do and never enough time. They can’t spare the time to pick up your idea, so how do you convince them? Show them how your project or proposal will save their time and help them complete their neverending pile of work.
I don’t want to plagiarise Terrence work, I’d much rather you picked up a copy and let him explain them first hand.
Would I recommend this book to someone working in a development team? Absolutely! Not just to help them drive powerful ideas forward, but also to help them appreciate other points of view – understand why The Boss, The Overworked, and The Burned may not necessarily agree with every suggestion.