Obeya – An example of The Big Room practice for Scrum
OBEYA – AN EXAMPLE OF THE BIG ROOM PRACTICE SCRUM
Now that is all very well, however not very specific. The classic that people turn to are the practices of Mike Cohn, the most famous of which is the concept of the ‘user story’.
I am not going to go into that here; I suggest you read about making user stories elsewhere as it is (whether you like it or not) pretty much canon in Scrum these days.
Are you ‘scaling -’ or ‘lots of’ Scrum?
As Scrum has started to cross the borders of a single Scrum Team and to large products and (non-Agile)organizationss, a more comprehensive approach to creating a backlog is needed too.
Please Note: Scaling and Lots Of getting mixed up most of the time. They require a very different approach to backlogs. By Scaling, I mean that you have a single Product Owner with a single Product Backlog.
Lots of Scrum to me means that you have separate products or a modular product that allows working on it concurrently with practically no dependencies.
If you are in the unfortunate (and rare) situation that you have a single, irreducible backlog, you presumably need to address that as well.
The obeya is a technique for visualising governance and the flow of value. It will merely make a poor backlog or a rigid organisation more transparent. Solving that is a whole other discussion.
Who is this for?
I use this technique for the high-level management of a company. Although many of the elements of an obeya can be utilised at a team level, it may be rather overkill compared to a simple list of backlog items on a whiteboard.
However, that does not mean that it is only for managers: the obeya is expressly for getting all parts of a company into the same room and working together.
The Product Owner(s), and a representative from the production team(s) should have a short daily meeting the obeya.
I like to work with what I have started to call a ‘Studio Team’ that includes anyone that is involved with the value stream – so also sales, marketing, support, etc.. Roles that provide secondary value (e.g. HR or IT) are not necessary but welcome.
Anyone is welcome in the obeya and at the different meetings (but only members of the Studio Team speak at the daily meeting).
Obeya simply means ‘Big Room’ in Japanese. The approach is often attributed to Toyota, but I have no idea if that is where it first came into use.
The idea is to bring people involved with all parts of a production process into one place so that they meet face-to-face to improve communication and prevent compartmentalising or phasing work to homogeneous ‘departments’.
Take a big room, preferably a pleasant one that people like to come to work in, with a large amount of wall space for hanging stuff. I have also done this in a shared team working area – that has the advantage that everyone can see what is being done and what the current state is all the time.
The disadvantage is that sessions there are distracting to people who need to concentrate. A private meeting room has the opposite pros and cons: low visibility but not distracting.
The layout is in three parts, from high-level via medium-level to detail-level. This is both in terms of time as well as granularity. In a room with three available walls, you could move from left to middle to the right.
The left wall is for visualising the direction, the agreements and the constraints. It has the team/company charter, the vision, stretch goals and strategy.
The middle wall covers the current conditions and trends and the Key Performance Indicators.
The right wall deals with experiments and short-term tasks.
Presumably, you will change things on the left wall only a few times a year, perhaps at a mission review but also ad-hoc when team rules or the market changes.
The middle wall changes continuously, but it is useful to review it at least once per sprint as part of a retrospective.
The right wall changes continuously and should be reviewed at least once per day in a short meeting (similar to a daily scrum).
Try to build up your room incrementally and iteratively, don’t try and make a ‘Big Bang’ obeya. Do sessions of at most a few hours to build up each part of your obeya and refine them every sprint as needed.
Depending on how well-defined things are in the organisation, you can also consider building up your room in reverse: start with your experiments and work towards your vision.
The thing I like to start with when forming any new team is to facilitate the making of a team charter. This does not have to be much more than a wall full of stickies that have our ‘rules of engagement’. It has at least three sections:
- Roles – Product Owner(s – per Product), Facilitator (i.e. Scrum Master), Studio Members. Just like with a Scrum Team, it is important not to define roles to function. So no: sales, marketing, development, etc.
- Schedule – the team meetings: long-term meetings like quarterlies, sprint length, daily meeting time. Make these fixed-date/time and timeboxed for predictability.
- Rules – how to decide on things – like fist-of-five voting, how to engage – like ‘no one has a monopoly on the truth’ or ‘we want to learn from each other’, rewards and punishments – like ‘late = cake’ or ‘kudo system’.
Vision and Strategy
There are many ways to do this. I like to describe the vision by answering the ‘why’ of the obeya. ‘Why do you work at …?’.
The Strategy is more the ‘what’ and the ‘how’ of the work:
- How do we add value?
- What is our product?
- How do we cause our success?
- What is the success for us?
- What is the failure for us?
If possible, try to answer these questions collaboratively. Google will find you any number of workshops for ‘Company Vision’, ‘Mission Statement’ or ‘Stretch Goals’.
You can answer with sentences or a payoff. I like to respond to these questions using metaphorical games like serious LEGO(r) or with a visual metaphor:
Value Stream Mapping
Another practice that comes straight from Toyota is the Value Stream Map. A value stream is anything in the path from the discovery of a customer need to delivery into the customer’s hands.
There are three parts to the Value Stream Map:
- The Information Flow – the top part shows customer and supplier contact
- The Production Flow – the middle shows the steps in your stream
- The Time Ladder – this shows how long your product is waiting or moving in each step
The great thing about showing production in this manner is that it quickly becomes apparent that when you have a lot of steps or a lot or waiting between phases, where your ‘waste’ is. It also helps managers with their most common affliction: watching the runners, not the baton.
Key Performance Indicators and System Health
I make a split in a business’ activities between the secondary value system – which does not produce anything and the primary value system – which is anything that adds customer value. The thing that Scrum teams need is to be left alone when it concerns ‘how’ they do their work. Management should be about making sure there is a clear view of what is being built and the amount of value that is being added. But what do you measure?
Firstly, management needs to make sure that the secondary value system is optimal. Software development should not be slowed down because of computer problems or because developers are going hungry. These things I call ‘System Health’ and can be things like:
- Facility issues (like IT/Telephony/Air Conditioning) discovered
- Server uptime percentage
- Salary payment confirmation
- Lunch appreciation index
As for the primary value system: entire books and dissertations have been written on this subject – too much for a lowly blog post! Management should support efforts to spread knowledge through the company and transparently show the performance of the value stream. These numbers are the Key Performance Indicators.
- Watch out you are not partially measuring ‘waste’ like queuing or lead-time: e.g. time spent or man-hours per feature.
- Watch out you do not measure only ‘trailing’ indicators: e.g. quarterly profit because you will be too late.
KPI’s that I especially like:
- worker happiness
- faults/bugs that went into production
- lead time per production step
- user stories completed
- user rating/use/downloads
- heat maps/usage flow
- financials (turnover, gross revenue, the purchase cost of turnover)
That last one is contentious. I would argue that if you are going to measure financials per team or product, the teams MUST be able to make their hiring and firing decisions as that is the largest cost item on their budget.
A3s/Experiment board and Backlog
I like to use a simpler version of the Toyota A3 method, which is based on Deming’s PDCA cycle. Using the KPIs on the KPI board, the Studio Team designs experiments that answer the question: ‘What next step will help us achieve our goals best?’.
The team order the A3’s on a backlog, with the one thought to bring the most value the soonest on top.
The team identify a hypothesis per question and a failure and success condition:
Hypothesis: We believe that using a tabbed layout of our cart will increase conversion percentages.
- Success: increased conversion
- Failure: equal or decreased conversion
The team then describe an experiment:
Experiment: We will make a tabbed layout a beta test this on 100 users.
After the experiment, the results are gathered:
Results: The tabbed layout had a conversion percentage of 37%
The normal layout over this time had a conversion percentage of 28%
This then leads to conclusions:
Conclusions: This would suggest that a tabbed layout has an advantage over the ole layout. We should deploy for all customers.
This then leads to a new Hypothesis on a new A3:
Hypothesis 2: The new tabbed layout for the cart should lead to better conversion for all our customers
- I have seen a ‘process improvement board’ hung up next to the A3 Experiments. It wasn’t filled by managers but by developers and members of the Studio Team with bottom-up improvements.
- A ‘business Kanban board’ that tracks the Studio Team’s tasks.
- A ‘ready area’ and ‘field of dreams’ that show what items development teams have pulled into their sprints.
- An ‘idea board’ where anyone could present an idea for a new product.
- Live metrics with App Store downloads, five-star reviews and latest comments
Working with Me Or Evolution4all
I have developed the “Organisational Mastery” product. The aim of this product is to create a coalition that drives change and internal innovation alongside shared knowledge throughout the organisation. It’s extremely suitable for companies that want drastically improve the alignment between executive leadership and delivery teams.
We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.Take The Test