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.

Getting Things Done Book Review

I was recently talking with a colleague I respect greatly about personal organisation. He said he’s a great believer in the GTD method. I raised an eyebrow, it sounded like some kind of car maintenance routine. But, when someone who seems to always have his eye on any number of spinning plates throws three letters in your direction I find it’s a good idea to listen.

A little googling led me to a Todoist blog post and then onto David Allen’s book Getting Things Done. I felt my eyes had been opened.

As a developer I’ve grown up with scrum and kanban. When I moved into management I started creating ToDo lists but no matter how hard I try they always seem to fall out of date. David Allen’s book, although fairly exhaustive really opened my eyes to a better way of working.

I don’t want to go into too much detail on the GTD methodology, there are far better resources out there and the book itself is very comprehensive. However, there a few nuggets in there which are too good not to share.

The first revelation for me was that your inbox is not your ToDo list. It’s a capture tool, used for recording every commitment you make and idea you have. Allen’s approach is to frequently empty your inbox by actioning, scheduling, or delegating tasks. The same principle applies to an email inbox. Don’t let it build up, move items out into Archive or Action Required folder so you’re not digging through thousands of messages for the ones you need.

The other ideas I liked were the concept of Agenda projects to keep track of topics to cover in specific meetings and using a Waiting folder for work you are tracking but have been delegated to other people.

Hopefully this has given you a taster. If, like me you find actions slipping through the cracks or found time wasted while you were looking for the next task I’d highly recommend the book.

It’s quite iterative, the first couple of chapters contain most of the secrets. These are then expanded upon and developed in subsequent pages. It’s also very… almost technology phobic. I appreciate that the methodology should be tech agnostic, something you can do with a pen, paper, and a few folders. But in this digital first world I’d have started with a technological approach. However, the Todoist post I shared above gives a very practical guide of how to implement it using their (frankly outstanding) software.

I’m a few weeks in and so far I’m a big advocate!

Team Topologies Book Review

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

Team Topologies

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.

The Unicorn Project Book Review

When I first heard about The Unicorn Project I have to admit I was disappointed, I’ve long been a evangelist for Gene Kim’s book The Phoenix Project but I’d just spent months working on my own development DevOps book, Code Black.

I shouldn’t have worried, I really enjoyed The Unicorn Project and we’d gone down different angles. Where I’d focused more on the Continuous Deployment journey Kim’s book focuses much more on developer empowerment and continuous experimentation.

The Unicorn Project

The story follows Maxine, the developer who caused the now legendary payroll outage at Parts Unlimited towards the start of The Phoenix Project. Exiled to the documentation team as punishment she’s instructed to support the Phoenix rollout but quickly realised how woefully under supported the engineering teams are. As the business piles on more and more pressure, expects more features, and has less and less appreciation for the technical debt they’re wracking up they continue. Until, as we know the entire project explodes.

Working with some familiar characters such as Bill, Brent, Erik, and Maggie and a few new ones including Cranky Dave and Kurt our heroine works to make life better for the entire company. These are the engineers, the red-shirts, not the bridge crew. They’re the ones who actually do the work and they’ve got a lot of it to do!

What did I like best? Kim put lots of emphasis on testing and improving the entire system not just a small part of it, he focuses on collaboration and the importance of making it easy to onboard developers and share knowledge, and really drives the need to innovate and out experiment the competition. He also emphasis the importance of treating engineering tools as important systems and draws distinctions between the IT products we build, and the miscellaneous ones which just keep the lights on.

What wasn’t so good? Within a few chapters I was absolutely sick of Erik’s use of the word “sensei”… seriously can’t some of the people he quotes simply be experts, evangelists, or even gurus!?

On a more practical point the book spends a lot of time evangelising functional programming and scalability technologies. Which is great, they’re very powerful tools. But one of the things I liked so much about The Phoenix Project was how it was clear the team were struggling the same tech debt we all are. It made it more relatable and I worry in this book Kim’s “rip it out and use the latest and greatest” will overpower his more generic messages of continuous incremental improvement. Perhaps it’s personal preference but I like my DevOps books technology agnostic.

So, would I recommend this book? Absolutely without question! I believe that The Unicorn Project will take its place alongside its elder sister on the bookshelves of developers, testers, managers, product owners, and operational engineers for the next decade. If you haven’t already go and buy it, any while you’re at it not get a copy of Code Black too!? 🤣

Crucial Conversations Book Review

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.

CCBook

Driving Technical Change Book Review

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.

What I Read in 2016

This post is shamelessly inspired by John Sonmez’s blog post Books I Read, seriously 72!? I need to get an audible account! Here’s my list:

IT Related

Always space for some geeky books on my shelf!

The Phoenix Project

img_0319

This is possibly the most important book IT managers can have on their bookshelf at the moment. The Phoenix Project illustrates how systems thinking can be applied to IT and shows you how futile software development is without it. If you’re going to read one book in 2017 make it this one!

The Goal

220px-the-goal-bookcover

An oldie but a goodie, I did a book review on The Goal recently and I have to say. Once you’ve read The Phoenix Project if you want to go a little deeper then this book is absolutly essential!

Rolling Rocks Downhill

img_3736-1

