Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 434 features our essay on Change Implementations – To Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams.   (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.

Vinigear Bottles

Not Sweet But Useful!

A big bang adoption of a process or system is an instant changeover, a “one-and-done” type of approach in which everyone associated with a new system or process switches over in mass at a specific point in time.  There are positives and negatives to big bang approaches.  We begin with the positives.

Patrick Holden, Project Portfolio Director – Software Development at SITA, struck a fairly common theme when asked about his preferences between the big bang and incremental approaches.  

While I favour incremental improvement, sometimes we really want to get on with the new, to change the mail system, phone, house, car or even your job you will need to prepare to different extents but you make the switch for one and all, it’s a Big Bang.  

The choice depends on divisibility, scope, and urgency.

The positives:

Big bangs fit some types of changes.  Not all changes are easily divisible into increments which lead to an all or nothing implementation. As I have noted before, most of the bank mergers I was involved in were big bangs.  On a specific day, all of the branches of one bank would close and overnight (more typically over a weekend) lots of people would change signs on buildings, customer files, and software systems. Perhaps it was a failure in imagination, but due to regulations and the need for notifications, it was easier for everyone to change at once.  Organizational transformations rarely have the same external drivers, regulations and notification rules; however, because of interactions between teams, it might be easier not to take an incremental approach.  Adoptions of large scale Agile methods and frameworks such as SAFe are often approached in a big bang manner. In SAFe many teams and practitioners are indoctrinated, trained and transformed together which by definition is a big bang approach to implementing scaled Agile.

Big bangs generate a too big to fail focus.  Large, expensive, and risky changes create their own atmosphere.  These types of implementations garner full management sponsorship and attention because they are too big to fail.  Christine Green, IFPUG Board Member, suggests, “it is harder to lose focus on big bang approaches when organizational leadership changes.” Big bangs can be used to address the risk of a loss of focus in some cases.  An example of an organization manufacturing a too big to fail scenario can be found in the often-told story of the early years of Fedex (Federal Express at the time).  It was said that the founder consciously borrowed money from smaller regional banks around Memphis so that he could use the impact of the risk of default to negotiate better service and rates.  Big bang changes are often too big to fail and therefore people ensure they don’t.

Management Expectations.   In many circumstances, management has little patience for the payback of continuous process improvement. As I was framing this theme, Christopher Hurney stated, “I’ve seen leadership expect Big Bang results in Agile adoptions, which is kind of ironic no? Considering that one of the precepts of Agility is an iterative approach. The expectation is often generated by a sense of urgency.  In this situation, a specific issue needs to be addressed and even though an incremental (or even iterative) approach would deliver bits and pieces sooner, the organization perceives value only when all of the benefits are delivered.  The Healthcare.gov marketplace was delivered as a big bang.

Even if the big bang approach to process improvement feels wrong, there are reasons for leveraging the approach. Chris Hurney stated that decision makers “tend to feel as though they’ve reached a point where a process has become unsustainable,” which makes the idea of implementing a change all at once worth the risk even though nearly everyone would prefer an incremental or continuous approach to change.

Previous Entries in the Big Bang, Incrementalism, or Somewhere In Between Theme

1. Big Bang, Incrementalism, or Somewhere In Between

Next:  Big Bang, The Cons!

 

Line Segment Shutdown

Line Segment Shutdown

When making any significant change to a team or organization, deciding whether to take a big bang or incremental approach is important.  Both of these approaches–and hybrids in between–can work.  Big bang and incremental approaches mark the two ends of a continuum of how organizations make a change.  The decision is almost never straightforward and organizations often struggle with how they should approach change.  The decision process begins by defining big bang and incremental implementation approaches in between the two ends so they can be compared. (more…)

Boundaries, like fences are one potential difficulty.

Boundaries, like fences, are one potential difficulty.

Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options. Dan and Chip Heath indicate that options are a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.  The difficulties with using systems thinking fall into three categories.

  • Boundaries
  • Complexity
  • Day-to-Day Pressures

Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.  Boundaries are a key tool for defining teams and providing a send of belonging; however, some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.  Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that, even if perfectly optimized, will not translate to the delivery of increased business value.  In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets, only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization. (more…)

 

Credit card billing systems are a useful way to explore systems thinking.

Credit card billing systems are a useful way to explore systems thinking.

The world made up of interlocking systems. At more finite level, such as a company or product, understanding systems is crucial for being effective and efficient.  For example, have you ever observed a team spend time researching, prototyping, piloting and then implementing a change to improve a product’s delivery rate, only to find that the process change yields little to no big picture impact? The second or third time you make this observation it drives the point home that optimizing steps within a system doesn’t always translate into better overall performance.  We need to think of the system as a whole.  Systems thinking pushes us to take a more holistic path.

A system is a group of interacting, interrelated, and interdependent components that form a complex and unified whole.  Russell Ackoff, the management guru, defined a system as “an entity which is composed of at least two elements and a relation that holds between each of its elements and at least one other element in the set. Each of a system’s elements is connected to every other element, directly or indirectly. Furthermore, no subset of elements is unrelated to any other subset.”  A critical core to these definitions is that a system is a number of related components that interact.  I add that the core of most (if not all) systems operate within a larger systems ecology that they interact with and which provide feedback and guidance. (more…)

TDD is a life jacket for Quality.

TDD is a life jacket for quality.

Test Driven Development promises serious results for teams, organizations, and customers, including improved quality and faster delivery. The promises of TDD, or any of the other variants of test-first development techniques, are at least partially offset by costs and potentially tragic side effects when it is done poorly.

The positive impacts explored in earlier articles on TFD and TDD include: (more…)