Comments for Jonathan Howell http://jonathanhowell.net Web technology, agile software development, and the scaling up of a Web 2.0 startup Sun, 05 Feb 2012 10:41:56 +0000 http://wordpress.org/?v=2.6.2 Comment on Agile QA is part of development by Alex Duncan http://jonathanhowell.net/2009/03/agile-qa-is-part-of-development/#comment-14 Alex Duncan Sun, 15 Mar 2009 18:25:45 +0000 http://jonathanhowell.net/?p=43#comment-14 Thanks for the response. I agree that option #1 is the better (or easier) option. I like the onus being put back onto the developers to write the test cases and to execute them. Whilst some developers may not see this as their role, it is important to restate the emphasis on quality and that it is the responsiblity of everyone. If I get the chance to try this out, I will let you know how it works out for us! Would be very interested in seeing a topic on distributed agile in the future. Thanks Alex Thanks for the response. I agree that option #1 is the better (or easier) option. I like the onus being put back onto the developers to write the test cases and to execute them. Whilst some developers may not see this as their role, it is important to restate the emphasis on quality and that it is the responsiblity of everyone.
If I get the chance to try this out, I will let you know how it works out for us!

Would be very interested in seeing a topic on distributed agile in the future.

Thanks
Alex

]]> Comment on Agile QA is part of development by Jonathan http://jonathanhowell.net/2009/03/agile-qa-is-part-of-development/#comment-4 Jonathan Sun, 08 Mar 2009 12:39:31 +0000 http://jonathanhowell.net/?p=43#comment-4 Yes, no prizes for guessing who this is, but didn't want to name names as I wasn't sure how public this info was at the moment. To your questions.... tricky. I can think of two basic approaches to try and make it work: 1) Treat off-shore QA as purely regression test / pre-release validation, and focus the development teams on producing quality code, including proper testing of new functionality. Get them to write test plans for user stories before they start coding, and get a developer who did not work on the story to execute the test plan within the iteration. If you have the luxury of a Business Analyst in your team, they could be responsible for the test plan. You could also start measuring valid bugs raised by QA during regression testing and consider that number as key measure of the performance of the development team as a whole (lower is better obviously!), and give awards (teams lunches or whatever works) for teams with a high quality of output. This is probably the best approach if the offshore QA team is relatively small compared to the size of the development team. It's just about making it clear to everyone that quality matters and is non-negotiable, that the development team are responsible for it, and that nothing is "done" until it is fully tested and production ready. Each story should be tested and signed off before the next one is started. 2) If the offshore team is bigger, and it would be wasteful to use them purely for release-level regression testing (i.e. this would not keep them all busy), then you can try and make them feel integrated in to the development team. This is always really hard, if not impossible: making one or two remote people feel integrated in to an an otherwise co-located team. But you can try. I think it would involve assigning individual QA people to work with specific development teams, and get them to work onshore alongside the development teams for a few months to build relationships. Once they are offshore again, make sure you have daily conf-call standups to keep the remote QA person in the loop on what needs a test plan written, what is ready for testing, and any questions about requirement or scope. Make sure that whatever you are using for tracking progress (XPlanner, Mingle, VersionOne, a whiteboard with a webcam on it etc) is always kept up to date so remote team members know the latest status. A chat room (IRC, Jabber) for the team also helps. This is the hard work option though, and should really be avoided if at all possible. Distributed agile is possible (maybe more on this another time), but a single team split across sites isn't really. Hope that helps! Yes, no prizes for guessing who this is, but didn’t want to name names as I wasn’t sure how public this info was at the moment.

To your questions…. tricky. I can think of two basic approaches to try and make it work:

1) Treat off-shore QA as purely regression test / pre-release validation, and focus the development teams on producing quality code, including proper testing of new functionality. Get them to write test plans for user stories before they start coding, and get a developer who did not work on the story to execute the test plan within the iteration. If you have the luxury of a Business Analyst in your team, they could be responsible for the test plan. You could also start measuring valid bugs raised by QA during regression testing and consider that number as key measure of the performance of the development team as a whole (lower is better obviously!), and give awards (teams lunches or whatever works) for teams with a high quality of output. This is probably the best approach if the offshore QA team is relatively small compared to the size of the development team. It’s just about making it clear to everyone that quality matters and is non-negotiable, that the development team are responsible for it, and that nothing is “done” until it is fully tested and production ready. Each story should be tested and signed off before the next one is started.

2) If the offshore team is bigger, and it would be wasteful to use them purely for release-level regression testing (i.e. this would not keep them all busy), then you can try and make them feel integrated in to the development team. This is always really hard, if not impossible: making one or two remote people feel integrated in to an an otherwise co-located team. But you can try. I think it would involve assigning individual QA people to work with specific development teams, and get them to work onshore alongside the development teams for a few months to build relationships. Once they are offshore again, make sure you have daily conf-call standups to keep the remote QA person in the loop on what needs a test plan written, what is ready for testing, and any questions about requirement or scope. Make sure that whatever you are using for tracking progress (XPlanner, Mingle, VersionOne, a whiteboard with a webcam on it etc) is always kept up to date so remote team members know the latest status. A chat room (IRC, Jabber) for the team also helps. This is the hard work option though, and should really be avoided if at all possible. Distributed agile is possible (maybe more on this another time), but a single team split across sites isn’t really.

Hope that helps!

]]> Comment on Agile QA is part of development by Alex Duncan http://jonathanhowell.net/2009/03/agile-qa-is-part-of-development/#comment-3 Alex Duncan Sat, 07 Mar 2009 20:01:58 +0000 http://jonathanhowell.net/?p=43#comment-3 I wonder what company you are talking about....! But if one doesn't have the luxury of having QA in the same building/time zone/continent what steps can you take to work in as agile way as possible and overcome the restrictions? Any thoughts? I wonder what company you are talking about….! But if one doesn’t have the luxury of having QA in the same building/time zone/continent what steps can you take to work in as agile way as possible and overcome the restrictions? Any thoughts?

]]>