Clouds at dawn

Clouds are a reflection of a system.

I am revisiting a number of essays on continuous improvement.  Today a re-edited essay from 2011.

Have you ever researched, prototyped, piloted, and implemented changes to processes only to find that nothing happens? The second or third time that happens strongly suggests that optimizing steps within a system doesn’t always translate into better overall performance. The problem is that most process improvements are targeted at steps within processes rather than the system as a whole. Adjusting our point of view through Systems Thinking takes us down a more holistic path. Systems Thinking is a means of understanding systems that emphasizes the relationships of the system to the entire environment, rather than individual steps.  Systems Thinking is based on a field of study known as system dynamics.  (more…)

Off leash area ahead sign for dogs

Is Process Improvement Off-leash?

Process Improvement is a phrase with baggage that evokes a number of cognitive biases that affect behaviors, not always for the better. To test this hypothesis I asked a few people (no attempt at a valid survey). Two responses reflect the wide variety of reactions that the phrase generates. Lisa Halberg of Relativity used terms like coercion and resistance whereas Chris Teter of West Monroe Partners used terms such as meetings, tweaking, and opportunities for automation. Both answers establish anchor biases that will color how the respondent will react to the phrase process improvement. When pressed the word “process” carried most of the negative baggage. Part of the overfocus on the word process is a reflection of a not uncommon misinterpretation of the first value in the Agile Manifesto, “…we have come to value: Individuals and interactions over processes and tools.” Some of the people that have embraced agile reject the idea that processes are required. While this does not reflect a consensus view, those that hold that belief are often the loudest voices in the crowd. On the other side of the coin are those who have adopted an equally dangerous obsession with the idea that discovery and knowledge work is as mechanistic as an assembly line and therefore can be described and proscribed down to the task level. Neither extreme makes sense except in very specific scenarios. Most of us live in the great gray area where some common process exists but nothing is perfectly deterministic. If we focus on the one core principle the greatest majority of knowledge workers can agree upon, the need to continuously learn and improve, we can find a neutral phase with a useful set of characteristics to help broaden our perspective.  (more…)

Cover of Actionable Agile Metircs

A New Copy!

Before we wrap up our re-read of Daniel S. Vacanti’s Actionable Agile Metrics for Predictability: An Introduction (buy a copy today) remember that we will begin our re-read of Turn the Ship Around by L. David Marquet next week and I am stoked Buy your copy and listen to the interview I did with Mr. Marquet (SPaMCAST 202). If you want to get ahead, the book after that will be The Checklist Manifesto by Atul Gawande (I recently bought a copy and want to share what I have gotten out of it). Now on to the main attraction!

This week we conclude our re-read of Daniel S. Vacanti’s Actionable Agile Metrics for Predictability: An Introduction (buy a copy today). Over the past 18 weeks, we have explored the power of a few metrics to help teams deliver value.  None of the books we have explored in the re-read series are simple, one-idea books. The complexity of these books are the reason they are important, but it makes it difficult to boil them down into a few words. If pressed for a one-line summary, I would say that it is that every team or organization should use data to pursue continuous improvement.There are four concepts that I would like to revisit as we conclude. They are:  (more…)

A Stack of Business Books

Books

The beginning of July is a good point to take a step back and consider the path of you are on, 2017 is just over half over.  A retrospective of sorts is in order.  Just like any other retrospective, the goal is to change the trajectory of the path you are on.  Changing the path you are on is important even if 2017 has been the best year ever.  As leaders, we often exhort those around us to embrace continuous process improvement as a path to improve our teams or organizations.  Just as important as process improvement is the need for continuous personal improvement.  As a first step towards continuous process improvement, every person should identify the goal they are working toward.  The next step toward that goal needs to be the most important task (MIT) you address every day.  One of my primary personal goals is to not get stuck in a rut and to continue learning.  My most important task, every day is to take a step on the path towards continuous learning.  Planning my day begins with identifying my MIT for the day, whether that is researching and writing a blog entry, recording and editing an interview for the Software Process and Measurement Cast or reading a few pages in a book one of my first tasks begins by checking my MIT off the list. (more…)

partially inflated balloons

Where did the air go?


