Goals for 2021

As is the time for goals and be years resolutions I’m going to throw out a few of my own.

  • Read 21 Books
  • Write 52 Blog Posts
  • Pass my PSM1
  • Finish my new book
  • Finish painting my Stark and Lannister armies!

21 books isn’t that ambitious for me, although without knowing whether I’ll be commuting will cut into my audible time. The scrum master exam, yeah – I probably should have hit around to that years ago!

The book is top secret, well… unless you’re on Leanpub! But the blogging and painting will take some discipline.

Let’s see how it goes. Happy New Year everyone!

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.

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!

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!? 🤣

Is Velocity a Vanity Metric?

A few weeks ago I went to a talk at Agile Yorkshire by Tom Hoyland where he discussed the how he formed an agile team. In it he claimed that Velocity is a Vanity Metric.

If you haven’t read it then I highly recommend you pick up a copy of The Lean Startup by Eric Ries, this was my main introduction to the term. In the book Eric talks about how a Vanity Metric is any figure which is skewed to inflate the success of a product. One of the example he gives is Number of Registered Users, a figure which will clearly go up and up over time. A better metric, Ries argues, would be Number of Active Users. Obviously if you’re looking for a successful product you’re more interested in how many users are currently using it than how many people completed the signup process.

He claims that by basing metrics and KPIs on these Vanity Metrics is akin to giving yourself a pat on the back for building a successful product while sticking your head in the sand about why your business was losing money (or the startup running out of runway as he describes it in his book).

photo of woman looking at the mirror
Beware the Vanity metric! Photo by bruce mars on Pexels.com

So, to return to Tom’s question – is Velocity a vanity metric?

Most Scrum Masters calculate a teams’ velocity by taking an average over the previous sprints. The number of sprints varies but six (around 12 weeks of work) is the norm. Using this figure the the team can then calculate how far a particular story is away from delivery or epic from completion.

person typing on laptop
Photo by rawpixel.com on Pexels.com

There’s no doubt that Velocity is a useful forecasting tool (although, as one of my colleagues pointed out recently that if you plan a sprint on your average velocity then you will, by definition, fail 50% of the time). However, is it deluding us into thinking we’re a successful team and detracting us from more accurate measurement?

I think this comes down to how you measure success. Most people would agree that judging a development team on how many features they can deliver is fairly narrow minded. A development team includes a Product Owner, their remit should be to develop a product not to simply crunch features. If that was their goal then they could simply create huge numbers of easy, yet useless features just to score points.

In this new age of DevOps a Development Team should use their PO’s expertise and take ownership of the success of their product. For them to be judged on how much work they produce, rather than how much success they’ve had is a limited measure. It reminds me of the from the book The Goal where they measured and optimised the workstations rather than asking whether the system was effective.

Therefore, although shocked when I heard it I agree with Tom. Velocity is a useful tool for the team to forecast. But if it’s chased as a KPI or used to measure the team then it is indeed a vanity metric and will distract the team from trying to improve their product. If we want to measure our teams’ success then we should look at the metrics of our products, not try to calculate some kind of Hours to Story Point ratio or chase an ever increasing Velocity. We should focus on Number of Active Users or Number of Requests via the API, this will measure the teams’ success, rather than it’s productivity. As a friend of mine is fond of saying, effective rather than efficient.

Scrum vs Scrumban

I wonder how many companies out there genuinely believe that they’re “Agile” because they have daily standups? I’m also curious how many people could explain the difference between Scrum and Agile? Before talking about all the merits of Scrum vs Scrumban I’m just going to reiterate a few of the basics.

Agile is a set of principles and ideas which signatories of the manifesto believe will help development of software (or actually almost businesses but for the sake of simplicity I’m going to stick to development teams).

Scrum is a process teams can follow to help them follow these principles.

Scrumban is another process which aims to uphold the Agile principles but in a slightly different way.

Most people are familiar with Scrum’s iterative approach. Software is completed every Sprint (usually every two weeks) and the upcoming work is ranked in order of priority and the team commits to delivering a certain number of those tasks in their next Sprint.

Scrumban is a little different, upcoming work is continuously reprioritised and team members pick items off the top of the list. There are no planning meetings because there’s no sprint commitment.

A few years ago we were struggling with the amount of support time our customers required. Ticket priorities were constantly changing and expecting the operations side of the business to wait for the next sprint planning session was unreasonable.

