How to better balance resources in a cross-functional agile team?

Question

I am the project manager for a team composed of employees who were hired specifically as QA or development prior to agile/scrum being adopted by the organization. Just for background, I came into the organization after the implementation of scrum.

The problem we're having is at various times during a sprint, team members will announce that they have no work to do. There are still many items that aren't "done", but either someone is already working on them or they're not in the phase that person feels they're responsible for - developers have no work because everything is in QA or vice versa. Previously, they would just pull more items off of the product backlog - no team commitment, no discussion, they were allowed to just pull something else in to the sprint. That, I put a stop to immediately, explaining by doing that they were committing to things for everyone else on the team without asking them first. I should also mention that the team rarely meets their original commitment set in planning, let alone the extra items pulled in, because things get stuck in phases even though there are team members claiming they have nothing to work on.

The idea of a single team working together to get everything to "done" has been explained to them, but developers say they weren't hired to do QA and QA says the developers just get in their way when they try to help on QA tasks and they don't understand how to properly test from a QA perspective. I've also explained that developers don't necessarily have to test and testers don't necessarily have to develop, but that the entire team should be working (through self-management) to either get committed items to "done" or doing something to benefit the team in the future (updating docs, maintaining the build/CI systems, improving automated testing, etc.) Regardless, we still get team members saying they don't have anything to do and want to pull new items in from the product backlog.

I feel that what they're really saying is: 1. There's nothing left in this sprint that I WANT to do. 2. I really want to get a head start on that so I have less work to do next sprint.

As a project manager, none of the team members directly report to me. I have discussed this with their managers individually and while they agree this is a problem, they feel that they can't force this.

The most direct result of this is that QA is constantly behind. When we start a sprint there are already several items ready for QA. While they work on these items, things keep piling up and at the end of the sprint we've got a giant set of items in QA and developers saying they have nothing to do. Of course with items not getting finished in a sprint, the next sprint comes and the problem keeps getting slightly worse and worse as QA can't keep up.

Does anyone see any course of action here? Thanks in advance.

Answer 1

I don't think there is going to be an easy answer to this question.

From my perspective, the critical factors are:

1. Team is not meeting the development goals
2. QA runs late, but does not want help from developers as it is currently offered/supplied
3. Developers complete the work that they perceive is necessary, and don't perceive any need to do additional work.

I've got a couple of questions:

1. What are the consequences of the slipped deadlines and the technical debt from QA? Have you assessed the impact of this problem on the ultimate deadlines?
2. What feedback are you getting from your stakeholders? Are they content? Are they upset enough at slipped deadlines that they'll support changes? Will they communicate that support to the line manager?

If I were in your shoes, I'd assess the consequences first and make sure that the stakeholders feel enough pain to support some changes. (if not, then we need to discuss a different problem).

Then I'd start to measure technical debt. On an average slip we slip x QA tasks; the average QA task takes X hours to resolve. Build a metric brief stakeholders/line management on that metric weekly/monthly/(period appropriate to your sprints).

Now we need to change the attitude of the developers and the testers. They're not working together as a team. First, we need to make sure that we, the PM, have provided motivation/leadership. Have we communicated the value of working as a team? Are there incentives for team-play?

QA needs to change their attitude. QA doesn't like the help that devs provide; that's fine, either teach them how to provide helpful help, or tell the PM to get them training that will enable them to provide helpful help. Ask QA if switching to test driven development would help? QA apparently has some processes that need improvement. Pull one QA and a couple of devs offline and ask them to redesign the QA process so that it is (a) faster (b) facilitates effective teamwork and (c) more effective. Ask the devs which QA person was the easiest to work with? Which QA has the best code-fu? That person has skills that need to be transferred to the rest of the team.

Devs don't want to do QA? That's fine. Work with line manager to obtain devs who have the right skills and want to work as a member of a team. Ask the QA dept, "Who was the most helpful dev this sprint?" PM can recognize that individual and make sure that line management knows that you value this person as a team player, and will want this individual on future projects. This dev's behavior is directly tied to your projects ability to meet deadlines and stay within schedule/scope/quality.

Ultimately, the only tool you've got is your stakeholder's desire to meet the deadline. Slipped deadlines create pain for stakeholders; your job is to redirect that pain in a way that will motivate change.

From what you've said, you've got a significant problem that needs changes to motivation, skills, and processes. The particular details of your situation will make those changes at least an order of magnitude more difficult than what I've blithely described above. If it were that easy, you'd be earning minimum wage.

Make sure that your stakeholders know that there is a problem, that you're taking action to solve it, and that you don't expect that the problem will be solved this sprint, or next sprint. The best you can promise them is that the rate of growth of technical debt will slow by x% every sprint.

Answer 2

The most direct result of this is that QA is constantly behind. When we start a sprint there are already several items ready for QA. While they work on these items, things keep piling up and at the end of the sprint we've got a giant set of items in QA and developers saying they have nothing to do. Of course with items not getting finished in a sprint, the next sprint comes and the problem keeps getting slightly worse and worse as QA can't keep up.

Another way to look at this is that your developers are constantly ahead. In either case you are over-resourced in terms of developers and/or under-resourced in terms of QA.

You can resolve this by changing the resourcing levels. Talk to your project sponsor and find out how important the overall schedule of the project is from a business perspective. Based on that, get your sponsor's agreement to either:

