Improve Design Team Collaboration: A Beginner’s Guide to Setting Up an Obeya Room
By John Drogosz, PhD
Most organizations on their Lean Product and Process (LPPD) journey gravitate early on to applying the practice of obeya. When we see an obeya that is well established, we can see the appeal. The team is engaged, the project activities and status are clear, and people are working together in real time on the issues that matter most to the customer and the organization. However, most teams will say it took them some time to hit their stride with this way of working.
If you and your team are getting started with obeya, the first piece of advice is to not overthink it. Just get your space up and running and be ready to make adjustments over time. That being said, below are a few tips to help you up the learning curve.
1. Use a space that is available and accessible to most of the team. Ideally, a dedicated room where the team is co-located works best. However, many organizations have had to adapt to physical constraints in their environment (and distributed teams — more on this in the other Design Brief article).
2. Keep it simple. Less is more when it comes to visual management. Most teams struggle at first with what to display and tend to cover the space with everything they are doing and frequently get lost in the details. The visuals should be the ones that help the team achieve its goals. Each team member should ask themselves: “What do I need to know from others? What do they need to know from me?”
3. It is a team sport. Everyone needs a space; everyone shows up and everyone speaks to their activities and issues.
4. Cadence is key. Obeya rituals should be designed around the specific needs of the team. Some examples include:
· Daily standups to surface key issues and provide team members with help;
· Weekly obeya gallery walks for the team to see the big picture;
· Weekly focused topics -– cost tracking, key decisions, design reviews;
· Monthly — Pulsing with key stakeholders on project goals and trajectory.
5. Remove other meetings and status reports once you are in the obeya.
Build obeya; build the team
If you are pioneering obeya at your organization, then hopefully the above tips will help you. The best way to learn obeya is to “go and see” others. One multinational company I worked with, strongly encouraged each new obeya team to first go and see a team experienced in obeya. Visiting was not just looking at the walls to copy the displays but actually attending some meetings to get context and see the team dynamics of how obeya is different from traditional team collaboration.
As you build your obeya, you are also building up your team. As with any sport, a team improves with time and thoughtful practice. Most teams take six to eight weeks before the obeya becomes the new norm, and the team starts feeling the benefits for themselves.
One team I coached had a bumpy start as it struggled to see how obeya was helping it. The members had worked together for years and had some well-established rituals yet their performance from project to project was mixed. In the early obeya stages, they went through the motions and some people said, “Why put this stuff up on the wall, we have it in the system for anyone to see?”
That perspective changed about a month into the project when their customer came to visit them, and they held their meeting in the obeya. During that session, they walked the walls with the customer lead, and he stopped when he reached the full-scale mockup of the product. He quickly saw that the clearance for the third-row seat was going to be restrictive. Several of the team members already knew this, and I saw them roll their eyes. It had been on the issues list for over two weeks, and nothing had been done about it!
Problem-solving: from two weeks to two days using obeya
The customer lead asked if they were sure about the dimensions and the team confirmed the physical model was precisely what was in the current CAD model. The lead went “Hmm” and they continued walking the walls. The skeptics in the team took this as a sign that the obeya had failed, and they would be rid of putting up visuals and go back to their usual project management work. However, a couple days later, the team received a call from the customer telling them that they had moved the fixed points for the third-row seat to give them more clearance. Two weeks on an issues list, two days in obeya! That was the inflection point for this team, seeing how obeya could concretely help it be successful in their work!
Another sign that your team is growing into obeya is when it moves from using it simply for reactive problem-solving to proactive risk mitigation. All obeyas have some kind of visual schedule. In the early stages, I see teams focused on what got done, what they are working on now, and what issues they have today. This daily/weekly blocking and tackling has its benefits. Teams that have matured into their obeya spend less time in the moment and are using it to look forward to anticipate risks and issues and mitigating them before they become real problems.
A telltale sign that obeya is seeping into the team culture is the level of activity happening in the space outside of the formal rituals. Obeya is meant to be a collaborative space for the team to informally meet to work together on the issues and challenges surfaced during the other meetings. This is valuable real estate, so make sure teams are taking full advantage of it.
Quick help at leader’s obeya “office hours”
One project leader was frustrated that the obeya seemed empty most of the time. She installed a touch screen to facilitate design reviews and video capabilities to collaborate with off-site personnel and suppliers. This helped increase traffic in the space, but it still was not natural for people to gravitate there.
Eventually, she moved into the obeya herself and set up daily “office hours” where she and the technical lead made themselves available for team members to drop by with anything they wanted to discuss. Team members reacted well to this as they knew they could get quick guidance. Eventually, this led to sub-teams coming in to work as they knew the leader would be there if they needed help. The utilization of the space went from approximately 15 percent to 80 percent in four weeks!
It has frequently been said that obeya is an andon system for a project team. Within the team, issues are surfaced and should be addressed there whenever possible. Organizations that have adopted obeya over time have effectively integrated it into their operating system. Essentially providing a help chain to teams when issues get surfaced that are beyond the team’s ability to deal with them so that they have a clear line to get the help they need. In fact, some leaders have created their own senior leader obeya once they have seen its value.
As you progress through your journey with obeya, it will need to evolve based on the project’s needs and the individual needs of the team members. Take some periodic pauses to reflect on the obeya (process and visuals). obeya is a dynamic environment, if something is not working, it is your room, so change it!
Obeya is a proven way to help teams improve collaboration, meet their goals, and accelerate time to market.
John Drogosz has over 25 years of lean manufacturing, product development, and above-shop-floor experience. As a coach, he has led lean transformations in numerous companies and industries, including Northrop Grumman, Johnson Controls, Areva, Peugeot-Citroen, Tenneco, Eaton, Hertz, Schlumberger, Harley-Davidson, Embraer, and Caterpillar.
As LEI’s chief engineer, process and product development, John leads the development of learning experiences that enhance design professionals’ lean development knowledge and capabilities while advancing the discipline’s body of knowledge. He codeveloped and is an instructor of LEI’s Designing the Future Remotely: A Lean Product & Process Development Immersive Learning Experience.
In addition, John teaches classes in lean product and process development and lean manufacturing for the College of Engineering at the University of Michigan — Ann Arbor. He also contributed to the Toyota Product Development System (2006) by Morgan and Liker and Liker’s book The Toyota Way to Continuous Improvement (2011).
