Re-read Saturday


Chapter 2 of Agile Conversations by Douglas Squirrel and Jeffrey Fredrick is titled, Improving Your Conversations.  First an update on my conversation experiment from last week. Last week I wanted to review my conversations to determine if I was correctly assessing scenarios using the Cynefin Framework. There was at least one conversation where I misjudged the complexity.  Whereas the participants viewed the scenario being discussed to be complicated (the solution being a framework or best practices), I viewed the scenario as complex or possibly chaotic.  The differences in mental models made the conversation tense and ungratifying. In my mind, my failure was not recognizing the issue until I was reviewing the conversation after the fact (one of the Four Rs in Chapter 2). I think a better approach, for me, will be to assess the complexity of the scenario before the conversion in the future. Perhaps a form of conversational premortem. 

(more…)

Happy New Year!  If you are reading this on the day it is first posted, we are just beginning a new year with all the expectations and possibilities.  Starting a re-read is a great way to start the new year. Today we start into Agile Conversations by Douglas Squirrel and Jeffrey Fredrick by charting the predicted course of the re-read and touch on the introduction.  The version of the book I am reading is the paperback version copyrighted 2020 by IT Revolution. The book consists of an introduction, seven numbered chapters, a conclusion, and 20 pages of end matter. All of this is over 223 pages.

(more…)

As 2021 comes to a close we bring our re-read of Project to Product to a close as well (buy a copy and dive into the book https://amzn.to/2WzvPac – Amazon Affiliate link). The conclusion of the book brings the discussion back as a reflection on the turning point of the Age of Software. Given that this is my third read of this book my perception may be different than yours. At a philosophical level, I think the discussion of the macro change model, Kondratiev Wave discussed in the Introduction and Chapter 1, is extremely powerful. Perhaps the current pandemic makes me more aware of the slowing wave of disruption and the gathering wave of consolidation – this is a feature of Kondratiev Waves.  We have passed the turning point, and the survival of organizations requires focus. 

(more…)

Chapter 9 of Project to Product (buy a copy and re-read the book with us https://amzn.to/2WzvPac, Amazon Affiliate Link) ties the three layers of the author’s model together and exposes the third epiphany from his visit to the BMW plant that has been the central plot element of the book. The chapter puts all the parts together, but instead of relating how he connects the infrastructure, I want to focus on how important it is to generate an end-to-end view of work for any software-intensive product. As noted in chapters 7 and 8 the environment of software engineering (broad definition) has evolved as a rat’s nest of tools and models that are rarely connected. The information about what is happening does not flow across any substantial portion of the value stream network. In many highly successful organizations, the flow of information and control of dependencies is managed by PowerPoint and meetings (better than nothing, but not much). Finding a bottleneck in the overall value flow network in this scenario is a matter of luck. This lack of end-to-end vision leads those interested in improving flow to focus on areas that they have visibility into the flow of work, which leads to local optimization. One of the classic questions heard after a “successful” tweak to a flow work is “why does the change have any impact on value delivered to the customer?” Local optimization is rarely effective. To quote my friend Steve Tendon, “you were not addressing the bottleneck” in the value flow network. 

(more…)

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

Next Page »