Thursday, May 17, 2012

Achieving Benefits from Distributed Agile Teams

This blog post is about a report on ‘Distributed Agile’ by Elizabeth Harrin. This report titled 'Distributed Agile Teams: Achieving the Benefits', is based on a survey conducted by Elizabeth during January 2012 among 340 distributed agile practitioners. It is an informative report and it is it free! 

Sometime during Nov/Dec 2011, Elizabeth collaborated with me in collecting my views and opinions on distributed teams. She has shared some of my thoughts in this report in several places.

I think surveys like this need to happen at regular intervals – may be every year. Also, the number of respondents per survey must increase. When thousands of practitioners participate in a survey the results can benefit analysts and researchers. A good idea is to conduct the next round of this survey from destinations that provide software services and analyze them with the inputs provided by customers who consume software services. A survey like this can provide the analysis and consolidation of the views of both providers and consumers.

Elizabeth’s report is a great one to begin with. Here are the links to the report and couple of reviews on this report.

Main Report (38-Page PDF) -


Blog Posts:

Friday, May 4, 2012

The Benefits of Pair Debugging

In my blog post ‘Debugging – Critical Questions’ I wrote, “Great developers need not be successful debuggers. Sometimes we find software test engineers becoming very successful in debugging as compared to developers.  More interestingly, when a developer spends several hours on debugging an issue he or she naturally collaborates or joins hands with the corresponding software test engineer to get it straight.”

Pair debugging is a very powerful technique. The are several benefits of pair debugging. Let me share five of them in this blog.

1) Efficient Defect Reproduction: When a developer and a software test engineer collaborate the time spent in defect reproduction is less as compared to the usual back and forth that happens between these two individuals.

2) The Power of Diverse Mindsets: All said and done, the mindsets are different for these two individuals. When they come together they continue to think in their own way. This is the power we get in pair debugging. They get to think in multiple dimensions – about different environments, across multiple layers, across multiple modules, across similar components, about related modules and regression effects etc., In other words, they get to think if a similar defect can be present in the system in as many possible ways. This thinking is required to initiate a holistic approach for debugging. When two individuals think differently, there is an opportunity to stay away from ‘quick fixes’ and commit to thorough fixes.

3) Collaborative Learning: Pair debugging is an opportunity to learn. Software test engineers get to learn about the architecture, design and coding elements of the system. Developers get to learn about the nuances of debugging and testing.

4) Preventive Maintenance: Pair debugging provides an opportunity to identify some of the weak modules or components that need preventive maintenance. When team members practice pair debugging over several months, they gather enough information to suggest ‘top-n preventive maintenance tasks’ that can reduce long term maintenance over heads.

5) Effective Defect Verification: Pair debugging results in effective debugging because software test engineers learn more when they work along with developers. This provides them an opportunity to think beyond the obvious and create test scenarios with the right test data set.

Have you tried pair debugging? Have you seen additional benefits?