Monday, May 28, 2012

Making decisions in Agile teams - another case study

Challenges of shared decision-making: A multiple case study of agile software development
http://www.sciencedirect.com/science/article/pii/S0950584911002308

I've came accross this paper with a lot of insights how agile teams reason when making decisions. This papers goes into details explaining the multiple quotes.

Here is an example of a quote from that paper:  It is now more difficult to ‘‘steal’’ resources from us, because the consequences of losing resources during a sprint are more visible with Scrum. Earlier the deadline was 6–12 months ahead, and then it was easy to steal a day or two. There has been a change of attitude in the company, and it is now well accepted that you do not steal resources from a Scrum team during a sprint.

Resource allocation is usually an issue in software projects and using Agile has this advantage that the allocation is onto the teams (to a large extent). This quotation shows also how they think when making the resource allocation visible to the management - e.g. through shorten deadlines. As you can see, this influenced the company.

@MiroslawStaron

Sunday, May 27, 2012

Simulating Agile teams...

Making decision about process changes based on simulating Agile processes...
http://www.springerlink.com/content/x8566274232m672g/

I listen to the talk presenting this research and, quite honestly - I expected something different. However, I could not stop thinking about this approach. Using agents they were able to recreate the behaviors of Agile teams based on real data from Microsoft.

I need to try out this tool so see how one could simulate process changes. Imagine if this could help out in making decisions on how to put together a team...

@MiroslawStaron

Sunday, May 20, 2012

Does Measuring Code Change Improve Fault Prediction?

Does Measuring Code Change Improve Fault Prediction?
http://dl.acm.org/citation.cfm?id=2020392

Code churn measures seem to be very nice predictors of software failures. In this paper, Bell, Ostrand and Weyuker show that one does not need much more. They also investigate whether code churning is often linked to other anomalies based on 18 releases of a large software system.

I recommend this paper for two reasons - it shows how simple measures can give a lot of value and because it comes from top names!

@MiroslawStaron

Tuesday, May 8, 2012

Four ways to speed up product development...

Four ways to speed product development (written in '94, valid now for SE)
http://dx.doi.org/10.1016/0024-6301(94)90209-7

When looking for solid research on how quality improvement impacts lead time, I've came across this paper. It shows that the product development models of the 90's are no longer valid. Instead, new aspects are important, like:
- streamlining development,
- parallel feature development, or
- continuous releases

Kind of obvious and already known in the 90's. How come software engineering discusses those things now?

@MiroslawStaron

Motivations (systematic review)...

Models of motivation in software engineering
http://dx.doi.org/10.1016/j.infsof.2008.05.009

I've written about motivations a few times, so let me write another paper review. This systematic review is a very good set of references for research on motivation in software engineering.

This paper proposes a model where they identify intristic and extristic factors. Again, technology challenges are one of the main drivers. What are the others then? Well, some are:
- variety of task
- feedback
- intellectual stimulation
- individualized consideration
- ...

The interesting thing is that they also put some numbers on how important different aspects are in a number of different models which they investigate.

I also recommend reading http://www.jstor.org/stable/249347 where the motivation is evaluated from the perspective of job satisfaction. This particular paper is a bit old, but still interesting.

Wednesday, May 2, 2012

Do social interaction in projects influence software quality?

Studying the impact of social interactions on software quality (paper review)http://www.springerlink.com/content/j747jqn77h358824/

I wish this paper could end up at some coffee tables in the lunchrooms at software development companies. I also wish this study to be replicated in large, commerial software systems.

In its essence the idea is simple (yet cool!): if there exist predictors of quality in the internal product characteristics (e.g. McCabe complexity), are there any predictors based on organizational aspects like social interactions.

This paper shows that in projects like Eclipse (www.eclipse.org) these social interactions, extracted from defect tracking discussions, have a good predictive power. The paper uses such aspects of social interactions as role or participant - it also includes lengths of discussions, centrality of the subjects, etc. 

There are a number of cool conclusions and metrics, but one I liked most: "Overall, we observe a strong ef fect of discussion f low inconsistencies on the failure proneness of f iles associated with the discussion." Basically it means that if the discussion is unfocused, then the module is fault prone - nice that they've managed to find a metric for that!

@MiroslawStaron