Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'd like some input on this on those working with agile methodologies...

A current project is finding that development on our planned user stories is finishing some time before the end of the iteration, and that the testing effort and business acceptance is what's actually dragging us out longer towards the end. This means that the devs in question have spare time, and they're essentially going out to the iteration+1 backlog and starting work on cards there before our current iteration cards are 'done'. As iteration manager, I want to put a stop to this - I want a more team-orientated approach where the group takes ownership of getting all the cards done, as opposed to "Well, dev's done so what do I dev next?"

The problem I face is convincing the team of this. On one hand, I understand why the devs don't want to test the code they've written (there are unit tests they write of course, but the manual testing to be done could be influenced by their bias). The team sees working ahead as making our next iterations easier, because a lot of the work is done before we start. I see this as screwing with the whole system of planning/actuals - but it's difficult to convince the team as to why this matters.

What advice can you guys and girls give? How do we stop devs reaching ahead? What should they be doing instead? How much of a problem is this in the scheme of things, if things are still getting done?

share|improve this question
1  
Quick questions - When do your testers actually start writing the acceptance tests? Why aren't the acceptance tests ready to run by the time the developers have finished coding? What is the ratio of developers to testers that you have within the team? –  David Wallace Sep 26 '12 at 4:44
    
3 devs on one system, 2 devs on another, 2 testers, 2 BAs. A lot of what's being written at the moment is code on a legacy mainframe system. There's little to no automation that exists for this system, so most tests are manual and in many cases involve financial calculations that need to be double-checked outside the system. In short, some of the changes are just a few lines of code, but involve a lot of data prep or processing to verify. –  f1dave Sep 26 '12 at 6:30
1  
That doesn't sound like enough testers if your tests aren't automated. I feel scrum works best with as many automated acceptance tests as possible; because they WILL fail at some point, and you need to be able to fix the problem and get running again as quickly as you can. –  David Wallace Sep 26 '12 at 9:20
add comment

6 Answers

up vote 3 down vote accepted

This is usually caused by "failure", that is not delivering everything planned for the sprint, being seen as a negative thing by management. Remember the occasional failure is required to know exactly how much the team can deliver. You may also need to remind the team that their performance is partially judged on the amount of code they can deliver, not just whether they deliver the promised features in each sprint.

If that is not the case, why is the team finishing work early? For example:

  • Are they over estimating, a common problem with scrum? If so, use the "finished early" sprints as evidence to push the team a little harder.
  • Are they getting assistance from outside the team? If so, add these as workers.
  • Was time allocated to probable interruptions, such as supporting an existing product? If so, reduce the estimate for the next sprint.

Also ensure that supporting tasks are done in addition to the development work, including automated tests, ensuring the product installation/deployment is up to date, documentation is complete and so on. Consider raising the completion criteria for these. Alternatively, have the dev help the QA by creating test data, automating tests cases and so on.

Remember the sprint team is judged by sprint team effectiveness, not whether the devs finish their tasks early or not.

share|improve this answer
1  
Yeah, there's some good points in there and I'm actually a dev wearing the IM (and testing) hat. A lot of it comes down to personality I think, with the "I'm a dev and I just dev so give me some more dev work" mode of thinking. We also 'failed' (we don't use the term) our first two iterations so that could definitely have had a flow on effect towards "well, let's get stuff done". –  f1dave Sep 26 '12 at 6:35
add comment

Are you sure you want to stop them from reaching ahead? If you prevent developers from looking at (iteration+1), then in the next iteration they will take that much longer to accomplish their dev tasks. Which means your QA will have that much less time to test things.

On our team, a recurring theme is actually the opposite, developers tend to over-commit so they either don't get their tasks done or get them done right towards the end. This has the effect of QA not having enough work in first 2/3 of iteration and way too much work at the end.

One of the ideas we've thrown around is to actually try to do what your team is already doing. Make developers take on less work and finish early so they can start looking at (iteration+1). This way some stories will get done earlier so that a) QA will not be bored in the beginning and overwhelmed at the end. Also in planning we would have better task estimates since people already had a chance to review the work ahead.

Being a developer and being a tester takes very different personalities and very different skill sets. I can see how most of your developers would be hesitant about jumping regularly into QA. Not only would they simply not enjoy their jobs as much, but you will also not get the same quality out of a developer "forced" to test, rather than hiring one more QA person who actually enjoys what they do.

Just my opinion (and I am a developer)

share|improve this answer
    
It's a good question. I'm a developer too and there is a tendency towards 'fuck it, let's be productive and knock a lot out'. But I've also been a tester and wearing the IM hat at the moment I appreciate pipeline management a lot more. A past project (different team) ended up with devs 2 iterations ahead of testing and everything eventually crunched before the release date, resulting in multiple pushouts of the delivery date and some very unhappy stakeholders. That's why I'm quite keen not to let these guys get too far ahead. :) –  f1dave Sep 26 '12 at 6:37
1  
@f1dave: I guess there's difference between developers constantly staying few days ahead of QA (i.e. every iteration they finish 2 days early) vs. their capacity is higher and they run away from QA. Sounds like in the long term, you'd be better off increasing QA capacity which you could do by a) hiring a person or b) having developers write some automated acceptance tests so existing QA can do their job faster. –  DXM Sep 26 '12 at 6:42
    
