What I Read in 2020

I’ve done this before (in 2016), I always think it’s a great idea to round out the year by summarising what I’ve read and learned. It’s far better than a quick check in GoodReads or The Story Graph!

The Phoenix Project

The Phoenix Project by Gene Kim

I try to read The Phoenix Project every year because it’s such a fundamental book for IT management.

What am I Going To Take Away? Every reread I pick up on something different. This year I’m going to try to model the workstations in a software development team.

The Unicorn Project

The Unicorn Project by Gene Kim

I had little doubt that I was going to enjoy any follow up to The Phoenix Project and The Unicorn Project didn’t dissapoint. It has to sit on that list of Must Read books for IT professionals.

What Am I Going To Take Away? The value of proper documentation and onboarding and the importance of end to end testing of an entire system.

When

When by Daniel H. Pink

I’ve always enjoyed Dan Pink’s books, Drive is a classic everyone should read. I didn’t think When was quite as strong but there’s lots of interesting stuff going on.

What Am I Going To Take Away? Are there optimum times of day to run certain scrum ceremonies?

The Mark of Calth

Mark of Calth by L.J. Goulding

A set of short stories set on Calth following the World Eaters betrayal of the Ultramarines during the Horus Heresy. I’m not usually a fan of the short story books but this one had some decent stories.

The Temp

The Temp by Steve Nelson

Some easy listening while we were going through the start of lockdown, a hapless temp who signs up for a whole set of weird jobs.

Unification (short story)

Unification by Chris Wraight

I don’t think I even remember this one. Something to do with a Death Guard warrior from the Horus Heresy to the “present day” in the 41st millenium perhaps?

Plague War

Plague War by Guy Haley

The continuation of the story from Dark Imperium. Ultramarines battle against the Death Guard.

Intelligent Design

Intelligent Design by David Spicer

A fun if fairly predicable story about AI taking over the world.

On Writing Well

On Writing Well by William Zinsser

Quite an interesting book about writing but, ironically, a little dry in places – especially when a section wasn’t something you were likely to find much use for (sports reporting in my case). Good examples of simplifying language.

The Solar War

The Solar War by John  French

I’ve been working through the Horus Heresy series but this was my first foray into the conclusion, The Siege of Terra – I’ll definitely read the others!

The Little Book of Ikigai

The Little Book of Ikigai by Ken Mogi

Less of a book about finding happiness and contentment and more about accepting the status quo in between lots of interesting facts about Japanese culture. Interesting but wasn’t a game changer for me.

Building Communities of Practice

Building Successful Communities of Practice by Emily Webber

Really interesting short read about taking a structured approach to building Communities of Practice. Maybe a little idealistic.

What Did I Take Away? Using a maturity model to slowly build and measure a community’s sustainability rather than going about it in a haphazard manner.

The Man With the Golden Gun

The Man With the Golden Gun by Ian Fleming

Classic Bond, very very dated in terms of his views about women, Russia, and pretty much anything. But still good fun.

Team Topologies

Team Topologies by Matthew    Skelton

Game changing. Proper strategies for organising teams and understanding how they communicate between them. Highly recommended.

What Did I Take Away? Consider architectural goals when designing team structure andbe aware of cognative load on teams. Consider the use of platform teams to provide platforms for product teams to consume.

Scientific Secrets for a Powerful Memory

Scientific Secrets for a Powerful Memory by Peter M. Vishton

Interesting book about human memory. Teaches and explains some of the memory hacks used by memory champions.

I Am Slaughter

I Am Slaughter by Dan Abnett

Despite having one of my favourite space marine chapters (the Imperial Fists) in it I didn’t really get to grips with this one. It’s the start of a long series and I’m not convinced I’ll pursue it. Maybe it was because I was having a rough few days while I was reading it and didn’t really give it a fair chance?

Insanely Gifted

Insanely Gifted by Jamie Catto

It’s ok to embrace you’re weird. Actually some good advice about embracing your deamons (not demons) and the fact that it’s rarely what people have said but you’re own baggage which drives your reaction. Some good stuff, if a little self help style – got me meditating though which can’t be a bad thing.

Spear of the Emperor

Spear of the Emperor by Aaron Dembski-Bowden

