SPaMCAST 618 – Process, Not Just Checking The Box, A Conversation with Mike King and Beth Leonard

SPaMCAST 618 – Play Now!

The Software Process and Measurement Cast 618 is a conversation about “process” that I had with two great people, Mike King and Beth Leonard, in March of 2020. Just doing the process to check the box for a rating or certification, whether the CMMI, CMMC, Scrum, or any other framework, destroys legitimacy and trust.  

 

Part 2 – Systems Thinking: A Tool for Process Improvement.

A system can paint many different outcomes.

Part 1

We should be guided by theory, not by numbers. – W.E. Deming

Many process improvement programs falter when, despite best efforts, they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. “Systems Thinking” is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather than simply events. “Systems Thinking” is all about the big picture. Grasping the big picture is important when approaching any change program. Grasping the big picture becomes even more critical when the environment you are changing is complex and previous attempts to change have been less than successful. The world that professional developers operate within is complex even though the goal of satisfying the project stakeholders, on the surface, seems so simple. Every element of our work is part of a larger system that visibly and invisibly shapes our individual and organizational opportunities and risks. The combination of complexity and the nagging issues that have dogged software-centric product development and maintenance suggests that real innovation will only come through “Systems Thinking.”

 

The Checklist Manifesto by Atul Gawande, Re-read Week 4 – The End Of The Master Builder

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.

 

The Checklist Manifesto by Atul Gawande, Re-read Week 1 – Approach and Introduction

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.

 

Incorporating the Idea of External Risk into Agile Efforts

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.  

 

Basics: The Dark Side of Process Architectures

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:

 

Basics: Difference Between Process, Procedures, and Techniques

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.

 

Basics: The Hierarchy of Models, Methods, Frameworks, and More

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:

 

Focus: Hybridizing The Pomodoro Technique®

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.

 

3 P’s of Agile Centers of Excellence

An Agile center of excellence (ACoE) provides support and energy to an Agile transformation within an organization. It supports through leadership, evangelization, best practices, research, support and/or training for agile and lean ideas. ACoE’s support can be categorized in three inter-related areas. These areas, the three “P’s,” are people, process and project.

People are the heart and soul of any development process. As we have noted, Agile has an enormous focus on people (remember the Agile value of valuing people over process). The ACoE provides support to people though bringing new ideas into the organization, by providing coaching, developing coaches and acting as change agents.

Agile is a set of processes, or sets of steps taken to achieve a specific end. A recipe is a process, as is a daily stand-up meeting or checking code in and out of configuration management tool. The ACoE supports Agile processes by capturing process, identifying and fostering the use of relevant metrics (collection and reporting are typically PMO functions – to be discussed in the near future), facilitating communities of practices and providing tools.

Projects are the currency of most IT organizations. At its simplest a project is an enterprise with a start and end that is organized to deliver a result. ACoEs support the performance of Agile teams at a project-level as coaches. Coaches are folks who deliver help to teams, stakeholders and other leaders within an organization so they learn how to be Agile. At the project-level, coaches help teams use and tweak processes to meet the team’s needs, provide training and support for tools and processes and help the team learn how to ask the hard questions about how the team is using Agile.

The primary goal of the ACoE is to provide practitioners with the tools, techniques and capabilities they need to be Agile. By helping teams perform, the ACoE also helps sell and maintain the Agile transformation. Both of these goals begin as an organization starts a transformation to Agile and continue to be important as teams evolve and continuously improve. The ACoE delivers value by addressing the three Ps. For example, through the role of coaching and by facilitating communities of practice, the ACoE helps to promote an environment where there is consistency of practice and where innovation can happen. While the combination of innovation and consistency might sound contradictory, coaches often act as an Agile Johnny Appleseed. ACoE coaches see how teams work, the changes that have made to the processes and why those changes were made. The ACoE can then help to spread ideas that prove to be valuable through coaching, referrals or discussion in communities of practice.