At the company I worked, they had a 6 step version of the PDCA so I used that. If I remember correctly, the first step would be go to the Gemba. Another one of the steps was Act split into two or something like that. I’d then prioritise which improvements would have the biggest impact for the team and work on those. Though step 1 was initiatied during the weekly 1:1, the remaining 4 happenned throughout the week through Slack conversations. Step 6 was a weekly/monthly/quarterly review of all changes to the process depending on the impact of the change. The company also recommend the use of SMART goals for the quarterly goals so we used that for each improvement.

Initially when someone had an idea to improve, they thought they needed to ask for permission. Rarely did anyone come up with an improvement that didn’t need my support as the manager. I assume it was because amongst other reasons they thought it’ll take time and cause a delay or it might have negative impacts. The smaller the change and negative impact, the less likely one is to ask for permission before trying something. If it becomes infinitely small, which is basically the status quo, nobody asks permission to keep working the same way. If they felt they needed to ask me for permission it was too big a change. I told them a kaizen is making a change so small that it barely registers as a change. So I’d sit with early adopter volunteers and see how they worked and initially make suggestions myself to demonstrate what I meant by a small change. If there was something they could do without automation, that was fine too.

An example of a non-automation improvement had to do with a full-stack or generalist tester. In the entire team, each individual only tested one component. If an end-to-end test was needed, it required co-ordination between team-leads of those teams and their testers. If that’s not already a waste of time, there was a duplication of testing efforts. For example, to adjudicate a claim you need to setup data in one component and adjudicate it in another. So one tester would test just data setup. Another tester would then use the same component to setup their data to adjudicate the claim. If the helpdesk app tester had to test a change to that app, they’d do the job of the first two! Gradually as the language was developed and there was less assumed knowledge needed for writing or executing test cases, an individual could test all three components. This eliminated the need for meetings or the duplication of test steps.