big batch

Main Barrier To Iterative Development: Lack Of Imagination

Organizations new to Agile often think their work cannot possibly be broken down into smaller increments of value. In this article, I want to explore a way to get over these objections:  a way that appeals to emotion as much as logic, a way that incorporates some gentle peer pressure via a comparison to the stodgy construction industry, a way that reaches the conclusion that any difficulty in breaking the work down isn’t intrinsic to the work but is instead a failure of imagination.

Indeed, when I first engage with an organization for the purpose of discussing how the Agile mindset could help them deliver more value, I almost always hear the same refrain.  Suggestions that the work be broken down in smaller increments of value are usually met with something along the lines of:  “Agile sounds great, and I’m sure these other teams you’ve worked with got a lot out of it.  But you see, we’re different because of reason XYZ, and we couldn’t possibly break our work down in smaller chunks.  That simply wouldn’t work here.”

I’ve heard this from leaders in advertising, analytics, customer support, design, IT, marketing, software, and/or you-name-it. When I’m skillful enough to overcome the early skepticism and secure space for a little education and experimentation, the organization usually learns that breaking big batches is not only possible but actually fairly straightforward and highly desirable.

This raises two immediate questions:  Why is there such early resistance to breaking down batches?  Also, why do these people think their context is so special that what works for others can’t work for them?

I’ll tell you right now that I don’t have firm answers to those questions.  However, I do have suspicions.  I suspect that many people still view the application of Agile techniques as something new and unproven, which only applies in some very narrow business contexts.  And that is a myth we can quickly dispel.

On my first trip to Barcelona, Spain, I took the time to visit the breathtaking Sagrada Familia basilica pictured below, designed by famed architect Antoni Gaudi.  There is a lot to know about the long history of this magnificent building, but for our purpose, I want to focus on the funding mechanism for the lengthy construction that started in 1866 and that isn’t scheduled for completion until 2026.  That is not a typo.  It has been under construction for well over 100 years!

Fig. 1. The Sagrada Familia basilica, “Architecture”; Sagrada Familia;
Foundation Construction Board of the Sagrada Família, 2015.  Web. 
11 Dec. 2015

On the one hand, there was a grand vision for the Sagrada Familia.  On the other hand, from the very beginning the project was to be funded by visitors.  With an expected construction that would span generations, it wasn’t possible to wait until the building was finished to welcome paying visitors.  Thus an incremental approach was used.  For example:

“In 1892 the foundations for the so-called Nativity facade were started. This facade was built first because, as Gaudí himself put it, ‘If, instead of building this decorated, richly ornamented facade, we had started with the hard, bare and skeletal Passion facade, people would have rejected it’” (“History of the Temple”).

Other examples of the Agile mindset at work abound.  In 1910, a model of this Nativity facade was displayed at the Grand Palais in Paris in an exhibition.  I am convinced this was done to keep the stakeholders focused on the value of the building rather than its cost.  Moreover, in 1952, several events of the 35th International Eucharistic Congress took place in the Sagrada Familia, further monetizing the building.  1955 marked the first public fund-raising drive, which allowed society to participate in the construction and to feel more involved.  And “in 1961 a museum was opened in the crypt to provide visitors with information about the history and technical, artistic and symbolic aspects of the temple” (“History of the Temple”).

Thus, the history of the construction of the Sagrada Familia provides us with a concrete (pun intended) example of the concept of delivering value early, and that clearly dates as far back as the late 19th century.  Moreover, of all places, this occurs in the large-scale construction industry.  If people dealing with concrete, granite, and sandstone could figure out how to break the work down in increments of value, I must politely suggest that people dealing mostly with digital work, whether algorithm, document, graphic design, music, software, or video, can do so, also.  Wouldn’t you agree?

Works Cited
“Architecture.”  Sagrada Familia.  Foundation Construction Board of the Sagrada Família, 2015.  Web.  11 Dec. 2015.

“History of the Temple.”  Sagrada Familia.  Foundation Construction Board of the Sagrada Família, 2015.  Web.  11 Dec. 2015.

Where to Start a Transformation?

So you’ve decided to go ahead with a transformation. How should you go about it? Where should you start? And whom should you start with? Does it matter? I suggest that it does indeed matter, and a lot.

For me anyway, one method has worked so much more successfully than the others that in my mind it is a “no-brainer.” That method is to cultivate fully the most fertile plot first. I call this the depth-first approach. Let me explain that. One of the first decisions that need to be made is whether the transformation will be attempted by moving everyone in lockstep, or whether there will be some form of staggered rollout and whom to start it with.

False Choice

Forgetting for a second the irony of using a big batch approach to lead a Lean or Agile transformation, we find that even the lockstep method ultimately devolves in a gradated approach. I’ve never seen a sizable group of people in which everyone is subject to identical constraints or internalizes new concepts at the same rate. Thus, even when the big batch method is attempted, you end up with pockets where certain concepts are applied ahead of others. Therefore, in no time at all some individuals and teams require a different kind of coaching. Whatever economies of scale are hoped for with the big batch approach, they quickly evaporate due to the now differentiated demand for coaching. Since coaching and mentoring capacity is usually limited, the change agents have to prioritize the opportunities for assistance.

The Who

Perhaps you pick the toughest critics and attempt to convert them first, figuring that if you can move them, you can move anybody in your organization. Or perhaps you are better off aligning with like-minded people and equipping them to evangelize on your behalf so that you can magnify your influence.

The Where

Space-wise, you could identify some of the organization’s biggest problems and attempt to solve those with the Agile mindset. If you crack one of those nuts, the likelihood that the others can be cracked too increases. On the other hand, maybe you should be wary of what is likely to be a tougher slug and instead pick a space where success is both more likely and less distant.

Mind Your Credibility

If you work in an organization that looks anything like the ones I’ve worked in, you know that people are more swayed by results they can see than unverifiable tall tales of riches. I try to never forget that as the change agent, I’m also perceived as the salesman. Increasingly tangible evidence of success may be required to move the transformation through the typical phases of adoption. This is where native stories are so important, and why I set out to create and record them as soon as possible.

Selecting the Right Investment

Every bit of transformational success is akin to making a payment to the bank. With that payment usually comes a deadline extension and an increase in credit score. Over time, as a portfolio of native successes is built, there are fewer resistors. Success begets success.  That’s why I choose to cultivate deeply the most fertile organizational plot I can find.

I’d sincerely love to hear from those who have experienced success with the breadth-first approach. I’m curious to know what conditions had to be true to make it work.