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.

Interesting question - although it would help if the question were more clearly stated. This is in the cluster of questions that have to do with how the PM can effect change in employees when the PM doesn't manage the employees.
–
Mark C. WallaceOct 24 '12 at 18:14

Yeah, I wasn't really sure what to put for the title as the problem covers a few areas. If someone can suggest a better title, I'll edit it for future searches.
–
NightManOct 24 '12 at 19:34

3

A better title might be something like "How to better balance resources in a cross-functional agile team?"
–
Doug BOct 24 '12 at 20:01

1

Why don't you have dedicated docs writers in your team? What is the stance of your organization re: unit testing? (it seems that developers are not accustomed to doing unit testing)
–
Deer HunterOct 25 '12 at 20:08

1

This attitude from the devs is what really holds you up. Devs are shipping unfinished alpha product across the team and effectively undermine your efforts, scrum or no scrum.
–
Deer HunterOct 27 '12 at 5:42

6 Answers
6

QA runs late, but does not want help from developers as it is currently offered/supplied

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:

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?

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.

I'd upvote twice if I could. There are a lot of excellent advices in this answer, notably the "put together one dev and one QA and ask them how to improve the process".
–
Florian MargaineOct 25 '12 at 6:19

Good stuff. Thanks. 1. The consequences are that the team now has a month or longer "regression testing" period before every release in which they account for all the technical debt that has accumulated. So they don't miss deadlines, but the deadlines are all heavily padded by the team. 2. The stakeholders are accepting of their padded deadlines, but are not happy with the quality of the product. I feel that the team would not need to pad their deadlines and see increased quality if they could get into the spirit of agile development and see that they're all working toward the same goal.
–
NightManOct 26 '12 at 19:06

I'd be interested in hearing more about incentives for team play. I'm very big on managing with positive reinforcement instead of negative.
–
NightManOct 26 '12 at 19:08

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.

If I do that there will be political consequences. I'm the new guy and much of the team has been together for years. If I break some of them up, the team will just hate me. On the other side, QA already outnumbers development and QA management can't budget in any more.
–
NightManOct 26 '12 at 19:14

1

Don't mean to sound dismissive if I did because you're absolutely right. Those areas are just constrained.
–
NightManOct 26 '12 at 19:17

1

Sometimes you do have to make the tough choices, or sometimes you can delegate those choices to make people feel in control of their situation. So give the team a choice. They either self organize and work as a team to catch up, or they decide that it's time to reallocate resources. Tell them they have a week to come up with a plan and present it to you; otherwise, you'll be making the decision yourself by reallocating resources. Good luck!
–
jmort253♦Oct 26 '12 at 20:04

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

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.

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.

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

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.

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

I would personally want to stick with Scrum, just because I'm confident with it. I'm not opposed to learning about Scrumban or other methods, but I wouldn't feel capable of coaching a team into a transition. I think the team had some really poor scrum coaching. It seems like they got told all of the process parts and none of the mindset parts and I feel the mindset stuff is the most important. And our scrum master is really willing to back me in trying to help the team improve. Unfortunately he can't control meetings well.
–
NightManOct 26 '12 at 19:47

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!

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.

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.