One of the most difficult things in apply SCRUM for development is integrating tester into development team.
Normally, despite your hard works, once you separate the tester role from developer role (but you really should, SCRUM team supposed to be a multi-functional team, not a team of superheroes who can do anything from develop to test) most of the time you will create a mini-waterfall from a SCRUM sprint.
It’s real. Developers would focus all their mind on programming, and after finished a “user story”, they would pass that US to tester for test. Tester would then test that user story, and when they found enough bugs, or finished with their test process, they return the “US” to developers, or mark it as done. Do you feel familiar already? Is it a traditional waterfall? And then, each sprint becomes a mini-waterfall. Everyone is happy ever after because we use SCRUM perfectly.
But… is it?
In reality, the mini-waterfall is a problem it-self. And, secondly, it’s the obstacle that prevent us to be ascended to a higher plane. Oh, sorry, to approach an Agile mindset. Team members may be divided easily and would not have a same goal in their mind – as intended in a SCRUM team.
Thirdly, if you could see timetable of that development team, you would see that mini-waterfall cost your team so much. In the first half of the sprint, when those User Stories was in analysis and development phase, testers would either have nearly nothing to do, or in a corner of the house write their own test-case, without help from developers or BA.
If they had nothing to do. Okay. It’s such a waste of human resources.
If they was writing test-case on their own while developers and BA try to make the program work. There are definitely many misunderstanding between tester and developers. And then, when developer give them the product to test, there should be a lot of bugs that could easily be prevented simple by give those developers some hint that it would be tested.
And at the last-half of the sprint? The student syndrome would present itself, when there would be so many user stories that be ready-for-test, and testers then would work like dogs to catch up with the sprint. (And surprisingly, this will be the time those developers have popcorn and watch)
It would be worse if the sprint fails. Tester would say it’s because those developers give them product to late to have enough time for testing and fixing bugs. Developers would say, it’s because you have a lot of non-sense case that would never happen in real-life. The transparent in the team would dismiss, replaced by natural conflicts between tester and developer, just like any waterfall team…
May be you should ask: Ok ok, we’ve got the point. And the solution is?
And that’s when I would say: this will be answered in the next post. Subscribe my youtube channel… Oh, forget it. Just follow my page to read next in my Agile Testing series.
P/S: it’s easy said than done. My SCRUM teams I am working in still have those things I describe above. It’s not easy to achieve nirvana.