I wasn’t sure whether I’d do this but I really did. I loved that it was told from a mortal woman’s perspective as opposed to a space marine’s. Only problem is now I want to buy and paint even more models just so I can paint them in a slightly different shade of blue…

Getting Things Done

Getting Things Done by David    Allen

Really good book (see my review). I’d never really considered personal organisation as something you had to learn and develop. More as something which you should just know…

What Did I Take Away? Being organised doesn’t happen by chance. Develop a system and constantly challenge it. Get your commitments out of your head and onto paper.

The Advantage

The Advantage by Patrick Lencioni

I picked this up in an airport spotting it was by Patrick Lencioni (of 5 Dysfunctions fame). I have to admit I wasn’t blown away. After a repeat of everything in 5 Dysfunctions it all got quite woolly and repetitive.

What Did I Take Away? Try to define the team values before hiring anyone into it.

Understanding Non-Verbal Communication

Understanding Nonverbal Communication by Mark G. Frank

Everyone wants to know about non-verbal communication because they want to be able to tell when people are lying. In reality this course was so much more! Enjoyed listening about personal space and dominant/submissive posture.

What Did I Take Away? Consider my non verbal communication when delivering messages. Everything from where I’m sat to what I’m wearing plays a part in the communication.

Routine Machine

I was really impressed with this, I wasn’t 100% convinced when I bought it but it was on a £3 sale at Audible so I was willing to give it a go. I’m really glad I did. John is obviously obviously a director and investor in many many businesses – I’m not, but I do like a good routine and there was lots in here to like.

What Did I Take Away? Quite a bit actually! We’re the sum of our routines not our individual one of actions. Tracking and improving routines and handing them our internal computer leaving our mind decision free is a powerful thing. I also REALLY like the idea of tracking your routines and keeping an eye on the averages. A highly recommended book this one. Oh, and actually reflecting and implementing thigns from books instead of just reading them. So expect more book review posts next year.

A total of 22 books – considering the year we’ve all had I don’t think that’s bad!

Photo by Eduardo Braga on Pexels.com

Next year I want to do a lot more book reviews, not especially for you but for me. It’s not enough to just consume pages. I need to take something away and implement change from the best ones.

Routine Machine Book Review

This morning I finished listening to Routine Machine on audible. The book is by John Lamberton, who describes himself as The King of Routine and in it he discusses the power of a good routine and how it helps him (and many others) achieve financial suggess and good health.

I’d highly recommend it. There are some really good ideas in there and it really gets you thinking about long terms goals and the small steps we take each day (how agile is that) towards achieving them.

Routine Machine: How successful people improve their morning routine, daily  habits and guarantee themselves results: Amazon.co.uk: Lamerton, John:  9781910600276: Books

Of course the book isn’t perfect, there are a few ideas and comments I really don’t like. Especially around the Director or Investor of any company locking himself away for a week to write a book and ignoring all emails and messages of people who work for him who require help with emergencies. I take John’s point on board – that he shouldn’t be a bottleneck and that these emergencies often don’t actually need his help. But I can’t help thinking that he and Simon Sinek would have a very heated debate on that one!

However, there was so much I did find valuable that I’d recommend you read it to. Here are my highlights:

  1. Big goals aren’t achieved by a few big actions, we achieve them by doing lots of good little actions day after day, week after week, year after year.
  2. The biggest asset you have to achieving success is time, don’t expect success overnight – aim for it and embed the habits you need to make it happen into your daily routine.
  3. Track these habits in an excel spreadsheet (other spreadsheets are available) and give yourself gold stickers to ensure that they are sticking.
  4. Don’t bite off too much too soon.
  5. Don’t read books without taking the message way. Read the book, follow the instructions.
  6. Identify what’s important and make sure you schedule time for those things first. Put the big immovable objects in your calendar first, not the day to day 30 minute meetings we’re all a slave to.

Although John told me to write a review I don’t want to share all the advice (because second hand is never as good as the source). Instead, if I’ve peaked your interest then grab a copy and have a read.

A Geek’s Guide to People at DDD2020

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!

Tech Talks at Work

One of the initiatives I sponsor at work which I’m most proud of are our weekly tech talks. The company had a long history of doing them, a small group of people would volunteer to talk about something for about an hour on a Friday afternoon. But the prep was hard work and there was no consistency. We could have talk three months in a row and then nothing for the next six. Worse still the same people always felt pressured into talking which seemed very fair on them.

