views:

454

answers:

6

I've been applying agile for a few months now on my project. However we are seeing a steady problem with our iteration burndowns. We aren't hitting zero each iteration.

The tasks remaining are QA tasks. Things like writing tests, testing, etc.

Now, there is some organizational resistance to the "cross-functional team" idea of agile. Dev's develop for single projects but Testers are shared for multiple projects. Which is quite contrary to the agile idea of Dev's and QA working together.

The fact that my tester's time is split across so many other projects is the cause of our slowdowns. The developers are testing to pick up as much slack as they can, but some tasks are still not getting done.

From what I see, I can do two things:

  1. Persuade the organization to move towards "each project having a dedicated QA person"
  2. Change my definition of "Done" to not include QA/Testing work. Things would still be unit tested though.

I'd much rather avoid doing #2, since I value the testing collaboration we're doing.

What advice do you have for my predicament?

+2  A: 

I don't think you can call what you're doing agile unless everybody is in on it. Get the tester to sit physically close to the devs (at least for the time the tester is working on tasks for their project such as creating the test plans), this may up the communication and get the QAs to buy into it.

Scott Langham
He is co-located (2 cubes down) and is working with us to create test plans. Which is great, and is the collaboration i was talking about. However, when the rubber meets the road, the tests don't get written/performed.
Steve Duitsman
+3  A: 

It's a tough situation and unfortunately quite a lot of companies who try to follow Agile do not recognise it. You do not have to have a dedicated QA person - even with Agile resources could be split between different tasks. You DO need to include your QA in your progress tracking.

Yes, your progress will be slower. There is a good reason for that (you don't have enough QA resources) and you should explain it to your organisation management with figures in hand. It will help you to persuade them that some change has to happen.

Also you could move towards more automated testing and use your developers to help the testers with the test automation. This will distribute the load more evenly and will improve the quality of QA on your project

Ilya Kochetov
A: 

You could consider QA as the customers for the Devs. So when Devs release at the end of an iteration to QA, the iteration is done.

Feedback from the customer (bugs that need fixing) can go into the work to be done for the next iteration.

Scott Langham
That's what we've been doing, but it feels like a cop out to me. That's what I was trying to describe in #2 from the question.
Steve Duitsman
+2  A: 

For this to work you must get the QAs to dedicate adequate time to the project. You may need to work with their management in order to get certain swaths of time set aside for them to work on your project. This way you would be able to schedule their time and know exactly how much work your developers can do that the QA team will have time to test. This may require you scaling back on development in order to compensate for the reduced support from QA.

You don't mention how much of your testing is automated. You may be able to increase the testing automation in order to reduce the time the QA team needs to certify the project. You could use part of your development time to prepare the QA tests for the QA team to run. Not optimal, but it could help.

pdavis
True, we are trying to sneak 10hrs a week of the testers time, until we go to management with this to adjust priorities. Most of our tests are automated tests, but the coverage is low. The framework is in place to use those tests to make automating the tests for this new work easier.
Steve Duitsman
A: 

In the short term, stop using the QA resources that can't fit into your process and take on these tasks with those that can be dedicated as needed. I realize that this isn't ideal, but there's a sub-optimal situation where you have an organizational structure that doesn't match your processes. You may just find that it will work out fine (and learn about testing in the process).

In the long term, your options are

  • find a way for this to work with the given organizational structure/process
  • change the organizational structure be suitable to the process
  • chagne the development process to be suitable to the organization
not-bob
+1  A: 

I think QA has lot more to offer in Agile environment than just the testing work. If QA is knowledgeable enough about the workflow and different branches of it, one can be in drivers seat to drive the rest of the scrum process. QA can be envolved with developers to design the logical workflows which will ultimately drive the test cases. This way one can eliminate lot of design and workflow related errors during the development process before they get into QA environment.

Chanakya