This is a book I’ve quoted from several times before, Clarke came to speak to us at Agile Yorkshire and I made a point of picking up his book. What I love about this book is how Agile ideas are developed as solutions for problems the team is having, rather using methodologies and presenting them as solutions to your problems.

5 Disfunctions of a Team

dysfunctions

This one was recommended to me via a colleague, it’s a great quick read and essential reading for anyone works in a team (therefore pretty much anyone). I’ll do a review of it sometime soon, recommended reading!

 

Personal

Although my wife doesn’t believe it I do occasionally read books which are not work related!

The Mermaid Singing

516xlezdovl-_sx330_bo1204203200_

My wife reads dozens of books where people are brutally murdered and has always encouraged me to do the same. While we were on holiday she talked me into reading a the first of Val McDermid’s Tony Hill series and I have to admit I loved it. I’m reading The Wire in the Blood already!

Divergent, Insurgent, and Allegiant

divergent-series

I actually really enjoyed these, I’ve seen the Shailene Woodley films on the shelf at the supermarket and have held off on buying them until I’d read the series. I’d expected another Hunger Games or Twilight Saga and while I wasn’t too wrong I loved the idea of the factions system. A good read, loved the twists and thought the big series twist was inspired.

 

8 books, nowhere near John’s 72 but still a good list. What have you read this year? Anything to add to my list for 2017?

 

The Goal Book Review

I recently finished reading The Goal by Eliyahu M. Goldratt. This is the book which is referenced in The Phoenix Project and Rolling Rocks Downhill so I was determined to get my hands on a copy and read it!

Alex Rogo is a Plant Manager, work isn’t doing so well… in fact he’s been given an ultimatum and is about to get shut down. In order to save his job he enlists the help of an old teacher who persuades him to question the standard measures and processes he’s been using his whole career.

What follows is a very interesting and in depth look at the Theory of Constraints (although I don’t actually believe the term is used in the book) as the team try to identify the bottlenecks in their plant and work on ways to exploit them.

Like the best books Eli doesn’t try to throw too many concepts at you, his message is clear – find the bottleneck and organise work around it. There are some great analogies (such as Herpie leading his fellow boy scouts through the woods) and you genuinely feel like you’re working these problems out alongside Rogo.

The last few chapters felt a little disorganised to me but they they carried an important message – build up the process of how to examine your system, don’t just rely on a defined step by step guide. Continuously review, understand, and adapt.

Would I recommend The Goal to other IT Managers? Absolutely! You’ll gain a great understanding of how to observe and measure your team’s throughput.However, I’d say it’s absolutely essential for anyone in software development to read The Phoenix Project first so you understand why we’re looking at manufacturing plants to help us run IT departments!

The Phoenix Project Book Review

I recently read The Phoenix Project, the definitive and often referenced DevOps Business Novel by Gene Kim, Kevin Behr, and George Spafford.

I have to admit I’ve been putting off reading this book, perhaps I had some misgivings about replacing Scrum techniques with the new craze of DevOps. Having decided that I was going to invest my time I was tested once again when I realised that Bill, the book’s main protagonist is an infrastructure guy… I’m a Development Manager, I want to know what DevOps can do for do for me not what I can do for the other guys!

That however was the last time I paused before devouring the remaining 370 pages.

Bill’s first few days after his promotion are littered with disasters. He has a project to deliver, infrastructure problems to resolve, and political ambushes to endure. In other words, he’s in the situation we’ve all experienced when teams aren’t communicating and colleagues are so stacked up with their own projects and priorities that they simply can’t assist each other.

With the timely arrival of Eric, the new potential board member Bill slowly equips himself with the tools he needs to resolve his infrastructure headaches and get the Phoenix Project back on track. Eric, acting as a kind of DevOps Yoda helps Bill gain an understanding of the four different types of work, the Theory of Constraints, Systems Thinking and see the value of Automated Deployments.

There’s a nice appendix at the end which helps consolidate the ideas and explains some of the ideas away from the story. There are also some mind blowing statistics about how some of the big web companies such as Amazon, Google, and Netflix.

So would I recommend this book to others? Absolutely! In fact I have, repeatedly to friends and colleagues! Whether you’re a developer, infrastructure guru or IT manager this book will introduce you to several new ways of thinking about workload management and IT processes.

Rolling Rocks Downhill Book Review

I read Clarke Ching‘s book Rolling Rocks Downhill a while ago and I picked it up again recently while on holiday. I’d enjoyed it the first time, going back over the story a second time with a little more leadership experience I was amazed just how many valuable lessons Clarke has managed to cram in there!


The book is a Business Novel and follows Steven, the Development Manager at Wyxcomb Financials who discovers that a competing company has stolen their idea and is determined to beat them to market. Their project on the other hand is behind and likely to slip even further. With their company’s future at stake Steven must develop a new approach to development to save the day.

What follows is a story of a team discovering Agile ideas and practices for themselves.  Not because they have a guru preaching at them, but because they’re trying to solve real business problems. I couldn’t help chuckling at some of the discussions Steven has with his mother, the Product Sponsor, and even the Cafeteria Manager as he learns about Iterative Releases, Product Backlogs, Continuous Testing and the Theory of Constraints.

After all can you really understand the advantages of building a small number of features in an iterative manner if you’ve not heard about the French Fry Revolution!?

An easy read and a great book to really reinforce some of the ideas of scrum you already know with real world examples. Recommended to anyone!