How to use Scrum when I have the QA working in two other projects?

One way to mitigate this problem is to focus on creating automated regression tests.

This will:

• Reduce your dependency on manual testing and hence on the QA
• Mean that each team member is capable of working on development or testing

In the short-term this may have an impact on the output from the team. But in the medium and long-term the automated regression test coverage will enable the team to move at speed and with confidence.

There are basically only two ways to deal with this type of situation: fix it or accept it.

Part time people on teams and/or projects cause major issues. You loose productivity because of constant context switching. You loose time because you wait for people to become available while they work for someone else's team/project. Your planning gets messed up because you plan on what you can see and have some control over (which is your own backyard, not someone else's backyard). Releases get delayed. Bottlenecks occur. Etc.

You can use Scrum, switch to Kanban, or use something else, but it won't make any difference. Your problem is not with the process you are using, but with the resources needed to keep that process running properly. So you can either fix it or accept it.

Fix it

Every team gets their own QA. Either you hire more people, or the developers pick up the QA tasks. This way you have no external dependencies, no waiting for people to become available, and no context switching. Each team gets what they need to be cross-functional and self-organize, which is what Scrum says you should do.

Accept it

If the company can't afford more people or you keep developers only on development tasks, and you have to share a QA, then everyone must understand that the whole setup is suboptimal and all those issues I mentioned above will occur. You accept that and try to figure out ways to minimize the problems. One way to do that is to plan together with all teams and then everyone agrees on when they can have access to the shared person, then respect that agreement. Of course this adds more coordination which in turns takes even more time, and you can always have emergencies or exceptions throwing you back in the same ugly situation you began with, but you need to accept that too if you don't want to fix it properly.

This is a classic challenge with teams starting in Scrum. Most teams are not used to working in this way and moving to these small product increments will have a few bumps in the road. A few things to consider that may help:

Timing and Availability:

You want a consistent sprint length and timing of events. If you have a 2-week sprint that starts on Tuesday, you should stay with that. This will allow people to adjust their schedules to match that. In the case of your QA person, you may want to make sure you are starting your sprint at a time that works best for them or they may been to block off the last few days as unavailable for other work. (I'll get to the multiple teams thing next)

Dedicated Team:

Generally speaking, dedicated teams are preferred when doing team work. What happens when we split people up onto multiple teams and efforts is that we lose time to context switching and schedule problems. Often, we lose more time to that than we gain by "efficient" scheduling of people. Studies have found that we lose as much as 20% capacity to context switching for each extra effort we split our time onto. That said, if you can't reach that goal just yet, the next best thing is to at least have consistent availability to plan around. This can reduce the negative impact of that multitasking.

Stop Starting, Start Finishing:

It is common that team members divide and conquer on a number of backlog items which are worked on over the course of the sprint, often passed to QA at the end, the hopefully wrapped up by the last day. This is often a stressful and frustrating experience for everyone. Rather, teams often find more success in rallying around a few (or even one) backlog item and moving them along quickly. In these cases, the average backlog item moves from start to finished in 2 - 3 days, meaning all members of your team are engaged throughout the sprint. Also, it means of one or two items don't wrap up, you aren't left with nothing.

Finally, a thought on Kanban

Every team I've worked with who used Kanban because they couldn't manage the constraints of Scrum actually had more trouble. While Kanban doesn't enforce a lot of rules, one of the things it asks us to do is measure and observe flow of work and it will spotlight those challenges that you are already seeing. If you aren't making changes to your process to address those flow challenges, you aren't getting anything out of Kanban.

There are a few things that I can see that are hampering you.

Scrum is a framework designed around a product being built and supported by a cross-functional, self-organizing team. Since you talk about projects and people working on multiple projects, Scrum may not be the best fit for you. Even if it "works", you won't get the full advantages if people are attending multiple different events from different Scrum Teams that they are supporting.

One option is to try Scrum as it was intended. Form a team around a single product or "project" and ensure that they are highly focused on that effort. Make sure the team has what they need in terms of knowledge, skills, and resources to do the work that's in front of them.

Another option is to abandon Scrum. There's insufficient details for me to give any reasonable advice on things to try, but most of the formalized Agile methods are around building projects around individuals, not moving individuals around projects - this is one of the underlying principles of the Manifesto for Agile Software Development. You may need to go back to project and product management foundations and roll your own, but even so, you may find that your organization is not of the appropriate size or structure to do what you want to do.