ideal one. Today, this type of work is usually seen early in the project where the customer can decide from multiple prototypes and then drive the way forward through iterative development cycles.
Sharing knowledge (sometimes referred to as ‘Amplify Learning' in Lean circles) within the organization is commonplace and advocated in every organization.
Personally I believe the best examples of this within Agile methodologies are the Scrum techniques of the Daily Stand Up Meeting and the Sprint Planning meeting. Not only is communication among the team significantly increased, including problems and successes, but if the customer is in attendance they can appreciate more why any delays in functionality (or the project) is occurring. Sometimes we (developers) forget that the customer may have parallel processes running while the system is being created. For example; process change, user training and document creation. Customers understand that Software Development can be extremely complex and would prefer to know of issues sooner as they can then adjust any external schedules appropriately, rather than finding out at the eleventh hour that the project is delayed.
Sometimes perceived Knowledge Sharing leads to waste, another Lean principle we want to avoid. This is primarily the case where organizations are attempting to extend Scrum through the Enterprise performing Scrum of Scrums where some of the projects are unrelated. This policy has forced managers and team leaders to attend irrelevant meetings in the mistaken preconception that the organization is adhering wholly to being ‘Agile'. This has been a factor in recent reports that many Scrum teams are either failing or not getting the benefits they hope to get.
Extending the Lean principle of sharing knowledge outside of the organization,specifically research and especially to competitors, is currently not a common practice. The question is: are there benefits to this?
In the Japanese Manufacturing industry, Ramp;D groups from different organizations have worked together to investigate new technologies, thus sharing costs and eliminating duplicate work. Only when the technology is realized, the same organizations compete in the market place using performance factors and features to differentiate their products.
Executives from a SD organization in the US or Europe may think this as a competitive disadvantage and that innovation should be kept behind closed doors. However we have a great example of this that has existed for several years, Open Source projects. One particular project is Eclipse. Initially conceived at IBM Canada, Eclipse was moved into the Open Source arena where it attracted a large number of contributors. Once released, the IDE gained a large user base and now has commercial competitors such as RAD from IBM, JBuilder from Borland and BEA Workshop, who are all competing on feature sets and price.
This practice promotes optimization in the industry, significantly reducing costs and increasing customer satisfaction. This last point is evident in the current demise of the HD format against Blu-ray for high-resolution video. How many of the 750,000+ purchasers of HD Players wish that Sony and Toshiba (who have now ceased production of HD DVD machines) could have worked together to produce a common standard?
I believe the cultural change is too great for this practice to occur within perceived competing organizations today. A shift is required from competitors fighting for a share in the current market to collaborating to increase the market and compete for a share within this larger market.
It is evident that a convergence of Lean and Agile principles is occurring and the term ‘Lean-Agile' is becoming more widespread (At time of writing Google returned around 32,000 results for ‘Lean-Agile'). The overarching principles of Lean, specifically