phoenix project

I have a renewed interest in Agile. I suppose the last few years of "corporate" software projects have left a.. taste in my mouth. Agile at startups seemed much easier to implement, since the teams were smaller and had already bought in to the process. We shared the goal of delivering features. At the agency and enterprise level there are just so many more actors to consider: stakeholders, external teams, embedded clients, multiple review processes... It's much harder to achieve organizational alignment towards an agile process, even if everyone signs off "in theory".

I now identify the combination of a general lack of experience in agile and a lack of clear governance in product development the largest risk I've faced on the largest projects of my career. I've spent much time over the last five years researching and practicing maintainable code and architecture to allow a codebase to be as easy to be productive in and to enable the types of change requests and pivots that come from a truly agile environment, but it's now obvious to me that the largest bottleneck is not in architecture or even development. The bottleneck is in agile and delivery.

A few weeks back I was looking for Agile books written specifically for organizations -- how to bring about an orientation to a successful agile process at an organizational level. One that kept coming up was "The Phoenix Project" (in addition to "Mindset", which is not a book on Agile, but on enabling a mindset of change and growth).

The Phoenix Project is a novel, and it barely mentions "agile" by name. I enjoyed it much more than expected, and have already recommended it to many coworkers: developers and managers especially.

The Phoenix project is really a book about a failing organization trending towards agile adoption and a continuous delivery pipeline, but it really shines in the clarity of it's vision. It's an inspiring read with contributors who really know what they are talking about (Jez Humble is a leading figure in continuous delivery systems). The introduction of DevOps as an integral evolution of IT seems profound yet also possible and beneficial to apply at even for smaller teams. I think this is because the axioms and objectives are so well defined.

The "Three Ways" described in the Phoenix Project are already repeated often in enterprise and agency settings, and this is unfortunate. They are described without their context and therefore feel weak and cheap, just another example of a buzzword in tech.

Essentially the "Three ways" is a way of realigning business goals towards "systems thinking". Once a single business requirement can be achived through the business IT operations infrastructure, it's about developing a tech and culture that allow simple ways to identify bottlenecks and iterate on them. Essentially lean iterations on internal IT and Dev processes, in a similar way that Lean taught us to take an iterative, MVP approach to product. I'd like to write a bit more on the Three ways, maybe next week.

Gotta run to the a Russian opera!