Applying 5S to everyday life

What if I told you that you’re most likely applying 5S principles naturally and daily at home without even realizing it?

Don’t you see how?

Maybe if I asked you how you organise your food or dishes? For example, I’m sure forks have a specific place in your home, as do plates, glasses, knives, etc. You have identified specific storage spaces for each of these items, and if a spoon accidentally ends up where the forks live, you think something has gone wrong, and you’ll probably put it right fairly quickly. Similarly, you wouldn’t put a dirty fork away among the clean ones.

Think about this the next time you put away your cutlery and crockery; look at each thing you do, and try to link it to each of the 5S steps.

Managing a Product Backlog with 5S

5S is fully applicable to managing a backlog, or to reorganising it when management has failed. I personally introduced 5S in my professional sphere to achieve this goal. The most recent time I used it was on a backlog consisting of more than a hundred items, not all of which were defined according to the same nomenclature, with or without descriptions and containing obsolete or important tasks… the operation required the input of a good part of the team and took a whole day.

Obviously, before you try something similar yourself, I’d advise you to bear in mind that it’s really not a great idea to start 5S from scratch on a regular basis, and that you need discipline to keep the system in perfect working order. So it’s important to ensure that the people concerned understand that this process is costly and painful, but becomes irrevocably necessary once the disorder has been allowed to develop.

In short, this is the strategy used, hand in hand with 5S, to effectively impose order on a backlog:

Seiri: remove the unnecessary. For example, although this may seem brutal, we can set a date upon which we consider the items in the Backlog to have become obsolete, and archive all items older than this date (for example, more than a year): items that are genuinely necessary will come up again in daily business, and it will be easier for us to assess the cost/benefit ratio of dealing with them. To be less brutal, you can also go through each item one by one with a representative of the client or the users; or, failing that, with a team member who understands all the complexities of the business… but this can quickly become time-consuming, which is why I recommend mixing these two approaches.
Seiton: Set things in order. Once the first step has been completed, each item will be reviewed again in order, if necessary, to place it in the right Backlog (assuming that the initial Backlog relates to several products), and prioritise the tasks between them. If there is no way of quickly and easily establishing a business value and/or story (effort) points, it’s a good idea to rank the items you know most about first, and the vaguest items last.
Seiso: Make it sparkle. Next comes the cleaning phase, the aim of which is to make it easier to detect anomalies and correct them if found. Personally, I use this stage to add any descriptive elements that may be missing, and rewrite the item in the form of a User Story if necessary.
Seiketsu: Standardise. This can, for example, be done (by a Product Owner, who has sole responsibility for the Backlog) by setting up labels and filters, addition rules (by default, items are added to the top or bottom of the Backlog), rules for prioritising items, a buffer space for any item that is not ready (be careful, however, that this does not become a second Backlog, so make sure that the life of each item in this buffer space is as short as possible), a Definition of Ready, or any other adjustment that you deem necessary. Beware: standardisation must be kept simple, in order to ensure that it is as simple as possible to comply with it.
Shitsuke: educate. For the last step – which, in my opinion, is also the most important one – you need to explain how the Backlog works to everyone who needs to see it (team members, but also other parties such as managers and decision makers). The best thing to do is to start by noting the failure and constructing the standardisation rules with the relevant parties to ultimately produce a solid practical proposal (using visual management, for example, which makes the management rules understandable at a glance, or perhaps automation, so that you don’t even have to think about them). This proposal should not be set in stone: continuous improvement must of course be encouraged, but we must remain vigilant about the strict application of 5S and therefore of the jointly determined rules, even if this entails an evolution over time as experience is gained, in order to avoid any drift that would lead to the failure of the 5S system.

Why isn’t our 5S working?

It often happens that the application of 5S lasts only for a short time before we return to our good old disorder: because chaos leads to chaos, it only takes one small exception to the rule and all the good work of 5S can be destroyed in a few moments. For example, the small User Story that doesn’t get properly filed in the Backlog, because we say we’ll do it “later”… and unfortunately, this means it will never get filed because, as Leblanc’s law stipulates, “later” means “never”.

This most often happens because the 5S process has not been completed. Following the fourth step of standardisation (Seiketsu), many people will stop there and say that they finally have a tidy, practical backlog or workshop to use, ignoring the step that I think is the most important: Shitsuke, or education (self-discipline) about working practices. Because this stage is neglected, for reasons of budgetary constraint or because it is not considered necessary, it inevitably leads to the return of disorder (a User Story that is not placed in the Backlog, followed by a second one because there was already one there, etc.). Note the following regarding the Backlog (as an analogy with Agile frameworks): Scrum requires a Product Owner, which greatly facilitates the last and most difficult stage of 5S, since the Product Owner is the only one who takes action on the Backlog and therefore ensures that 5S is applied. Remember, however, that Scrum requires that the content of the Product Backlog must be publicised sufficiently clearly to all concerned (Scrum team, but also stakeholders), so it is important to ensure that, despite the fact the Product Owner bears sole responsibility for the management of the Product Backlog, the standardisation of the backlog is still the result of a shared process based on collective intelligence.