Dev and QA- blurring the lines

Few weeks ago, I was talking to Jon about how the Agile adoption has been working for us.

One of the things I talked to him that day was - my observation that the developers were scrambling to get the development done during the beginning of the sprint and then it was la-la land towards the end.  And it was opposite for the testers. I found them not to be so busy during the begining of the sprint and then rushing to get it done by the end of the sprint.

To explain a bit more, the model we have right now is- The developer completes a story and then throw it over the wall to the tester who then tests it and during that time, the developer codes the next story. So obviously by the time the tester is testing the last story, the developer has little to do- maybe complete some documents and such . This is quite better then before when we had the QA team testing the delivery made by the developers in the previous sprint. But this still didn’t quite sound right…

So when the Nashua Scrum club announced the November meeting- the Birds of feather session titled Pairing Programmers and Testers immediately caught my attention. The speaker for the evening was Damon Poole with the title- Scrum and Kanban: Chocolate and Peanut Butter?. I have little or no knowledge about Kanban before then, so it seemed to be a promising evening.

I put forth my question in the Birds of Feather session headed by Abby Fichtner (aka @Hackerchick) . My question was taken in a very spirited discussion that followed and with many people offering me some excellent advice.

I especially like what Abby had to say about how Developers and Testers can actually pair as in how two developers pair during development . This really struck home with me. To me this was like  an ‘aha’ moment.

Imagine this- I write my unit tests and production code. At some point,  my Tester buddy swings by my desk and I tell him\her whatever I am doing and testing. Maybe show him\her my suite of unit test cases. Or do some smoke testing in front of him\her. Maybe he\she does testing with me then and there. And presto !!! He\She uncovers some “instant-defects”. These defects are the ones which developers are never unable to uncover by themselves- but the tester finds them - well instantly. Once fairly satisfied, the team (Developer and tester) jointly releases the story to a more formal QA environment . It can now be tested - by a more formal QA process or executed through a suite of automated test cases (which was  BTW getting done along with the actual development of the story) or whatever serves the best for the product or process.

This is quite radically thinking for me. Whenever we talk about Testers and Developers working closely- I have always seen that to mean that we need to share, collaborate,  make frequent releases etc. But this was taking the game to entirely a different level.

I can see many benefits of this. To quote a couple- you remove half of the red tape involved in making a release which is quite an overhead in Scrum style of methodology.  Secondly, we have cut down the endless cycle of - “Here is the release- what do you think of it ? Oh I found a defect. No problem, will fix it in the next release “. Finally. we have made software development now a joint ownership between the developers and QA- at last. This is the only way the lines between the developers and testers can be blurred.This I think is the biggest advantage. Ironically, this is also the biggest roadblock. You need a radical shift in thinking to get to this level of maturity in your process.

The second part of the evening - the presentation by Damon Poole was even more good karma. He started talking about Scrum and about it’s problems . And then he talked about exactly what I had brought up in the Birds of Feather session few minutes ago !!! Well, actually he did a better job in articulating the problem statement than I did :).

He presented Kanban as an approach to solve the problem. In Kanban, you don’t have time-boxed releases but  one single development life cycle. Scrum is like a train slowing down every time a station arrives. All these frequent stops make the whole process drag the efficiency down . You need time to slow down and then you need time to ramp up in the next sprint. Now compare this with a train which simply zips by without stopping at the stations. You get the idea…. It looks to be an excellent idea- but I am sure is not easy to pull off. Like Damon said- it is a good idea to start with Scrum and then move on to Kanban- if that is what you need.

He also gave a very nifty history of Lean methodologies which I found very interesting .

And of yes- Damon had some excellent slides to go along with his presentation. Very well delivered.

About Nashua Scrum Club- It has had three sessions so far. I have attended two of them and found both of them to be excellent quality.I specially liked their format - where they have a Birds of feather session followed by a presentation by a speaker.

I think user groups are an excellent way of keeping in touch with the community and learning in the process. the interaction that you get in user groups can not be duplicated by reading books or even interacting with others on Internet.