In week 4 of re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along) we tackle Chapter 3, The End Of The Master Builder.  In Chapter 3 Gawande identifies the scenarios in which checklists have an impact. Checklists provide value even in complicated scenarios. (more…)

Today we begin the read of the The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). The version of the book we are reading is published by Metropolitan Book, 2009 and is the 22nd printing. The book has nine chapters and with acknowledgments has 209 pages. My reading plan is one chapter per week, therefore, the re-read will span 11 weeks (including today).  

Introduction

Until relatively recently I did not read forewords and introductions. I think I have missed a lot of contexts. The Checklist Manifesto starts with two stories from the medical arena. In the first story, the doctor missed a piece of knowledge that nearly killed the patient. If the attending physician had asked about the type of weapon that caused the wound the patient would have had less of an issue. In the second story, the surgical team missed a slight (but important) treatment deviation that stopped the patient’s heart. The patient only survived because the team stumbled over the deviation in the norm.

Prior to writing The Checklist Manifesto the paper, Toward a Theory of Medical Fallibility (note the paper, although thought provoking is difficult to get. I found a source to read online but a copy is $18 USD) made a major impact on Gawande’s thought process. The paper lays out a framework to understand why mistakes are made. There are two overall categories of mistakes. The first is due to havingonly partial understanding. For example, trying to generate cold fusion and failing, falls into this category because no one knows how to generate cold fusion, we have a partial understanding. The second category is ineptitude. Ineptitude describes incidences that in which knowledge exists but is not applied correctly. Checklists, and therefore the book, are a tool to attack the second type of incident. The idea, that some mistakes or errors are controllable and some are not might not sound earth-shattering. Not adopting a way to deal with those that are controllable is disconcerting.  

The introduction was worth the price of admission! Why didn’t I read introductions and forewords in the past . . . silly me.

A spider web has several external risks.

A spider web has several external risks.



Making sure external risks are addressed in an Agile effort, or any effort for that matter begins with making sure that at least a basic risk management approach is in place. If a basic risk management approach is in place we can integrate the concept of external risks.  Everyone involved should understand the basics of the risk management process being leveraged on the effort.  All risk management processes need to identify who is responsible and how the process fits into the value delivery flow.  Specifically, incorporating the idea of external risks into the process is typically more urgent as the scale and duration of the effort increases if for no other reason than longer efforts are exposed to the trials and tribulations of the outside world longer than small efforts.  The size of the effort affects two main variables used to scale  Agile risk management.  The larger the effort the greater the need for the people involved with the effort to define who is responsible for risk management and how much process is needed to keep things organized.   The size of the effort, while a continuum, will be represented by small efforts (one team and a few iterations or sprints) and large efforts (over 75 participants with at least 6 iterations or sprints) for illustration.   (more…)

Don't get caught up in these process mistakes.

Don’t get caught up in these process mistakes.

Almost all human endeavors use a process architecture.  Some of those architectures might not be immediately apparent, such as the scrum that often occurs at the beginning of a foot race or software development in a two-person start-up.  Others, such as the product development in the medical device fields, are far more regimented.  A mantra that many leaders in the software field utter is: “that we should only define just enough process.” It is easy to cobble together a process architecture that leads to common problems.  It isn’t that anyone goes out of their way to make a mess out of process architecture, but it happens far more often than anyone would like.  Common process architecture faux pas include: (more…)

Barbecue Recipe

A recipe is a form of procedure!

Models, frameworks, and methodologies are like the three outer layers of a matryoshka doll.  Once we have opened up the layers from models to frameworks and methodologies, components focused on defining “what” steps or tasks needed to build or deliver a product, the next set of layers shift to defining how to do a specific task or groups of tasks. The next three layers of our process architecture matryoshka doll are processes, procedures and techniques.  Each layer is more granular.

Processes are the workhorses of the most software departments. Processes define well-documented, repetitive groups of tasks and decisions needed to achieve an outcome. A simple example of a process is the steps needed to hold a standup meeting. A process provides a view of the main elements needed to meet the processes business goals.

(more…)

1481963246_fc8d418e34_o

Similar, but not the same.

Models, frameworks, methods, processes, procedures, and the list goes on and on.  Whether we are discussing Agile or plan based software development, works like methods, models, frameworks, processes and others are often used.  The people that use these terms in polite conversation often assume or imply a hierarchy in these terms.  For example, a model might include one or more frameworks and be instantiated in several methods. Each layer in the hierarchy breaks down into one or more items at the next level. Words and their definitions are an important tool to help understand how all the pieces and parts fit together and how to interpret the conversations about how software is developed and maintained in the lunch room or in hallways at conferences like Agile 2016. The unfortunate part is that few people agree on the hierarchy of models, methods, and frameworks.  These words are often used synonymously sowing seeds of confusion and mass hysteria (ok , that might be a teeny tiny overstatement). 

A proposed process hierarchy or architecture is as follows: (more…)

Boy holding a pencil

Sometimes you need some focus.

Whether you are working alone or in a collaborative office, finding a way to focus is important. I am currently experimenting with The Pomodoro Technique® as a tool to generate an environment where focusing is possible. In my experimentation, I have begun to hybridize Pomodoro to ensure I am working on the highest value activities in the right order and then to identify process improvements. I have added Kanban as a work entry technique and daily retrospectives to Pomodoro. (more…)