Lean as a toolkit towards agility - Ranjan
Indeed, what the final tenet on the manifesto encourages a team to do is make sure it is learning and improving its processes over time. Scrum or XP are just basic frameworks which facilitate an initial shift, and then the team must make sure that they choose the right processes under given circumstances to be effective and inclined towards a delivery. During such a process a team might decide to break one or more basic tenets of the framework they choose to follow, if it improves their effectiveness and delivery. For example, YAGNI is a fundamental tenet of XP, but a team might choose to tweak it if they find it necessary to design upfront on certain tasks. Theorists and fanboys will shout foul, but realists and seasoned practitioners will understand the needs to do this. (Having said this, the team must at all times be congnizant of the risks taken when making these decisions, and observe changes closely for a few iterations.) These tenets are not commandments to follow staunchly, they are guidelines to follow a philosophy of continuous improvement to deliver the best value to a customer. They provide a meta-plan, or a planning approach, which is not any more important than responding to change. This realization itself facilitates better localized processes. The argument above is an example of improvement within a process. The shift towards learning from Lean Manufacturing is an excellent example of how not just a team, but the community as a whole looks around for synergies in different workplaces to improve business processes and deliver more value.
The commercialization and marketing of XP or Scrum as a development practice, sadly has not done justice to Agile as a philosophy. As more and more corporations try to join the bandwagon, I have noticed frequent claims of agility subsequent to following an XP or Scrum approach. While adapting to XP and Scrum practices is not wrong, it does benefit a team to do so, but if the team does not understand the underlying philosophy behind the practices, it fails to see a fundamental dimension of growth. By looking at just the practices within the methodology for improvement and not without, it ignores tools and practices that might help itself to improve on a larger scale. Any failures in such a premise becomes then a failure of the process followed, and management decisions being made to repeal processes. Such superficial following is thus harmful for the corporation as it misses out on a good philosophy as it chooses to discard it, based on an implementation fault.
Lean software development is the new kid on the block. Lean manufacturing and Agile Development are very aligned towards each other, for starters both are people centric and concentrate on reducing wastes. As the hype to be Lean increases, similar superficial dabs will increase, some will succeed and some will fail. Should such failures count as failures of the Lean model? Should teams stop striving to be Lean when they figure out that they would not be able to stop the line, or follow another much proclaimed Lean tenet? Shouldn't teams be looking at Lean practices as empowering tools and not laws? By educating itself towards a mindset and not just manifest of it(read Lean), wouldn't a team benefit more?
In fact what a team should figure out is that XP, Scrum and now Lean are just toolkits that facilitate aligned and effective delivery of customer demands. Stand-ups, TDD, Scrum of Scrum, Frequent releases are all a part of a greater toolkit that facilitate agility, and a team should pick and choose what is most effective for itself. Lean, like XP is a set of practices teams have evolved over a period of time to be more effective. It has evolved over prior practices like Taylorism and Fordism at Toyota. The point to note is that Toyota did not invent or create a lean process out of nowhere. They optimized based on a given set of circumstances and experimented new approaches towards manufacturing. That is an instance of pure agility. The current state of Lean is just a product of agility, and thus provides a good toolkit, just like XP and Scrum and other agile manifests do.
By treating these manifests as toolkits, we open up our perspective and become more responsible to better delivery, by following them blindly, we close our eyes and wait for good things to happen, just because we are following a process. Indeed, true agile teams improve continuously. Upon hitting roadblocks, they come up with solutions which are measurable in terms of effectiveness. They break dogma and blind faith to increase effectiveness and thus deliver more for the same dollar spent than the last iteration. And when do they stop looking for improvements? Never.
Source: Ranjan Sakalley