Agile to Lean Roadmap

Recently, I wrote about the Agile and Lean relationship. In gist, the picture drawn was similar to two concentric circles, where the inner circle represents a set of practices that are Agile and the outer ring represents the guiding philosophy that we know as Lean, in context of software development. It is time to refine that picture a bit and see how it morphs further. One of the most important concentrations of Lean is on the value stream from beginning to the end, or as it's called in business lingo, from concept to cash. Lean just doesn't talk about one process in the whole value stream and then stops. In the manufacturing world, Lean mandates consideration of the suppliers, vendors, and sellers. It looks at optimizing and reducing the waste from a product and its associated processes from the origin to its walk out the door. In the software world, this would translate to, for example, picking up an idea when it is still an idea (not a project yet), its evaluation, breakdown into project(s), getting them chartered and funded, team assigned, developed, rolled out, and installed for availalbility to business. A Lean practioner would want to look at how business value is being generated end-to-end and how the waste can be avoided in this entire thread. Agile, on the other hand, has concentrated only on the software development and the chain downstream, historically. While eliminating waste remains on the agenda of the Agilists, their sphere of influence is a project or a few. They also, typically, ignore the upstream steps. There may be complex reasons behind it but one obvious reason that I have observed is the unwillingness of Agilists, who are typically technical in nature, to meddle much with management. Project identification, chartering and funding is usually seen as a management activity that the Agilists have shied away from. For a Lean practioner, the boundary between technology and management doesn't really exists.

Future of Agile as a Competitive Strategy

Michael Wah, Senior Consultant at Cutter Consortium, wrote an interesting article this month titled 'If Agile Were to Go Mainstream'. It mentions the advantages that Google has over Microsoft in time-to-market. He says, "Google is apparently practicing a more agile, iterative-style approach (sometimes quarterly) to releasing software, while Microsoft is more tied to the big-bang, multiyear cycle for its products." This is not a news anymore. One has only to be a Google user to be able to see that they release new tools many times a year and improve the existing almost as often. It's the next line that I found very interesting in which he muses on public perceiving Google as "agile and adaptive" and Microsoft as "heavy and slow".
Similarly, Netflix is raging its own battle with Blockbuster and Apple in the DVD rental space. or should I call it the movie rental space since it's soon to be a mainstream instant watch service too. A recent article (Freedom of Fast Iterations: How Netflix Designs a Winning Web Site) talks about how Netflix gets to try out new designs with real users very fast using iterative design approaches. Forecast The message in both these stories is that Agile development or Iterative development is actually being glorified like none ever before in history. The exception may be Lean, which has been talked about in media a lot. So the questions are:
  • What's the future of Agile with its foray into mainstream? - Are we likely to see an environment where every one will talk about it, understand it, but only a few will be able to implement it right?
  • Is Agile fast attaining the status of a competitive strategy? - Are we heading towards an environment where the end users will choose and companies will sell a product based on how it was built, much like Toyota.
  • What will be the future of Agile as a competitive strategy? - Is the mainstream adoption of Agile over-exposing it? How can the negative publicity by failed Agile adoptions be avoided?

The Road Ahead Here's what I think is going to happen. Agile will remain mystery to a large proportion of adopters. The reason I say so is because very few care to know the 'Why' of practices. Just adoption and implementation of practices doesn't mean that they retain the essence of Agile. As for becoming a competitive strategy, I think it will because it already has started to be. Let us analyze it from the perspective of users, competitors, clients, investors and the adopters themselves.

  • As a user I have more trust in a company like Google that releases better products more frequently because in cases there are bugs or deficiencies of functionality they won't stick around for long.
  • As a competitor if I haven't adopted Agile yet, I know that I am doomed because even if I start now it'll take me years to become Agile enterprise wide.
  • As a client of Google products I know that that I am always using the latest and the greatest that the company has to offer and it is highly unlikely that it is obsolete.
  • As Google/Netflix, in addition to having reaped the benefits of innovation, faster time to market with less waste and just enough I have potentially saved millions of dollars. This to the investors will be a sweet melody once Agile goes mainstream even on Wall Street.
