This week, Chapter 8 of Project to Produchttps://amzn.to/2WzvPac (Amazon Affiliate Link). I was presented with a scenario this week in which product, UX, development, testing, and security operated within their own boundaries with their own goals and tools — silos. Even though this was a discussion scenario it is easily one of the most common problems I observe in organizations once they begin to scale from start-up mode. Disconnected tools are both the result of silos and the cause of silos. This siloed behavior between departments can easily cascade into functions within departments. I often see teams that have different development tools, code repositories, and testing tools trying to work together to deliver a single product. A few years ago, a colleague and I identified five separate development and testing environments on a single release train. Trying to periodically create a single working version of the application for testing and review was a nightmare (the systems engineer in charge used different words). Every specialty and function wants to use the newest and shiniest tool leading to local optimization and fragmentation.

(more…)

Before we dive in I would like to share an observation. I have re-read any number of books over the years. Some have not held up well and I just moved on; others reinforced the ideas and excitement I garnered during the first read and that is great.  The really exciting re-reads are those that for whatever reason deliver new revelations. Project to Product is one of the later re-reads. This week is one of those big jumps for me — it did not start that way but a few things came together and there it was. We will wrap this re-read up in three or four entries and I will expand on a pattern I am seeing in how I synthesize information (hopefully it will be useful for you also). Now back to your previously scheduled re-read.

(more…)

This week, the PC version of the Kindle software I use seems to have lost its copy of Project to Product — I have gotten reasonably adept at reading on all of my devices therefore got the re-reading done. While not the end of the world, it makes this week’s chapter on disruption and the role of technical debt in some of the stories shared by Kersten even more poignant. In the chapter the author tells four stories of disruption — they are interesting in their own right. Still, if we look for a common thread I would suggest the communication needed to manage the balance between flow items (features, defects, risks, and debts). The right balance requires knowledge of external contexts such as changes in business dynamics and market risks and internal context, such as the amount of work required to support a product and the level of technical debt accumulated. Getting the balance right is a strategic portfolio decision that requires a broad range of parties at the table. 

(more…)

As the previous chapters have highlighted, we can measure the flow items that enter and exit a value stream. There are a number of suitcase words (words that have many ideas packed in them) such as value streams and flow items. Chapter 5 of Project to Product connects flow items and metrics to business results. The integrated view is where the real power of the model is found (but only if you bite the bullet and understand the value streams in the organization).

(more…)

As a reminder, the Flow Framework defines four flow items (things we are interested in measuring in this framework).  They are:

  1. Features
  2. Defects
  3. Risks
  4. Debts

Using the framework is premised on a lot of things, however, two of the most critical are value streams and goals for how those value streams are going to operate. Everything starts with value streams. Without a clear understanding of how work is organized to deliver value to the market, organizations are operating blindly.

(more…)

One of the most influential books in my career was Peopleware by Tom DeMarco and Tim Lister. One concept in the book was the concept of flow state, being fully in the zone so that a problem or piece of work can be focused on and delivered. Flow maximizes the amount of value delivered. Demarco and Lister’s introduction to flow paved the way for my interest in The Flow Framework. Chapter 3 of Project to Product introduces the Flow Framework.

(more…)

Chapter 1 begins Part 1 of Project to Product (there are 3 parts to the book). This part of the book introduces the Flow Framework, the core of the book.  The graphic showing the whole model is the first thing you see when you open this part of the book which anchors the importance of the model for the rest of the book.

(more…)

This week we begin our re-read of Mik Kersten’s Project to Product. I am reading from my Kindle version published by IT Revolution (buy a copy). Today we are tackling the front matter which includes the Foreword by Gene Kim (author of the DevOps Handbook) and the Introduction, which is titled the Turning Point. In past re-reads, I have argued strongly that jumping immediately to the core of a book is a mistake, I again urge you not to make that mistake.

(more…)

When I started writing this blog entry I tried to remember all of the books that we have re-read (or read for the first time) on a weekly basis.  I couldn’t remember.  When I look at the statistics for the Re-read Saturday entries they are almost always in the top ten, month after month so it doesn’t matter whether I remember each of the entries (I added a task to my backlog to find them all) because you find and read them.  Two weeks ago I went on holiday, backpacking on Isle Royale. It was a total unplug. During that time I ran a poll to select the next two books to re-read.  The answer is: 

(more…)