Hi Sigge, thanks for your valuable questions. I’m trying to provide more information, please see my answers below and hope that helps.

1. How many people were involved in the project? 2 teams, but how many developers and testers were in the teams respectively?
– That’s really a good question; we were having only one team actually although initially our plan was to have 2 separated teams. Later we just decided to merge the testing/development teams since we really saw the benefit of having just one self-organized team without any silo being built up internally. Probably that’s why I was mentioning “2 teams” in my post, sorry for the confusing. And I had 7 people in my team – the perfect size for a Scrum team. Among them only 1 was tester and the rest 6 were all developers. I didn’t count myself in because I didn’t commit to deliver any piece of code.

2. You talk about developers not testing their own code, and then you have some roles with responsibilities. Did you recognize roles that were possible for one and the same person to have, and any roles that are not possible to combine?
– We only had one recognized role – the “Quality Goalkeeper”. That role had the power to say no when a decision is needed on whether or not we can say the sprint is successful (from the quality perspective). For the other roles, they were virtual and only related to specific user stories, and the people who took those roles were dynamic. Let me take one example, in one sprint, Developer A was the “Story Owner” for User Story #1, but he didn’t necessarily code for that story, instead, he was coding for User Story #2, which was owned by Developer B. I didn’t see any roles that are not possible to combine, even the ScrumMaster role 🙂

3. Did you have any project lead involved in some form? One for each team, or you were the one for both? Would you consider some other constellation or need for other leadership for this to get better? Or did the team organize these things completely by themselves?
– No, I didn’t have any lead level person involved, and the team members I had were not very senior. I was providing suggestions to all the individuals on when they would do what. Fortuentely all those guys were quite smart and were learning new things very quickly. The more important, we were able to work inside one open working space everyday so that it would be easier to communicate and build up trusts inside the team. In the first 3 sprints it was just in a mess and team was under a high pressure, but they did figure out what could be the best way for them to improve. My experience is that once the team realizes they are fully trusted and supported, and are encouraged to utilize the maximum level of their own creativity, you’ll see how amazing they are.

Hi Shrikant, thanks for your comment.
From my point of view (and also our experience), having developers to be involved in functional test (at least on their local development workstations) will not cause too much effort to them – if they don’t have too many bugs to be caught in the test, it just takes 10 – 15 minutes to execute the test cases.
Actually a couple of key points that we probably want to make sure all the developers understand and agree to:
1. Bugs are not included in our definition of done for any piece of the software we’re going to deliver, eventually we’ll resolve all the bugs we find, but the later we do it, the more effort we’ll have to put on it.
2. The best way to deliver few bugs is always not no produce bugs (ideally). The effort for the developers being involved in the test case development and earlier inspection is actually helping them to do the things right at the first time, and to save the effort happens in the future.

Hope that answers your questions, thanks.

Thank you for a good posting,
Sigge