The overwhelming choice of process improvement specialists is incremental change.  The 21st century has seen an explosion in the use of incremental change methods, not just in process improvement, but in software development and maintenance.  Techniques and frameworks like Scrum, Extreme Programing and Kanban are just a sample of methods that are being used.  The support for incrementalism should not be taken as a carte blanche endorsement.  In order to effectively use incremental change, a practitioner must avoid these three major pitfalls: (more…)

A Thali is an incremental meal

Incrementalism–doing small changes in order to achieve a larger effect–comes in many styles and flavors.  The many variations of this approach have titles such experimentation, continuous process improvement, kaizen events, and plan-do-check-act cycles (PDCA).  To paraphrase 20th Century toothpaste commercials, 4 out of 5 process improvement professionals recommend incrementalism.  Agile and Lean are full of examples of branded incremental change models including the Toyota Production System, Scrum and Kanban (when applied to process improvement). We can see the impact of incrementalism on how these frameworks are constructed by observing the individual techniques such as sprints and time boxes, daily stand-ups both in scrum and XP, and retrospectives, to name a few.  Each technique reinforces taking small steps and seeking feedback for re-planning.  If you don’t want to consider frameworks or techniques remember that the agile mantra of inspect and adapt is a statement of incrementalism.   Incrementalism makes changes to how work is done by shifting the focus from the one big project or implementation to taking small steps, gathering feedback and then reacting. This approach to change is not new. Deming popularized the PDCA cycle early in the 20th Century.  Practitioners embrace incrementalism because making many small changes one after another provides feedback fast, which enhances organizational learning and mitigates many of the risks seen in Big Bang models. Four attributes support learning and risk reduction:

  1. Learning – PDCA type or inspect and adapt models all are built on the expectation that when a change is made, the impact will be reviewed and then the feedback will be used to improve how work is done.  Feedback is used as a learning device, where the faster feedback is generated the higher the possibility of learning.
  2. Risk mitigation – Steven Adams, agile consultant (SPaMCAST 412) stated, “Continuous process improvement is a less risky route.  But could be the slower.” Incremental changes typically will not imperil the organization in the way Big Bang or “bet the farm” type changes could.  For example which has more risk: a bank merger or adding hundreds of customers one at a time through a production interface? While this might not be a perfect analogy the larger change that gets feedback only when it’s completed will ALWAYS be riskier. Along with reducing the risk that size generates, smaller increments help ensure that that change programs don’t wander away from the vision that launched them.  Todd Field, senior project manager and Scrum master described it as, “I believe you need to have a Big Bang vision and an incremental improvements plan.“  Techniques like delivery cadence (e.g. Scrum’s sprint cycle) keep changes small and requiring product owner and stakeholder’s acceptance expose risks before they can become issues making incremental changes safer.
  3. Accumulation – Incremental changes building toward an overall goal are often compared to compound interest.  Small changes build on each other until the return is significantly higher than simply making each of the changes in isolation.  Dominique Bourget, the Process Philosopher described this concept as “It is like losing weight… you get more benefit by exercising one hour each day than to exercise 30 hours in a row on the last day of the month.”
  4. Adaptation to the pace of change in external environment – Software development environments are very dynamic.  New methods, techniques and tools are investigated, implemented and discarded as organizations try to get more done within corporate budgetary restraints. We all know the mantra faster, better, and cheaper.  Because of the rate of long term change in the development environment, change programs often lose focus or sponsorship.  Incremental changes are better at reacting to change and adjusting to the level of urgency within an organization.  Kristie Lawrence, IFPUG Past President, suggested that “continuous process improvement allows you to slowly and surely improve. The trick is to manage the scope of what is being improved – changing one thing changes the entire “system” and surface things that you never knew about.”  Implementing small changes provides a feedback loop to continually test the need for further changes.

Incremental changes provide organizations with a tool to minimize the risk of change.  Agile pundits, originally made the point in terms of software development.  The same ideas that make incremental change useful for software development are equally useful for improving the value of continuous improvement all across the business while reducing risk. As a result,  practitioners are predisposed to championing incremental change.

No Silver Bullet is the 16th installment of the Re-Read Saturday of the The Mythical Man-Month by Fred P. Brooks. No Silver Bullet is the longest of the essays, and even includes an abstract and introduction. In this essay, Brooks discusses hard parts of software development and how most of the productivity gains of the previous decades were focused around improving the processes around software development rather than addressing the really hard parts. The hard parts are capturing and translating requirements into a design. (more…)