An assortment of thoughts.  Mostly tech related.

Pecha Kucha - a Time-boxed presentation method (plus slide deck templates!)

Pecha Kucha is a lesser-known method of delivering concise, fast-paced presentations. Pecha Kucha in Japanese means 'chit-chat'.

The Pecha Kucha presentation style - similar to lightning talks - focuses on a few simple rules:

  • 20 slides

  • 20 seconds per slide (and slides are advanced automatically)

  • Slides are usually low on text, and are often just images to (hopefully, dramatically!) illustrate a powerful point to the audience.

Pecha Kucha (PK) Presentations are often done in groups. There are often multiple-speaker PK nights and meetups where people can come and learn a little bit about a lot of different topics. You can learn more about Pecha Kucha and watch a bunch of interesting presentations here.

I love the idea of these, and they borrow much from Agile/Lean thinking. I love the time-box constraints imposed, and the creativity they force as a consequence. Plus they eliminate waste!

Just 400 seconds (6 mins 40 seconds) to get your point across…

“Be sincere, Be brief, Be seated.”

― Franklin Delano Roosevelt

Downloadable Pecha Kucha Templates

While not especially difficult to create, I've created a bunch of blank templates for both Microsoft PowerPoint and Apple's Keynote. Each template has 20 blank slides with a 20 second automatic advance on each slide. I've included a deck for both 4:3 and 16:9 aspect ratios:

Download, drop in your images and practice! And, I'd love to hear/see some agile-themed PKs...

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… ;)