Back in 2019 I went to the Leeds Test Atelier and attended a talk by Sophie Weston. She discussed what her company had done with tech talks and I was really impressed. She argued that the key requirements for any sustainable tech talks were:

  • Duration should be 20-30 minutes
  • The same time/location every week
  • DO NOT MISS A WEEK
  • Food

Inspired by this I went back to work and set about seeing if we could pull off something similar. Sophie had explained how important it was to keep the schedule going week after week. If you start missing weeks those odd weeks develop into hiatuses and then the entire thing stops. She also strongly advised bacon sandwiches but I didn’t have a budget so we relied on BYOB (Bring your Own Buttie) instead.

Over the next few weeks I set about pitching my idea and recruiting speakers. I wanted twelve. I figured that if I could find twelve people willing to give a talk and get them on a weekly schedule then it would be worth doing and I might stand a chance of the talks becoming a sustainable weekly occurrence. I got fifteen.

The Mic Drops began to take off. Photo by Christina Morillo on Pexels.com

We booked a meeting room and opened up Skype for anyone who wanted to dial in. We also made sure we recorded all the sessions so if someone couldn’t attend they could watch it at a later date.

At the time of writing we’ve had:

  • 60 consecutive mic drops pausing only for holidays
  • Over 20 different speakers
  • 20+ hours of recorded videos
  • 1700+ attendees

Even the global pandemic didn’t slow us down, we simply moved to 100% online!

So here are my steps for starting up your own weekly tech talks:

  1. Plan out your first three months in advance to make sure you have sustainability
  2. Hold your talks at the same time and place every week
  3. Unless for a specific reasons the talk and questions should take less than 30 minutes
  4. Record them
  5. Don’t limit to “Tech Talks” some of our best talks have been on sleep, agile, management practices, books, and communication skills. Encourage variety!
  6. Always have a back up speaker, try to have two
  7. Survey your department to find out what talks people are interested in
  8. Invite External Speakers
  9. Run workshops to coach the less confident speakers
  10. Anyone can talk and anyone can attend!

Have you run tech talks in your company? Did you follow a similar format to us? What worked well for you?

Communities of Practice

Many larger companies are following the lead of companies like Spotify’s to create engineer led communities, sometimes called Guilds. The concept is simple, and very good. Creating a cross team culture of engineering excellence to drive best practice forward among employees sounds like a brilliant idea. In this post I’m going to discuss my experience of working with Communities of Practice and my thoughts on their true value.

Companies usually start a CoP initiative when they want to engineers to take ownership of:

  • Defining Standards and Best Practice
  • Training and developing it’s members
  • Breaking down Silos around teams
  • Hiring and building a better team

It sounds great right?

As with most things the reaslity isn’t quite as straightforward as that.

Teams collaborating and self directing through Communities of Practice is a hard, but powerful concept. Photo by Canva Studio on Pexels.com

As anyone who reads my blog may pick up I enjoy a little amateur psychology, I believe it helps me in my role as a team manager. One of the things I’m acutely aware is the tribe mentality of scrum teams, when people get so focused behind their products they often find it difficult to see other teams as allies – too often they’re seen as impediments to deliveries or competing products. Forming a Community of Practice asks people to shift their focus and split it away from their scrum teams to think as a wider team. It can be hard to sit with two hats on!

So, how do you get started?

There’s a very good book by Emily Webber called Building Successful Communities of Practice which outlines a very good approach. She talks about a Community Maturity Model which outlines various objectives the forming community should aim to hit as they grow. By splitting out into distinct Potential, Forming, Maturing, and Self Sustaining phases. It’s important to realise that giving someone a goal and letting them go is not enough to build a Community of Practice.

With CoPs I’ve helped develop it’s crucial to start with a small group of engaged people who set goals and achieve them. Using these successes and achievements as an example to recruit more members and take on more ambitious goals. You can force dozens of people to join a meeting but you won’t get engagement, you want to be able to hold up what the community has achieved, show it off, advertise it, and ask other people if they would help deliver the next goal.

