Oobeya is a Japanese word that means “large room”, and refers to a room where the walls are covered with visual representations of a project (such as schedules, diagrams, drawings and metrics). An Oobeya permits a team to steer its projects efficiently and reduce the time to market of its products.
More than just a room with visuals, Oobeya is a project management method based on lean principles:
- Satisfy your customers completely by focusing the team’s energy on delivering top-quality products and services, at the customer’s pace
- Reduce lead time and costs by eliminating waste and variability within your own activities and processes
- Develop people by increasing their autonomy in solving problems and improving their work day after day
The first bullet implies a direct link between the quality of a product and the satisfaction of its users. A happy customer is one who will spread the word and keep coming back for more. What IT engineer does not dream of this?
The second bullet implies that there is always a better way to do things. Lean strives to create a more serene work environment so that people can spend their brain power on creative matters rather than firefighting. Inevitably, finding ways to eliminate waste saves time, and time is money.
The third bullet implies that it is important to develop people in order to develop good products. By applying the scientific problem-solving method every day, workers develop their autonomy (and confidence) in addressing issues and making the right decisions.
Oobeya has three key characteristics:
Firstly, Oobeya relies on visual management, which is one of the lean foundations. The goal is to make work visible so that problems are intercepted as soon as they appear. Project teams can then tackle the right problem at the right time, and each problem becomes an opportunity to learn something together. This practice is all the more important in IT, where the work is hidden in peoples’ heads and in computers.
The second key characteristic of Oobeya project management is that it promotes intensive collaboration and builds mutual trust. Solving problems in a factual and structured manner tends to bring people into consensus quickly and helps them put aside emotions. Furthermore, the Oobeya forces people to resolve a problem together instead of just pushing it onto someone else because “it’s their job” or “I do not have time”. Finally, successful problem-solvers develop self-confidence in their ability to resolve issues with others, and as a result others are more inclined to trust them.
The third key characteristic of the Oobeya project management method is that it requires strong leadership and vision. This implies that behind any project, there is a unique product that embodies the vision of one person. In the Oobeya approach, this vision preferably belongs to the lead or chief engineer.
This is not to say that an innovative product is just the doing of a single person, but it is most certainly the result of a highly creative mind whose persistent goal is to turn their vision into a high-tech product. The lead engineer is similar to the designer in the high fashion industry. In IT, there are a few good lead engineer well-known examples, such as Steve Jobs, Larry Page or Mark Zuckerberg. Not all lead engineers build multi-billion dollar businesses out of their great ideas, but I guess…they could.
In corporations with large IT departments whose job is to support the company’s business, the concept of a “lead engineer” might seem remote because a lot of the activity is about maintaining existing systems. The majority of projects are corrective actions or small improvements. So why do you need a creative and visionary technical expert to run these everyday projects? In many cases, you probably don’t; however, it is still crucial to have a dedicated “product owner” for each project who is 100% responsible for the delivery and manages the whole process from A to Z. The Oobeya method requires such a person to take the lead.
Rescuing IT in big business
Most large companies I’ve worked with are organized in functional and technical silos (business analysis, architecture, design, application development, quality, data migration, application interface, reporting, network, servers, security, etc.) all connected in one way or another, but not really working together. Sometimes, you will find a project manager whose job it is to “coordinate” projects. This generally means that they try to get all the silos to do something together, but with little success because they have no recognized authority, and also because they don’t have enough technical and functional knowledge to help make speedy decisions.
This situation generates problems that are all too known in the world of IT: projects are late and run over budget, while the final users keep complaining about the quality and usability of their tools.
According to the 2013 Chaos Report by the Standish Group, this phenomenon is not just widespread; it is systemic. On average, only 39% of IT projects commissioned by businesses succeed, meaning they are completed on time, on budget and with all required features. Failure to deliver on time may possibly bring down penalties upon the firm. Quality suffers as there is more pressure to rush into delivery in order to avoid further delay.
The Chaos report also mentions that small projects are more successful than large projects. This is partly due to the growing use of the agile methodology over the past decade.
Agile is a framework for building the right product with minimum overhead in an unclear environment. It provides software development teams with many advantages: increased visibility through taskboards and burndown charts, flexible design through iterations, and faster development through automated tests and code refactoring. I myself have developed better products using the agile methodology. And to be honest, I have had a lot more fun working with auto-organized agile teams; they are a good remedy against micromanagers.
However, agile did not resolve all my problems. What is the point of developing faster if my team is the only one in the process that does so? How can I avoid “de-scoping” in order to meet a client deadline, even if it is understood as “re-prioritizing”? How do I get rid of technical debt once and for all? How do I train new developers quickly? Every day, I see agile teams struggling with these and similar problems. If ignored, they can result in dissatisfied customers, delays in releasing the application, lower than expected velocity, and team overburden.
Observing the operations of IT teams in the field, even agile teams, I encounter certain problems occur over and over:
- People involved in the project do not know who their client is or why the project exists. The project vision is often fragmented.
- The process of collecting client requirements is too formalized, so client problems are not well understood
- There is a lack of synchronization between all teams involved in the whole project
- Project schedules don’t correspond to reality, because the key people in the field (i.e., all technical and functional experts, from architecture to operations) are not involved in estimating and planning
- Problems are identified too late (delays, mistakes, “not right the first time”, etc.)
- Employee turnover causes the teams involved in the project to lose expertise
- The end-user is only distantly involved
This is where Oobeya can help. Oobeya is a learning method: teams learn to evaluate the voice of customers, see problems as soon as they arise, resolve problems quickly and efficiently in order to protect customers, create and use standards that improve quality and remove variability in their process, and collaborate with the whole organization. All of this contributes to developing knowledge about our own work. Smarter, more motivated professionals make better products faster. If the team is already agile, Oobeya can increase the team’s velocity and give them the tools they need to match their pace to that of the customer.
Companies such as Nike, Amazon, BNP Paribas, Nokia Siemens Network, Toyota and Thales are using the Oobeya method to release higher quality IT products faster, both internally and to the public. The CIOs and directors of these companies say that they get better visibility on project activities and problems, so they can provide support where and when it matters most. They also say that they receive fewer complaints from customers, and that their managers are more proactive in addressing risks and issues.
The Oobeya approach
An IT product goes through a series of transformations (a production line) just like a hamburger in a restaurant: from an idea to a set of features to mockups to test cases to code to data sets to prototype to an application on a server. An agile project will go through these steps many times for a single product, which is one way of breaking big problems down into smaller problems, much easier to address. However, problems that jeopardize a project can arise at any transformation step, and in IT they are very hard to see.
You might say that developing software has nothing to do with making hamburgers, because there is a lot more room for creativity, complexity and changes. There is also room for more problems, hence the need to make problems visible immediately.
Oobeya uses a four-step process:
- Visualize production to reveal problems,
- react immediately,
- and resolve problems one by one,
- thereby improving your working methods.
This is not a one-time affair, but rather a system to be applied every day in the field. The repetition of all 4 steps, in that precise order, is the key to developing new reflexes and practices that will continuously improve a team’s operational effectiveness. The speed of improvement depends on the number of times they repeat these steps.
A spirit of collaboration is absolutely crucial to this approach, as problems often concern more than one person.
1. Visualize production to reveal problems:
In an IT project, there has to be a system to visualize the production flow. The lead engineer and the project team start by building their Oobeya room with the following elements:
- Project Objectives describe the project background and vision.
- Voice of the Customer describes customer preferences, the basis for product design.
- Target product describes the final output and also shows the current state of the product.
- Performance Indicators translate project objectives and the voice of the customer into 3 to 4 key indicators (customer satisfaction, quality, time, cost).
- Macro Plan aggregates all the project’s key deliverables and milestones.
- Problem Solving lists all ongoing problems and documents how they are being resolved.
- Team Production Monitoring shows the flow of production for each team.
The elements of the Oobeya room will evolve over time, some more frequently than others, except for the Project Objectives which serve as the north star of the team. For large projects or distributed teams, the production monitoring boards may be set up in the individual teams’ offices rather than the Oobeya room.
2. React immediately:
Representatives from all participating teams meet in the Oobeya to synchronize activities and deal with problems before they can compromise the project objectives.
Oobeya meetings are run by the lead engineer, and include a representative from each core activity (research, development, QA, operations, etc.). The lead engineer provides a clear vision and direction for the product, keeps track of performance indicators, ensures that schedules are followed and deadlines are met without compromising quality, and trains people in resolving problems as they arise.
The Oobeya is not exclusive to a business activity or particular context. In an IT project, the leader of the Oobeya could be the IT director or a project manager, as long as they take full responsibility of the whole process and the quality of the product. For a small to medium-sized software development project, the only other participants might represent marketing, development and operations. For a large project, the number of contributors could be 3 to 4 times larger.
The Oobeya is visited frequently by the project team
to keep everyone on the same page. The team meets:
- At least once a week to check on progress, identify, address blocking issues, plan the following week and share lessons learned from resolved problems.
- As needed, to resolve a show-stopping problem together.
Each project team also meets every morning for fifteen minutes (a “flash meeting”) in front of their own visual management and production monitoring boards. Team members share their issues and plan actions for the rest of the day.
Outside these meetings, anything that visibly blocks the production flow is handled as fast as possible. When a team member encounters a problem, they either try to fix the issue with the help of their manager or move it from the production flow into a “red bin” for later analysis. Common IT issues include defective inputs (e.g. incomplete or unclear specifications), technical problems (e.g. a tool not working properly), a competence gap (e.g. ‘I am struggling with this part of the code’), or an unexpected emergency like a production incident on an existing system.
3. And resolve problems one by one:
Did the actions taken by the team to address issues restore the production flow? What lessons do they draw from the resolution? Is there anything they can do better to prevent this specific issue from recurring? These are the questions that a lean team asks itself right after it has managed to put out a fire. It is tempting to resume work and forget the issue at this stage, because enough time has already been lost. This is a mistake: the team will continue resolving the same problems over and over, and will never get themselves out of firefighting mode. If anything, their situation will get worse because the number of recurring issues will grow as the project progresses.
In an Oobeya project, problems are tackled one by one following the Plan-Do-Check-Adjust (PDCA) process. Made popular in the 1950s by Edwards Deming, the PDCA is an iterative problem-solving methodology inspired by the scientific method:
- formulate and measure the problem,
- observe the problem in the field,
- brainstorm possible causes as a team,
- experiment locally, on a small scale,
- measure results, validate a hypothesis,
- draw conclusions, change your working practices or the work environment, and begin again.
You have to go through one PDCA at a time to resolve (eliminate) a problem, so that you can really learn something from it. Launching one action at a time to confirm a hypothesis helps you understand which action has actually borne fruit. This makes it easier to decide which practice needs to be standardized to prevent the problem from recurring.
4. Thereby improving your working methods:
This step corresponds to the “A” of the PDCA. In this case, “adjust” means that the team learns an actionable lesson from their problem-solving and then shares it with the project stakeholders. From these lessons emerge new ways of performing specific operations in order to improve the production flow. This success in turn improves the work atmosphere and develops mutual trust among the stakeholders.
A new practice generates a new standard, which is then shared with the rest of the team via a “training dojo”. It is not sufficient to write the standard and upload it on a shared drive. Pushing new information does not guarantee that people will find it when they need it, or remember that it exists. Standards are best used to train people (current team members and new ones) one-on-one in the workplace, not in a classroom.
Standards evolve as new cases appear and new problems are resolved. This transformation from specific solution to generalized standard to workplace training is what guarantees continuous improvement.
Below are examples of new work practices that teams may put in place following PDCA:
- A software engineer creates a new standard for versioning code that is understood by everyone, in order to save time when the team needs to find a particular version to roll back to.
- The product owner of a Scrum team writes a quality checklist for ensuring that user stories are clear and complete, to avoid too much back and forth during the sprint. Such checklists are even more useful for distributed teams.
- A team in charge of deploying new product versions into production sets up a new way of prioritizing requests to ensure that they work at the same pace as the upstream teams.
Oobeya in practice
This section gives three examples of project teams who have successfully implemented the Oobeya approach.
The first is a 10-person web application development team whose purpose is to manage projects with less than 4 months of lead time. Their 3000 clients are the back office of a large bank. Their projects are small but important and valuable to the business. The team has a backlog of ten projects, and most of them have already exceeded the required 4-month time frame. The clients are furious, and keep complaining to the CIO and whoever wants to listen. Let’s call them “the Webteam”.
The second team works for a large telecom operator and is scattered. They integrate new marketing offers into their main client’s mobile platform. There are many delays and quality issues, and the client is threatening not to renew the contract. This would be a catastrophe. Let’s call this team “the Telecom team”.
The third team is in charge of developing innovative applications for the R&D department of a pharmaceutical company. The team is spread over 3 countries. Its end-users are chemists and biologists involved in creating new pharmaceutical products. The IT team does very little in-house development, mainly working with external software providers. A few projects are managed using Scrum. Their main problems are long delays and poor quality of deliverables, sometimes with critical impacts on the business. This generates frequent complaints from the business. Let’s call this team the “R&D team”.
Each of these teams followed the Oobeya approach, hoping to get themselves out of a sticky situation. Here is how they did it:
1. Visualize production to reveal problems:
The three teams started their Oobeya projects as follows: they defined their project objectives and the “voice of the customer”, analyzed the project backlog, built a new macro plan, and invented performance indicators describing customer satisfaction, speed of delivery, defects, and budget. All these elements were created by the team collectively, during their Kaizen workshop.
They also added a problem-solving sheet to the wall, which filled up very quickly. Little by little, the teams added other useful elements to their Oobeya such as “red bins” to highlight incidents and defects, taskboards and kanbans to better manage capacity, and a “suggestion box” to solicit improvement ideas. In addition, the Telecom team decided to facilitate collaboration by co-locating some members of the project team who were working on different floors (integrators, developers, and testers, all members of separate functional teams).
The materials of an Oobeya are cheap and easy to use (post-its and paper board). The photos below show the first versions of the Oobeyas built by the three teams. They have all evolved considerably since then.
The Webteam
The Telecom team
The R&D team
2. React immediately:
The Webteam immediately writes down every incident that occurs in the test and production environments on a red post-it, and places in the “red bin”. These problems are addressed with the highest priority. In the images below, two production incidents have been moved from the red
bin to the development task board and will be tackled by the next available developer, with the full support of the team leader:
The Telecom team wants to drastically reduce the number of defects they deliver to the customer. Each defect impacts up to two million end users. Each one is written down on the quality board as soon as it is reported, and the team immediately performs a QRQC (Quick Response Quality Control). This is a lean tool for resolving complex quality issues like technical bugs. QRQC asks the team to form at least 7 hypotheses for the cause of the problem, and identify ways to test each hypothesis quickly. Any confirmed hypotheses are soon acted upon.
The R&D team reacts immediately when a risk of delay or an actual delay on a project milestone becomes visible on the macro plan as a red triangle. These problems emerge during the project team meeting. Every participant states whether his weekly milestones have been reached or if they anticipate delay. The Oobeya leader challenges each person: what is preventing you from delivering this milestone? Their issues are written down on the whiteboard and if the problem is considered a risk for the project, the team begins a PDCA after the meeting.
3. And resolve problems one by one:
In the example below, the Webteam has noticed several delays in one of its project schedules (top). They formed a hypothesis: “We don’t understand the client’s specifications, and have to wait a long time for clarification.”
In the bottom photo, the team draws a cross each time a delay occurs and can be attributed to this possible cause.
After a series of local experiments trying to improve their process for collecting and understanding client requirements, they succeeded in removing the problem almost completely. The turning point is obvious (black vertical line), and confirms that the team found an effective solution.
The Telecom team analyzed its production defects placed in the red bins and realized that most of them were due to errors in the network preparation scripts. After several experiments to fix the errors and rewrite the scripts, the number of defects started decreasing. After 1 month, they were practically gone:
The R&D team quickly realized that they had a major capacity issue, which was one cause of the observed delays. Team members kept complaining about being overburdened, but no action was ever taken because their workload was not visible. A simple “kanban” was set up for certain team members, which allowed them to quickly identify peaks and level their workload on their own.
4. Thereby improving your working methods:
After completing several problem resolution cycles, the three teams learned many lessons and changed their working methods in response.
For example, the Webteam radically modified the way it collected information on client requirements by analyzing the problem of missed milestones. The team now follows a simple yet precise process to handle client requests with templates and quality checklists. They created these tools themselves and refined them in collaboration with their clients.
The Telecom team created new script standards to secure network preparation, and trained all integrators involved in the project.
The R&D team leaders adjusted their management approach from being fire marshals who rally the team when there is a crisis to being PDCA coaches who encourage the team to continuously resolve minor problems before they get out of hand.
The results obtained in a few months are nothing short of spectacular:
In two months, the Webteam managed to deliver 11 applications with 0 defects. They were able to perform a release every 10 days which was sufficient to meet their client request (in lean, we call this frequency the « takt time »). Client satisfaction went up 61%.
In one month, the Telecom team succeeded in reducing the number of defects per delivery from 3 to 0 and the number of delayed deployments from 10 to 0. Eventually, the team started making money again and the contract with the client was renewed.
The R&D team increased their customer satisfaction by 30% in less than one month. The CIO of the company explained that customers were stopping her in the cafeteria to congratulate her teams for carrying out frequent satisfaction interviews and delivering better service.
The conditions of success
As a dynamic and collaborative approach to project management, the Oobeya boasts numerous and obvious benefits. It promotes and develops teamwork, allows the team to notice and resolve problems rapidly, and is an invaluable tool for first controlling and then reducing the lead time of projects. However, even after a team has begun to reap the benefits, they often have difficulty incorporating the Oobeya into their daily routine.
The teams succeeded in adopting the Oobeya for several reasons. First and foremost, we can point to the immediacy of the initial results. In one to three months, they managed not just to meet their objectives but to exceed them in some cases. They learned to identify “good problems”, a decisive factor in the success of any Lean approach. However, to guarantee the long-term sustainability of any lean practice, other conditions must be met.
The first condition rests on the notion of managerial challenge. The CIO and the managers in all three examples visited the Oobeya on a regular basis, in order to challenge the teams on their performance and support them in the resolution of operational problems. By challenge, I mean making the team think by asking the right questions about their performance and improvement strategy. Another benefit is that managers are able to understand the real difficulties that people encounter on the field. This helps them make the right decisions to improve employees’ work conditions. Regular visits from management provide the essential support and motivation for teams to achieve continuous improvement.
The second condition is that the teams were able to adapt lean to their particular situation, taking ownership of the approach. In effect, each team implemented their own version of the Oobeya. They chose their own piloting tools and performance indicators, developed autonomy in resolving problems, and acquired a sense of innovation. The teams learned to “go and see” their clients to better understand their needs, but that is only part of the story. Above all, the teams developed leadership skills that gave them the reflexes to fight not just for their projects, but also and especially on behalf of their clients.
About the Author
Sandrine Olivencia is currently a Lean Coach specializing in IT project management using Oobeya with Operae Partners. She is co-founder of the online lean community with Michael Ballé. She is co-author of the first French book on Lean for Agile teams. A board member of the French Agile association for 3 years, Sandrine is also the organizer of the Lean IT Summit, and XP Day and Agile France conferences. She has extensive experience as a software developer, IT project leader and agile coach for a variety of companies in the US and Europe.