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.

Similarities Between Lean and Agile

It is said that the difference between theory and practice is greater in practice than in theory. Although I believe this is true of a lot of things, one area that eludes this old saying is the practice of Lean and Agile.

Practicality

The theoretical differences between Lean and Agile are the frequent subject of heated debates, even though their practical implementations often solve many of the same problems. I think those differences aren't nearly as pronounced as they are often thought to be, and that far too much energy is expended on their account. I suggest we focus instead on getting to the business outcomes we all crave by cherry-picking the best arguments and techniques from each. Let me elaborate:

Origins

Of all the differences I hear about, the most prevalent seems to be that Lean seeks to reduce variability in the work so that the system can be optimized, whereas Agile accepts that variability as inevitable and attempts to adapt for it. This description is not without merit from a historical standpoint. Lean was first popular in traditional large scale manufacturing environments, and Agile sprouted in software development where each unit of work is unique.  Though this analysis may be historically accurate, it is also far too shallow for us to conclude that Lean and Agile are fundamentally different.

Practices

The similarities strike me as far more numerous. Both Lean and Agile seek to deliver value to the customer through building the right thing. Both promote a culture of continuous improvement: Lean has kaizen, and Agile has the retrospective. Furthermore, Lean has poka-yoke to mistake-proof problem areas, and Agile similarly promotes the management of technical debt. Both focus on reducing delays. Lean most frequently uses the value stream map as the main tool, while Agile methods often use short iterations for much of the same purpose. Both emphasize the importance of quality. Lean has quality standards, and Agile frequently has a "definition of done." Both promote resolving blocking issues quickly through all-hands-on-deck approaches. Lean has its andon cord, and Agile often has an impediment identification and removal process. Both promote a reduction of Work In Progress (WIP) for the purpose of accelerating flow. Lean emphasizes single-piece flow; Agile urges people to swarm on a common work increments. The list goes on and on.

Values

The parallels between Lean and Agile are actually not surprising. Indeed, a quick examination of the fundamentals reveals similar values. If one compares the principles that underpin the well-known Agile manifesto with the expression of Lean found in the Shingo Model, one notices a common philosophy.

I think the Shingo Model cornerstones of respect and humility are just a highly condensed expression of the Agile manifesto. What I mean by this is simply that the Agile values (and principles) can be traced back to respect, humility or both. For example, humility is implied in the desire to replace planning with a discovery approach. To arrive at that desire, we must first humbly admit the limits of our knowledge and prediction abilities. Similarly, respect is implied in the belief that people are intrinsically motivated, trustworthy and able of self-organization.

Put another way, Shingo’s respect and humility are to Agile what the Maxwell equation is to the inner workings of electric car propulsion systems. All the information is there, but it has to be unpacked.

Fig. 1. "Maxwell-Faraday equation"

Bottom Line

In summary, I believe Lean and Agile are rooted in many of the same principles and values. The challenge of articulating the differences is probably best left to the academics. The doers should focus on taking action instead, because while the differences may be smaller in practice than in theory, practice still makes perfect. I’d love to hear from you if you think this is an oversimplification that obscures some important practical differences.

Works cited

"Maxwell-Faraday equation", Maxwell's equations, Wikimedia, 24 Nov. 2015. Web. 1 Dec. 2015.