Yep. B) is definitely the only option we have, and it's already something we're looking at. :) –  f1dave Sep 26 '12 at 6:49
    
@f1dave: I'd be very curious how (B) works out for you :) I've been floating the idea of automating some of our acceptance tests on our team but so far we don't actually have any. I'm still a bit sketched out about being able to actually keep tests at a whole product level actually maintainable. –  DXM Sep 26 '12 at 7:07
add comment

Why is the testing effort and business acceptance taking so long?

It sounds to me like you're planning mini-waterfall projects within your iterations (developing, then testing, then acceptance). Testing and accepting should be done directly after each user story is finished, and preferably by the people who developed it plus a product owner. It should not take longer than one, maybe two hours (if you streamline this it could be done in minutes).

There are some solutions for now. You can have the development team research new technologies one day in the week to keep them busy. In this day it might be a good idea for them to look into their testing processes, since they seem to have a problem with testing (they don't like it). Perhaps they can spend their extra time developing an automated test environment that goes beyond some simple unit tests (unit testing is just one of a multitude of testing techniques).

share|improve this answer
    
Yeah, that's definitely part of it. We should be doing more unified work up front around testing criteria/acceptance scenarios before the code is written. It's something I'm working with the team on, but a lot of members haven't ever worked in this way before (some straight out don't like it) and it's a gradual process. –  f1dave Sep 26 '12 at 6:32
add comment

As long as you keep pushing for more stories during the sprint it will be hard to avoid this behavior. Instead let people spend the rest of the sprint with whatever they are up to, except new stories. I guess there is a myriad of things that can be done: from build automation, learning that cool new tool from last week, testing or having that barbecue that you could have had for weeks. A new sprint can be planned accordingly in order to do more stories in a new iteration (if that is the goal).

If you can speed up test and acceptance, then do so. If you can't, this is a limiting factor.

share|improve this answer
add comment

What is happening during testing, and why does it takes so long?

It could be a resource issue (5 developers, one tester - not going to work)

Or maybe testing is overly thorough AND not finding any issue any way - in which case just test less and automate more?

Or maybe quality is poor and it takes a lot of time to test because there is a lot of rework/fixing required? In which case developers need to slow down and build better quality in (and eventually consider having QA work with them during development).

Someone smart (I'm too lazy to look it up) said that the job of a developer is to put QA out of business.

share|improve this answer
add comment

I have seen developers who finish early because they are not thorough. In my book, developers have no less responsibility for testing than testers, so if testers are finding many things that need to be reported, it adds both administrative time and later on re-testing time.

Developers can build very impressive collections of unit tests to run and still the code can have spectacular failures. Perhaps the cause is that they are considering the required functionality too narrowly. Perhaps it may go back to the use cases which may need to call out more alternate flows. Or perhaps it is a sign of poor code quality matched up with too few or too naive unit tests.

In some development environments, there may be many features that are tested with simulators or given a pass because they are too hard for developers to test with what they have available at their desk. In the interest of fairness, the scope of developer test vs. acceptance test is a huge factor in how much testers must work.

Another consideration is the ratio of developers to testers and the complexity of the test configuration relative to the tools available to automate the testing. If development runs unit tests in ten minutes, but complex user interactions or tests with hardware and external devices are not part of their testing, perhaps it is normal for the testers to be long pole. Testers may do a lot more to document their work than developers and if this is true there might be some kind of assessment about whether one side is taking short cuts or the other is doing unnecessary work.

Developers should not influence testers in ways that compromise their objectivity. However, I think is it very reasonable for developers to share documentation about their unit testing and the code that was changed with testers. In some groups, developers do a bunch of work, then hand off builds to testers when the schedule is almost exhausted. In other groups, testers get daily builds, so testing can proceed with new bits as they become available. In some groups, testers can even generate their own builds that are timed to their best advantage.

Some teams are adding people with the title Software Development Engineer in Test so that they can have highly trained staff to do code/decision coverage testing. This may run counter to some Agile guidelines, but so do the developer test practices that we say we should do but don't.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.