In my previous post I mentioned how to use end-of-iteration reflection meetings to determine what a team should focus on for improvement in the next iteration. In this post I want to briefly cover two different ways that a team can tackle those improvement actions.
In the first – and simplest – case, let’s say a team needs to fix a problem with their automation framework that is causing some instability. So far, the team has just addressed the immediate symptoms in order to get the automation back up and running, but there’s a sense within the team that the problem runs deeper and needs some focused effort. In this case, the team needs to set aside some dedicated time during the next iteration in order to solve this problem at its root so that it doesn’t keep coming back time and time again, and continually costing the team. Some teams I’ve worked with have simply written a user story and put it on their backlog of user stories to ensure that the dedicated time actually occurs. In this case, the story goes to the very top of the backlog – the team addresses it at the outset of the next iteration (since it’s now #1), fixes their automation problem, and only then starts working on the next story on their backlog. Whether you choose to write a user story or not is up to you – the KEY is that you set aside time to handle smaller issues.
The second case involves larger problems – problems that will take time to solve and that can be quite complex. A simple example of this may be that the automation framework that the team has been using for years may no longer be supported, and now the team has to move to a brand new automation framework. This undertaking isn’t going to be able to be handled in a day or two – even with the whole team focused on helping. Since there’s always pressure to get new features and functionality out the door as quickly as possible, the team most likely isn’t going to be able to hit the “pause button” for four weeks while they switch over to the new framework. What we suggest here is a bit of a compromise: create a small team of automation folks and dedicate them 100% of the time to moving the current automation to the new automation framework. The remaining team members continue to focus on new feature work. The important thing with this suggestion is that you’re getting your new automation framework implemented while still getting new feature work completed (albeit at a somewhat slower pace) – but you’re doing so without having engineers multitask across different sets of responsibilities. This approach honors the lean principle of working on one thing at a time.
Just to recap – if your tackling a small improvement action, dedicate time. If it’s a larger improvement action, dedicate a team.
As always, please feel free to respond with any additional advice, insights, experiences, and/or questions that you may have. Thanks!