Informatica Perspectives

To continue from Part 1 of the Lean vs. Agile discussion, several agile and lean principles are very similar and don’t need much clarification.  A few of them however do deserve a few comments to highlight the unique qualities of one or the other.

One of the strongest themes in Agile is iterative development as indicated by principles one through three of the Lean vs. Agile chart - it even goes so far as to prescribe the frequency of iterations. Lean doesn’t prescribe either an iterative approach or put an arbitrary time-frame on delivery, but it nonetheless aligns strongly with Agile in the sense that Lean strives for small batch sizes (increments) and the fastest possible delivery in response to customer demand (pull). Lean also uses manufacturing techniques such as mass customization to achieve rapid delivery.  Furthermore, one of the best ways to mistake-proof (Poke-Yoke) integration components is to build them incrementally and validate each iteration. As stated by Levine in A Tale of Two Systems(1), “Continually ask this question: ‘What is the minimum set of functions we can put into production and get business value?’ Then do that. Then do it again.”

Agile principles four, five, six and 11 address team issues and also promote the idea of bottom-up empowerment just as Lean does.  Lean however does not prescribe the frequency of interactions (Agile suggests daily meetings) nor does it insist on face-to-face conversations. Lean however does put a strong emphasis on visiting the Gemba (the workplace where the work is being done) which accomplishes similar results. Business sponsors, users, and other stakeholders shouldn’t sit in their office and manage by reading status reports or participating remotely via conference call, they should Genchi Gembutsu (go see for yourself). Lean also relies heavily on pull signaling mechanisms such as Andon lights; the equivalent in a software factory may be an automated workflow tool that places a task on the integration team member’s work-queue. In short, Lean doesn’t insist on face-to-face communications as long as the appropriate mechanisms are in place to ensure effective hand-offs.

One way to achieve effective communications that doesn’t necessarily require face-to-face communications is the use of simulations even in the early stages of a project before all the components of the end-to-end solution are available. Simulation tools have the benefit of forcing a degree of specificity that is demanded by computer software; in other words, the act of programming a computer to produce a simulation forces you to be specific.  And as explained by Levine, “…simulations [are] a mechanism of visual management, one of the key integrating events that helped teams collaborate effectively.”

Agile principles one, three and seven prescribe working software as the primary deliverable rather than specifications or documentation. Agile keeps much of the project documentations (such as requirements and user stories) on flip charts or white boards in the project room which is then discarded after the project is over. Lean is similar in that it focuses on what the customer values (working software) and eliminating waste such as unnecessary documentation that is not used after the project is over.

If Agile and Lean are so similar, why couldn’t one just use Agile methods instead of Lean? There are several key concepts in Lean which are not addressed by Agile. Fundamentally, Agile is a project methodology while Lean is a sustaining process methodology. Lean puts a strong emphasis on understanding, optimizing, and continuously improving the entire value stream – not just optimizing a given project. Agile does encourage team learning, but its focus is on staff development and not on institutionalizing end-to-end process improvements. Lean also applies manufacturing principles such as Jidoka (automation) and mass customization to the software development process which Agile is silent on.

In summary, Agile and Lean are generally very complementary when it comes to developing integration software components. Lean however goes somewhat further in providing sustainable practices. My best advice is to select techniques from both practices and continuously learn and improve them in your organization. In other use Lean AND Agile.

Check back for part three of this blog series on Lean versus Agile. In the meantime, you may want to check out www.integrationfactory.com which includes an overview of David Lyle’s and my upcoming book Lean Integration and a number of useful reference links.

(1) Michael K. Levine, A Tale of Two Systems: Lean and Agile Software Development for Business Leaders, CRC Press, 2009