Making scrum-fall work for the short-term

Question

Our team is in an annoying situation: Our corporation is in a period of transition that will probably last another 3 to 6 months after a merger between two companies with very different philosophies. The transition is heading in the right direction (the acquired company was acquired for their ability to manage the technical side of things well), but progress is slow and rocky.

Due to politics, re-orgs, and chaos, our PM isn't able to get good specs for us before we start developing an iteration, yet we can't grind to a halt. The developers are able to make do, but I can't co-develop automated tests without a clear idea of the product to work from. Right now basic things like frequent communication between test and business owners doesn't exist, and the design isn't fixed until coding is done. As the tester, I've been scrambling to gather requirements - often from the dev - and change and re-change my fixtures - and it's just not working. Since I'm so busy responding to basic design changes, I don't have time to get much test coverage and I can't follow through on my test plans.

We're looking at starting a two-iteration scrum-fall model for the next 3 to 4 months, where the test / debug work lags one iteration behind the design and development work. Devs will be designing and developing the current iteration of work while I write fixtures for the last iteration, then I'll test their last iteration and they'll fix those bugs. The idea is that this will last for a few months, and then we should have good design docs available.

Things I've thought about already: The "catch-up" iteration, where I'm testing for the previous iteration and the current at once to move to Scrum proper, won't be an issue; I'll halt development on test tools for the iteration, as that normally takes about 50% of my time. We don't have deadline pressure; this is a large, time-consuming project with probably 5 more months before we can go into production (although moving deadlines / resourcing commitments are part of the chaos right now). I trust my PM to work at getting us to the point where we can move back to normal sprints; I don't think a temporary move to scrum-fall will end up being permanent due to laziness.

TL;DR: Due to an inability to get good specs and business requirements early in the sprint, we're going to try having test lag one sprint behind development.

Question: Has anyone been-there, done-that? What pitfalls should I be looking out for, and what can I do to help make this "scrum-fall" system work smoother? What can I do to help the transition back to normal Scrum happen sooner (to pave the road for better documentation and communication)?

Answer 1

The main challenge with any waterfall style testing is that you are increasing the time between the defect being introduced and the the defect being found, and the closer you can bring these points together, the cheaper the defect is to fix.

My recommendation would be that you split your testing and do some in the current iteration and some in the catch up, with a view to trying to close that gap.

Current iteration

• Build verification testing
• Manual exploratory testing

Catch up iteration

• Formal requirement verification
• Test automation once feature has been verified

Answer 2

Quite a few software projects have a tick-tock model of a feature version, then a stable version and I see this as similar on a smaller scail.

The key thing is not to test things that the devs know isn't really done but sort of works and is only pushed to testing because they've not got enough time. I don't think that really helps anyone.

The other thing is to get a 'tracerbullet' version there so that you've got something however rough to start showing people. You'll get no feedback with nothing to show, so it's a race to get that loop started. Once you've got something, people will soon say what's wrong / how it could be improved.

And ask them to name it - that will get some buy in too.