An assortment of thoughts.  Mostly tech related.

The Phoenix Project - A very brief review

Talk to anyone involved in the DevOps, Agile, or Continuous Delivery movements and, if they’re readers(!), they’ll all likely recommend The Phoenix Project as a must read.

The Phoenix Project by Gene Kim, Kevin Behr and George Spafford

The Phoenix Project by Gene Kim, Kevin Behr and George Spafford

Despite the fact that I’ve had a copy of the book kicking around for over two years, I only recently found myself having a little downtime to sit down and actually read a physical book, so this weekend, I grabbed it off the bookshelf and got stuck in.

Unlike the majority of books on these topics, The Phoenix Project is a novel which tells a story of a dysfunctional car parts manufacturer and retail supplier, all told from the perspective of Bill Palmer who is newly promoted to the role of VP of IT Operations. The book goes on to document the journey of the company through catastrophe after catastrophe and the lessons learned, and the actions taken after each.

I had heard great things about the book, but still had my reservations, wondering how well a story could be interwoven with relevant theory without it being jarring... I had picked it up after I had first gotten a copy but never read much.

I read a few chapters - all conveniently similarly sized and short - and got caught up in ther story. The book is quite compelling (a bit of page turner - even for an IT book!) and very easy to read, and the learnings you gain from it aren’t as blatant as you might first think.

The book uses the company’s manufacturing plant to illustrate a number of lean themes and then how the IT Operations area can take a leaf out of the plant’s playbook and apply some of the lean principles in tackling their IT Ops dilemmas.

Among many themes, the book tackles:

  • Visualising work

  • Controlling WIP (Work-In-Process)

  • Theory of Constraints

  • The Three Ways

  • Four types of work - Business Projects, Internal IT Projects, Changes, and Unplanned Work

I especially liked the only graph the book contains which illustrates wait times based on busy/idle ratios - it powerfully visualises the impact of over utilisation and the importance of building in slack time to improve flow. This will not doubt be super familiar to Lean practitioners, but it was the first time I had come across it.

Wait time based on % time busy vs % time idle. Credit:  The Phoenix Project Resource Guide

Wait time based on % time busy vs % time idle. Credit: The Phoenix Project Resource Guide

The last section of the book contains a resource guide to educate the reader on a deeper dive into the theories the story touches on. For those who don’t have a copy of the book, you can still read the resource guide…

The book also recommends further reading. Some of which I’ve read, and highly recommend - Personal Kanban by Jim Benson and Tonianne DiMaria, Getting Things Done by David Allen, Continuous Delivery by Jez Humble and David Farley, to name a few.

Of the recommended books, the one that really stands out for me to tackle next is “The Goal: A Process of Ongoing Improvement” by Dr Eliyaho Goldratt. I’ve downloaded the audiobook and look forward to getting through that one next.

I enjoyed The Phoenix Project and recommend it highly to anyone involved in IT. It’s both an enjoyable and educational read and super easy to consume.

Oh…and if you’re not convinced, here’s another The Phoenix Project review with 20 inciteful takeaways.

Multiple Concurrent Sprints in a Single JIRA Project

…or having multiple teams work out of a single project in JIRA.

Out of the box, it might appear that JIRA doesn’t allow multiple teams to work out of a single backlog of work in JIRA, given that backlogs exist in specific individual JIRA projects. As a result, most teams set themselves up with a new JIRA project and work out of that.

This makes things a little difficult, especially for some scaling Agile frameworks such as LeSS (Large Scale Scrum) or Nexus, where having multiple teams operating out of single backlogs is demanded.

There’s a hidden, lesser-known feature in JIRA software that when switched on will enable this kind of operational behaviour and allow several teams to operate out of a single JIRA project.

It’s done by enabling something called parallel sprints in JIRA. To do this you need to have the ‘JIRA Administrators’ global permission.

This JIRA Software knowledge base article explains the simple process to enable parallel sprints.

Screen Shot 2018-10-16 at 3.50.07 pm.png

There appears to be a couple of gotchas, though…

The article explains:

Please note the following caveats when using Parallel Sprints:

The Velocity Chart will not show the velocity per team.

The current implementation assumes that the teams perform estimation identically, which is unlikely in practice.

These could be a deal breaker for some, but there could be workarounds.

I’m not quite sure what the second point refers to. I know JIRA can have story points or time as the estimation unit, so it could be related to that. If it’s in regard to teams and their different considerations of how much effort a story point represents, that makes sense, but I’m keen to see what this looks like in practice.

Velocity charts can be generated manually if needed.

Useful to know if you find yourself with multiple teams needing to work out of a single Backlog using JIRA Software. I’m writing this as a prompt for myself as much as it is for anyone else… ;)


The 7th Principle as a *drop the mic* moment...

I was chatting with my good friend, colleague and agile-coaching-expert, Craig Smith, the other day. It was a wide-ranging discussion as part of a debrief following a long term assignment with a client.

For whatever reason the conversation weaved its way to a discussion about the Agile Manifesto and how to best remember it. I have another post coming on that soon, but there was one principle that Craig referred to as a ‘drop the mic’ moment for him and what he described has really made it stick for me, too.

I think he’s mentioned it a bunch of times in his presentations (which are excellent BTW)…

This one.

7. Working Software is the primary measure of success

The 7th principle of the Agile Manifesto - really is the essence of it all. All of the other stuff is great, and yes, its all important and we should follow the other stuff too, but this is what it’s all about. Agile is not about merely about doing things differently and working in different ways, it’s about doing things differently in order to do what we are supposed to be doing - and doing that thing better.

If we are not measuring ourselves against this critical yardstick, we’ve got it all wrong.

It’s easy to get caught up in all the patterns, events (I can’t bring myself to use the terms rituals or ceremonies any more), practices and more, but ultimately are we building our software (or whatever it is we are paid to do) better than before?

This has really resonated for me and has become sticky in my mind. I hope it will for you.

So. Working Software is our primary measure of success. That’s what counts.

*mic drop*


obama mic drop.gif