As for the future, I think Agile is about to face some hard time. With very few people trained do it right, heavy potential demand and mandatory Agile implementations carried out by those untrained teams that are likely to create another thousands of untrained Agilists, the outlook looks grim. I have come across and discussed a few cases where huge projects are masquerading as Agile projects and will most likely be a nightmare soon. Given the small size of Agile community that has actually made Agile as successful as it is today, the battle they will likely fight with the skeptics will be bloody. Transition Plan Given the not so pretty outlook how can we better prepare for it? Couple of scenarios that come to mind are:
  • Start attending Agile conferences or join the nearest Agile community you can find.
  • It's never too late to start experimenting with Agile on small projects.
  • Get help from outside. Although small, the Agile community is largely independent consultants that are very knowledgeable and innovators. Needless to say that a lot of them are extremely good at what they do and that shouldn't be a surprise after you have a read a couple of their publications.
  • Lastly, if your company is serious about Agile, get help from consulting companies who have a lot of experience with Agile.
The transition and change to Agile, specially across an enterprise of thousands doesn't come about easy. It is not going to be smooth and there are some failures bound to happen. It's span and scale, however, can be minimized by utilizing a mix of approaches mentioned above. It may not just be enough to get a few of your people to attend conferences and embark of the change. Ideally, it should be mixed with some sort of external expertise.
Picture taken from:

Lean Vs. Agile OR Lean and Agile - A Relationship Defined

Several conversations in context of Lean and Agile have revealed a few patterns that I would like to share. Some people talk about Lean and Agile as if they are the same things, some try to distinguish as if they are not, and some are simply caught between the two, not sure what is what. Another observation - a lot of folks in their conversations use Lean and Agile and almost come across unsure about what they exactly are. I have heard them all - agile way, agile manner, agile methods, agile practices, agile processes, agile framework, agile tools, and a few more.
What's the difference? Let's see if the two bullet items below start to draw a picture:
  • Lean Thinking and Agile Methodologies
  • Lean Principles and Agile Practices
In the software relam, Lean is a philosophy and Agile is a set of practices. In not so refined and all encompassing manner , the philosophy is to avoid the waste which can be implemented using some practices. That's the difference. Wait a Minute! Joe: Isn't Lean a manufacturing concept and Agile from software development? You can't compare the two. Jane: Well, haven't you heard of Lean Software Development? Joe: I have, but I have always had the doubt if two fit in together.
Unified Principle Different Practices/Tools It's a mistake to see manufacturing and software development as two different things in this context. They are one and the same, fundamentally, producing a working mechanism. The lean philosophy or thinking is implemented in manufacturing using Lean toolset, whereas in software it is implemented using Agile practices. The guiding principles still are the same:
  • Eliminate Waste
  • Center on the People
  • Flow Value from Demand
  • Optimize Across Organization
Lean in manufacturing have implemented their principles using some building blocks (tools and practices) like 5S (work place organization), Total Productive Maintenance, Visual Controls, Concurrent Engineering, Kanban, Work Cells, etc. The seven wastes of manufacturing that Toyota identified - Overproduction, Waiting, Transportation or Conveyance, Over or Incorrect Processing, Excess Inventory, Unnecessary Movement (Operator Motion), and Defects - are the guiding principles behind some of the Agile practices and their evolution. Agile community's adaptation of some of the practices/tools from Lean environment have given us Pair Programming, Continuous Integration, Test Driven Development, Small Releases, Coding Standards, Sustainable Pace, Collective Ownership, etc.
So, it shouldn't be a questions of Lean or Agile, or Lean Vs. Agile. They are neither competitors nor mutually exclusive, when it comes to software development.

Tangents, Details, and a Beaten Dead Horse - Throes of a Meeting

Let me not even make an assumption that you have never been in one of those meetings where some of the participants botched it down. We all have been through those and, most likely, have been guilty of bungling meeting ourselves. That happens - yes, even the most experienced of us get carried away over-explaining the Aha ideas, or sharing war stories and anecdotes and get into details that are not so engrossing to others.
Until Jeff Patton demonstrated a polite way to rescue a hijacked meeting I stood a very high chance of being labelled 'Mr. Nuisance' for abruptly pointing out digression and demanding a move-on. Yes, I am surprised that no one has questioned my emotional intelligence on my face so far.
The panacea I learnt is to use placards. Prepare a set of 3 cards that read, SOLD, TANGENT, and TOO MUCH DETAIL written on one card each. Make sure they are accessible to each meeting participant - prepare multiple if required. And before a meeting ask your participants to raise and display the card to you if they think there's a need. This is a very polite and empowering manner to give feedback, real time. All my meetings have them now, although I haven't been shown one in a while. This, however, should be used with strict ground rules.
  • Participants should not play with cards during the meeting and will only reach out for them when a use is intended.
  • A card show will have to be honored and acted upon by the speaker.