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

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 on

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


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


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


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


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!



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

The Mermaid Singing


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


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.

Why write Unit Tests?

Testing is a passion of mine and it’s something I expect to write about a lot more in the future. What I feel is discussed less often though is “Why are we writing tests?”

When many people talk about writing tests they talk about writing Unit Tests, classes and methods broken down into small, isolated areas of code which can be examined with tests to guarantee code quality. Let’s look at an example:

public string ReadText(string filename)
    return File.ReadAllText(filename);
    return null;

This code reads the text in a file and returns it, if the file doesn’t exist it returns null.

The thing is, this is trivial code. Writing Unit Tests for something like this is overkill surely? That thirty minutes or so could be invested in the next feature, a bug fix or meeting the tight deadline.

Let’s suppose another developer comes along in a few years time, they see this method and know something their predecessor didn’t. .NET has a FileNotFoundException exception! Deciding to be a conscientious coder they update the method to throw an appropriate exception if the file isn’t found.

public string ReadText(string filename)
    return File.ReadAllText(filename);
    throw new FileNotFoundException(string.Format("The file '{0}' was not found", filename));

Unfortunately our conscientious developer missed something. One of the myriad of methods which calls our methods is GetOrCreateFileWithContents

public string GetOrCreateFileWithContents(string filename, string defaultContents)
  var currentContents = ReadText(filename);
  if(currentContents == null)
    currentContents = CreateFile(filename, defaultContents);

  return currentContents;

Because of our change this method now fails, ReadText throws an exception and the new file is never created in it’s place. This may be an oversimplified example with an overzealous and (dare I say it careless) tidy up but it illustrates the risks we take every day when refactoring and improving code.

This is the true value of Unit Tests, not in finding bugs but in defining the behaviour of the method. If our original developer had invested that extra thirty minutes our Boy Scout would have had some warning when then tried to update the method, they’d have seen that they’d changed the behaviour of the class in an unacceptable way and wouldn’t have made their changes.

The moral of the story? Unit Tests may seem like overkill while you’re writing them. But spare a thought for the poor soul who’s trying to read your methods in a few years time… Leave them a map, a series of executable tests which guarantee that your required behaviour remains unchanged. Your thirty minutes could save them hours, prevent bugs being introduced and help keep your application stable.

SpecFlow what is it and why should I care?

I was introduced to SpecFlow a year or so ago by a friend of mine during a presentation at Agile Yorkshire. He described it as a tool for BDD and I was immediately struck by the revolutionary concept of human readable tests. It’s taken me a little time, some projects and many follow up questions but I feel I’m really beginning to grasp the power of this easy to use tool.

So what is it? SpecFlow is a framework which translates text into a series of steps which are compiled as a test.

This makes more sense with an example. Let’s say I’m the developing the software for a cash machine.

Given I have £150 in the bank
When I withdraw £100
Then I should have £50 remaining in my account

SpecFlow will then generate three steps for you to implement.

public class Bindings
  [Given(@"I have £(.*) in the bank")]
  public void GivenIHaveInTheBank(int p0)

  [When(@"I withdraw £(.*)")]
  public void WhenIWithdraw(int p0)

  [Then(@"I should have £(.*) remaining in my account")]

  public void ThenIShouldHaveRemainingInMyAccount(int p0)

I’ve filled these in quickly to give you an idea of how the process is intended to work.

public class Bindings
  private readonly CashMachine _cashMachine;

  public Bindings(CashMachine cashMachine)
    _cashMachine = cashMachine;

  [Given(@"I have £(.*) in the bank")]
  public void GivenIHaveInTheBank(decimal initialBalance)
    _cashMachine.Balance = initialBalance;

  [When(@"I withdraw £(.*)")]
  public void WhenIWithdraw(decimal withdrawlAmount)



  [Then(@"I should have £(.*) remaining in my account")]
  public void ThenIShouldHaveRemainingInMyAccount(decimal expectedRemainingBalance)
    Assert.AreEqual(expectedRemainingBalance, _cashMachine.Balance);

Behind the scenes SpecFlow has built a test using your test framework of choice (MSTest, NUnit, XUnit or a variety of others). These tests can be run within Visual Studio as any other unit test. Here’s my scenario running in Resharper:


Resharper Executing Test


I think most people would be impressed by this. SpecFlow has converted human readable text and enabled us to write a simple unit test for it. We can easily add a second to make sure that our new state of the art cash machine can also dispense pennies.

Given I have £100.86 in the bank
When I withdraw £1.99
Then I should have £98.87 remaining in my account

We can add additional complexity such as overdrafts

Given I have £100 in the bank
And I have an overdraft of £50
When I withdraw £125
Then I should have £-25 remaining in my account

Or functionality to check that I cannot go overdrawn

Given I have £100 in the bank
And I have an overdraft of £0
When I withdraw £125
Then I should be prevented from withdrawing money
And I should have £100 remaining in my account

I’m sure you can see the value of having simple, understandable definitions of what a particular area of code should do instead of the complicated, developer-only Unit Tests which litter many of today’s solutions. If you wish these executable tests can form the basis of your specs, documentation and even training. Your Product Owner can get involved and validate the tests are correct, if they’re particularly tech-savvy they may even write a few themselves!

What I particularly love about SpecFlow however is the way it empowers today’s QAs. From the moment the first bindings have been created your QA team can be let loose to create new tests, verify edge cases and prove alternate scenarios until they are happy that the feature works as designed. Tests can now be created alongside the features being developed, Acceptance Tests can be created directly from the specification which the QA team can use to validate each feature and scenario as it is being developed. These same tests then form the basis of your regression suite for years to come.

Should any of these tests fail the QA team can provide the developer with not only the human readable replication steps but with with an executable test which can be debugged on the dev’s own PC.

I find this very exciting, we’ve started using SpecFlow for a number of projects and I have every intention of using it for more. If you’re interested in finding out more visit the SpecFlow website or read their Quick Start Guide.