• Give you additional QA resources so that you can maintain or improve on your current pace by helping QA catch up to the developers; or
• Redeploy the excess developers onto other projects so that your QA can keep pace with your developers, though there is a risk that your project may take longer to complete.

Answer 3

Unfortunately, you are facing one of the bugs in Scrum. By default, it assumes that people are eager to work together regardless their previous roles or ambitions, and they are more than happy to give these up for the greater good. I'm not sure that a generic solution exist, but here are some ideas:

If you want to keep Scrum

1. Most probably the team has some issues with understanding the basic principles behind Scrum. The recommended solution is to coach the team and be patient, and temporarily try to live with the current situation until those principles are understood.

2. There is a good chance that the developers are faster than the testers, so you can remove the unnecessary testers and use them somewhere else, or you can create two teams from the current team. With this approach you create an artificial bottleneck - the number of testers -, which will provide you more information about the situation.

3. Talk to your Scrum Master, because she is the one who should escalate this problem and try to come up with solutions and coach the Scrum Team. Something isn't right here.

If you want something else than Scrum

1. I've seen setups where there were two shifted iterations: one iteration for development and testing and one just for testing - this one started later. The idea was that the developers overcommit and did more work than they can test in an iteration, and the additional work had been tested in the testing only iteration. This wasn't an optimal solution, but everybody got something to do and the team(s) delivered - the fully tested user stories were demonstrated to the Product Owner.

2. You can start learning a bit more about Scrumban, and slowly switch from an iteration based approach to a continuous approach like XP + Kanban.

Answer 4

There is already an excellent answer from Mark C. Wallace but I thought I'd add one more thing.

Try to balance the system a bit by using work in progress limits.

At the moment, dev is producing work at a faster rate than QA can test it. Try set a work in progress limit on the dev process that will feed work into QA at a rate they can complete it, you will avoid having loads of work backing up in your QA stage. You can also add a work in progress limit to the QA step so it's clear when QA is overloaded.

For example, if you have 4 dev pairs, try setting a work in progress limit of 3 on the dev step and a work in progress limit of 2 on the QA step (1 being worked on, 1 queuing).

This will mean that your devs will have slack time since only 3 pairs can be doing dev at any one time. This might seem like a bad idea but it's generally better to leave slack in the system rather than to keep producing work that then can't be kept up with by downstream steps.

The devs on slack time could be looking at things like removing technical debt, spikes, live support, analysis on stories coming up etc that are still productive but won't clog up the QA step.

Also, by forcing them to do nothing to contribute to the sprint while their colleagues are all working their proverbials off to complete stories, I'd hope that professional integrity would encourage them to get stuck into helping out with some test!

Answer 5

An excellent set of answers so far. I just want to add this:

I recommend the book How Google Tests Software. This quote sums up their goal for balancing development and QA:

Quality is not equal to test. Quality is achieved by putting development and test into a blender and mixing them until one is indistinguishable from the other.

This has been my experience. In my role at YouView where we were building the UI for a Set Top Box we had an excellent test team but until we made them part of the development team; working with them in Specification Workshops before development begun and releasing functionality to them early and often for feedback we had a similarly dysfunctional relationship to the one you describe.

Getting the right collaborative relationship between developers and testers has in my experience been fundamental to raising to quality of the software being produced.

Answer 6

I wonder how sophisticated your automated testing facilities are. If not particularly good, then there may be a real benefit in investing time and effort into this area, as the payback will be rapid and substantial. You indicate in one of your comments that you have a month long regression testing period before every release: this sounds very significant indeed, and although I don't know your environment, it seems that if this could be reduced, through aggressively automating your test cycles, you would reap real benefits.

In his book "Agile Project Management", Jim Highsmith talks a lot about "ruthless automated testing", and states "Experience has shown that the biggest difference between mature and immature agile teams lies in their commitment to ruthless automated testing". You may not entirely agree, but it is worth considering the implications of this statement.

Another topic from the same book refers to getting the right people. It's a hard point to make, and harder to follow through on, but you seem to have some issues with your people. Maybe that's another key area on which to focus, at least in the short term.

Good luck...

Answer 7

I think you'll find that this is a structural problem and not related to individual attitudes or understanding of scrum. Whenever I have encountered devs who won't do testing, testers who want the code handed to them on a platter, and so on, it is because they are doing what they are told or what is implied by the circumstances of their employment.

If devs don't want to test, it may be their manager or the company culture. "Devs cost more than testers so they should be developing not testing." I have heard this said by the devs themselves, by their manager, by project managers, and by senior executives. "QA is ultimately responsible for quality." I have heard this said by testers, by their manager, by project managers, and by senior executives.

Until your development organization's senior leadership (and higher) can commit to a team-oriented organization, you will be fighting this battle.

In your case, the staff managers seem to be sympathetic. In that case, I'd suggest testing their support... ask them to reset expectations of all staff towards more team-oriented collaboration rather than individual role-fulfillment. You get to itemize the expectations, and they sell it. Or if not, you gotten closer to the source of the problem and may have other resources available for addressing it there.

Google tests the way they do because their culture reinforces agility from the top down. Most shops I've worked in or coached don't have that luxury -- we wind up pushing agility up the organization. It's slow but sometimes it works.

As my own coach Richard Lawrence, has said: first try to reach the milestone where the team consistently delivers what it commits to. Then build on it. I will add that it can take quite a while to get even there.