I wrote about our two team system a few weeks ago. Once we were free of trying to design a process to accommodate both Planned and Unplanned work we realised that for a ticket driven environment Scrum was no longer the approach for us.

Using Scrumban for our Support Developers means the operations team can continuously repriorise tickets in our queue as customer’s priorities change. As soon as a problem is escalated it moves to the top of the prioritised list, can you imagine the benefits after continuously breaking sprint?

We have a Kanban board in Trello, on the left are the prioritised tickets, next we have tickets a developer is actively working on, next are tickets ready to test, and finally a list of recently solved ones.

At any point I can send out the board and say “this is what we’re looking at, this is where your problem is”. Various stakeholders can negotiate with the PO to adjust priorities as required.

What’s key here is visibility, when your stakeholders can see the ordered list and can negotiate their position on it they feel far more empowered than sitting waiting for an endless queue. However in my experience it’s worth triaging this list as issues come in and letting quick win issues jump the queue to avoid long, pointless wait times.

We believe that this approach makes our Support Developers far more flexible and (hopefully) helps us provide a better customer service – that’s certainly what our numbers imply!

Have you tried Scrumban? How do you plan your Support Developers work?

What Makes Me Hire A Developer?

I’m going into a new round of interviewing developers for my team so I’ve been giving a lot of thought to what I look for when I’m interviewing people to work with.

Joel Spolsky says that you need to look for two things, brains and the ability to get things done. His reasoning is that developers who are smart but never finish jobs belong in never ending research projects, developers who get things done but aren’t smart end up causing you more work and if your candidate has neither then you should run a mile!

While I like his logic I have a few other criteria.

Joel doesn’t mention the candidate’s passion, their ability to learn, to form relationships with their team, or to empathise with the customer. In my eyes a developer who doesn’t have these qualities will negatively impact your team’s dynamic and product just as much as someone who produces bugs for a living.

So why an ability to learn? I hope this one fairly obvious. In our fast paced development world a developer’s ability to learn new technologies, absorb ideas and keep up with current trends is (in my opinion) more valuable than whether they have an in depth understanding of bitwise operators or lambda expressions. I’m not saying don’t ask about the technical side, but make sure your candidate can learn your code, your technologies and whatever comes along next!

Relationships? How many times have you worked alongside someone who can’t work in a team? They’re territorial, overly sensitive and horde knowledge with the misguided belief it makes them invulnerable. Look for people who enjoy the camaraderie and take time to teach and learn from their colleagues.

Empathy for the customer? This is, in my view one of the most important. Can your candidate put themselves in the shoes of your clients? Can they envisage how a bad release will impact your reputation? Do they understand the consequences to people’s working day when your code doesn’t work as expected? Find someone who understands the frustrations of bad software and poor customer service and you’ll find someone who will strive to prevent it!

Passion? Simply put I want a developer who wants to develop software! I don’t mean you have to spend every evening and weekend writing code or contributing to open source projects but demonstrate to me that you enjoy what you do. Tell me about what you’re working on, explain that bug fix you’re really proud of but please prove to me that you’re there’s something about the job you actually enjoy (other than just the £££s).

So there you have it, a few of the qualities I want my developer candidates to demonstrate for me. What do you look for when you’re interviewing? What personality traits do you try to show when you’re being interviewed?

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?

 

Multiple Binding Attributes in SpecFlow

I recently discovered something rather nice in SpecFlow, I was implementing a scenario like this

Scenario: Save a user
Given I have a user with the name Joe Bloggs
When I save them
Then the user should have a FirstName Joe
And the user should have a LastName of Bloggs

I wanted to provide the flexibility in the assertions so our QA could decide how he wanted to phrase the text in the scenario. Logically however we’d want the same binding for each variation.

Here’s what I came up with:

[Then(@"the user should have a (.*) (.*)")]
[Then(@"the user should have a (.*) of (.*)")]
public void ThenTheUserShouldHaveA(string field, string value)
{
  var user = GetUser();
  Assert.AreEqual(user.Properties[field], value);
}

However this didn’t work, I kept getting a field of “FirstName of”. I discovered however that you can reverse the binding attributes to give priority.

Updating the attributes to

[Then(@"the user should have a (.*) of (.*)")]
[Then(@"the user should have a (.*) (.*)")]

This change gave the of binding precedence and ensured that both scenario steps worked correctly.