Lessons from Wipro’s Tryst with Lean (TPS), Part-2 of 3

The following section is devoted to the lessons that can be derived from the success of Lean principles at Wipro and applied in any of Knowledge industry--be it telecom, insurance or legal services etc.  It’s an extension of my previous posts: Wipro’s Tryst with Lean (Toyota Production System) and Lessons from Wipro’s Tryst with Lean (TPS), Part-1 of 3

3.  Specify how workers should communicate with one another.

It is about structured communications.  Since multiple people are involved in a process, effective communication becomes imperative—especially because teams may have members all over the world.  A lean system can promote good communication by articulating the ways in which it should be carried out. 

Here's how:

• Define who should be communicating, how often, and what.  Knowledge workers need to understand who will use their output.  When the supplier of the work is in direct contact with the "customer" (typically someone on the same team), the two can collaborate to ensure that the output performs as expected.  If frequent communication generates a rich flow of information, problems can be spotted and fixed early on.  And when the desired content of communication is spelled out, people get the information they need and don't have to waste time trying to figure out what others are saying.

One tool Wipro adopted to aid communications was the ‘Design Structure Matrix’.  In a DSM, a project's tasks are listed along the rows and columns of a matrix, and the team marks whether each item is related to the others, designating each relationship as either a direct dependency or a feedback loop.  This Matrix can then create a recommended order for the tasks, and Wipro used a simplified spreadsheet version that any team could understand.  With one push of a button, the program ranked the tasks and identified which team members needed to interact about each one and when.

• Create a shared understanding.  Members of knowledge teams increasingly work across geographic, cultural, linguistic, and functional boundaries.  This means they may not have the same take on what is being communicated; the same words may have different meanings to different people.  Mind it!
• Resolve disagreements with facts, not opinions.  This can be an especially big problem when the work involves tacit knowledge, because it's often not at all clear how an expert arrived at a particular decision and to what degree that decision was based on intuition or emotion versus facts.

One of Wipro's lean projects illustrates the challenge and benefit of unambiguous communication within a team.  The team in question had implemented a system of regularly scheduled reviews in which more-experienced members evaluated software code written by their less-experienced colleagues.  The reviewer for each junior member was different each time.  Unfortunately, the senior reviewers used different standards and communicated assessments differently.  What was good code writing to one might be an error to another.  Even when reviewers agreed on what constituted an error, they often called it different things.  The lack of common standards and communication hurt junior employees' morale.  One of the reviewers spotted the problem and called the team together to discuss it.  The group recognized that it had an opportunity to standardize communications as well as the primary work.  Some of the senior members put together a fist of common errors and their definitions, for all the reviewers to use.  The exercise led the team to realize that many mistakes they had considered to be fuzzy errors-issues involving such things as how variables were defined and how explanations were embedded into code—were actually quite concrete.  And once these things were spelled out, the errors could be systematically fixed.  The team's language soon became so precise that even a machine could understand it:  The code-writing program could automatically evaluate whether members had followed the guidelines and would raise a red flag if they had not.  In the end the team found itself spending less time fighting over what was an error and more time working on preventing errors in the first place.  The incidence of errors dropped dramatically as a result.

4.  Use the scientific method to solve problems as soon as possible*

The people who created the problem should fix it*

It is about addressing problems quickly and ‘directly’.   One of the fundamental goals of the Toyota Production System is to turn an operation into a ‘problem-solving engine’.  The core of that engine is the scientific method.  But there's much more to it than that. 

Here’s how to adapt the scientific method in a knowledge setting:

• If a problem arises, ideally the person who created it should fix it.  Problems can crop up because the work process is flawed or because the worker has made a mistake.  In either case, involving the worker in solving the problem usually results in a quicker solution, because the people closest to a problem typically know the most about it.  If this isn't feasible, the worker should participate in applying the fix.  Recall that at Wipro, the senior members of a software team would check the code written by novices.  If an error was found, the novices, not the experts, were responsible for fixing it, with help from their senior colleagues when needed.  This ensured that the novices knew when they had made a mistake and understood what had gone wrong, reducing the likelihood of their making similar mistakes in the future.
• Problems should be solved where they occur.  Location provides important contextual information.  Without that information, those trying to solve a problem can't reproduce exactly what happened and are much less likely to succeed.

In an era when team members are often spread throughout the world, the lean idea that everyone trying to solve a problem should be able to see it firsthand might seem unfeasible.  But modern technology makes it eminently possible.  For example, some members of one Wipro team were responsible for testing software at a U.S. customer's site;  other members, based in India, were responsible for fixing any bugs that emerged.  In this case the team members weren't just in different locations—they were in different time zones.  One group was typically sleeping while the other worked.

Sometimes the engineers in India couldn't replicate the errors that their colleagues in the U.S. had found and therefore couldn't fix them.  Ultimately, the team decided to have the U.S. group use web-video tools to record the steps they took and the system configurations that had produced an error;  this made it much easier for the engineers in India to identify the causes and fix the problem.

• Solve problems as soon as possible after they emerge.  The fresher the information about a problem, the less subject it is to distortion, and the easier it becomes to find the cause.  Attacking a problem early on also helps you make the most of the incident as a learning opportunity.  This is why Toyota has employees ‘pull and on’ cords to sound the alarm when a problem occurs.  Even if installing similar alarm systems in, say, a law firm or pharmaceutical lab isn't feasible, applying the principle behind them is.  With this in mind, one Wipro team that had been checking its newly written code weekly switched to having frontline engineers check one another's work day, while team leaders reviewed the group's work every two or three days.  The incidence of errors dropped.

By using the scientific method and having whoever caused an error fix it where and when it occurred, a knowledge organization can build a problem-solving engine that drives continual improvement.