As Scrum Masters, the Scrum Guide tells us that we serve the Product Owner by ‘Finding Techniques for effective Product Backlog management.
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.
As Scrum has started to cross the borders of a single Scrum team and to large products and (non-Agile) organisations, a more comprehensive approach to creating a backlog is needed too.
Please Note: Scaling and Lots Of get 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 actually rare) situation that you have a single, irreducible backlog, you presumably need to address that as well. The obeya is a technique for visualizing 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 personally use this technique for the high-level management of a company. Although many of the elements of an obeya can be used 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 compartmentalizing 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 right.
The left wall is for visualizing 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
A metaphor of a company vision in LEGO
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 success for us?
What is 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 answer these questions using metaphorical games like serious LEGO(r) or with a visual metaphor:
metaphorical strategy map
Value Stream Mapping
Another practice that comes straight from Toyota is the Value Stream Map. A value stream is anything in the path from 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/or 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 really 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:
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 are not measuring only ‘trailing’ indicators: e.g. quarterly profit because you will be too late.
financials (turnover, gross revenue, 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 own 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.