Communities should set their own goals. They need the ability to ask their members what work is needed and the autonomy to be able to go and make it happen. Otherwise they’re simply a vehicle for management to share project work between teams.

Finally, these formative and fragile communities need real organisational support. They need people to have goals set around forming the community, these people need time (I recommend setting the expectation of a day a week out of regular team duties), they also need a discretionary budget. Breakfast, coffee, prizes, and events go a long way to getting people in the door to hear what you want to achieve and once you’ve got them a social budget is a great way to help those cross team relationships form!

If you’ve been involved in Community of Practices or “Guilds” as they’re sometimes known let me know. What advice would you give to someone who wants to form them in their organisation?

Four Types of Work in An Agile World – Revistied

It’s been over three years since I wrote my post Four Types of Work in an Agile World and a lot has changed since then but it is still, by far the most popular post on my blog. I wanted to take a minute to revise the post as I believe things have changed, in the industry in general – not just my head!

When I wrote about this topic originally I described the four types of work introduced by The Phoenix Project as:

  • Planned Work
  • Internal Projects
  • Changes
  • Unplanned Work

I discussed how we used the product backlog to mange the first three and introduced slack into everyone’s sprint and a SWAT team to mop up as much of the Unplanned Work as possible to avoid it jeopardising the planned work.

Over the subsequent years I’ve considered this a little futher. Partially as my knowledge of DevOps and Scrum have grown, but also because – let’s face it, no one wants to be in that SWAT team!

The first change I’d make to The Phoenix Project’s famous 4 types of work is to recognise that in reality all work is either Planned or Unplanned. Internal Projects are a type of Planned Work and Changes are an implementation phase of both. Lets say instead we have:

  • Planned Work
    • Business Projects
    • Internal Projects
  • Unplanned Work
Unplanned Work will always threaten to destroy Planned Work. Photo by Christina Morillo on Pexels.com

Next I’d argue that my previous approach of having a distinct team to shelter the project team is incorrect. It’s another phase of waterfall, splitting different phases of the Develop, Verify, Run into different teams creating silos which don’t talk to each other or share learning. As someone once said – if it’s you getting paged at 3am because the website has crashed you’ll quickly make sure you resolve it in office hours!

Teams must be either orientated around projects or focused on delivering platforms as described in Team Topologies. Those teams must ensure the entire lifecycle from design to operation. To do anything else is to isolate that team from the user and reduce feedback see DevOps 2nd Way).

These teams must also ruthlessly hunt down and eliminate the technical debt which leads to this unplanned work. Creating a buffer team to try to contain the work will only last until lack of feedback and continuously declining quality consume that buffer and overflow back to the development team.

Tech Debt can only be paid down by:

  • Increasing the frequency of deployments (thereby decreasing the delta).
  • Allocating between twenty and thirty percent of the team’s capactity to preventative maintenance and tech debt work.
  • Improving operability and monitoring in production.

Teams have to be utterly ruthless when they resolve issues in production to take action so that they can’t happen again. Or at least that they will be much easier to detect and resolve the next time. Unfortunately, many businesses do not invest the time necessary to maintain their own products. This leads to conflict between the teams and the business and ultimately fails both sides.

This is where it is so important to have your Product Owner on side. I won’t attempt to duplicate many excellent articles on the value of paying down tech debt and having that conversation. I’d only be repeating the words of others. What I would say is that providing meaningful metrics on code quality using tools like StyleCop, Fortify, and SonarQube help quanitify the risk to the business of continuing to operate in this way.

Negotiate the composition of your backlog with your Product Owner. Photo by Tirachard Kumtanom on Pexels.com

If you want to get your Planned Work back on track you need to hunt down and destroy the sources of Unplanned Work (this is not to say you shouldn’t respond to change when it comes along). It means that Unplanned Work is a symptom of technical debt, either in the form of bugs, lack of clarity, or poor operability.

If you want your team to be able to get on with improving your product, you need to ensure that they aren’t getting distracted by people struggling to use it – otherwise you won’t have anyone wanting to use it at all!

DDD2020

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!

For a ful list of sessions take a look at their schedule.

It won’t be quite like this in 2020! Photo by fauxels on Pexels.com

If you’d like to come along you can register at eventbrite.

A huge thank you to everyone who voted for my talks!