Scrum in under 10 Minutes

Scrum (or sometimes SCRUM) represents an agile development methodology. It works with a product backlog that contains all features that should be implemented for a product. This backlog is then partitioned into iterations, called sprints, which typically range from some days to about a month of work. The goal after each sprint is to have a working and hopefully bug-free increment of the product.

Image from wikipedia

Hamid Shojaee made an 8 minute video in which he explains the main concepts of Scrum. Although being a bit fast-paced, the video is quite interesting and also visually very enjoyable.

The video explains the different kinds of backlogs, the sprints, standup meetings, and burndown charts, which seem like a nice tool for visualizing the project progress and estimating the remaining effort.

Watch the video below or the HD version on youtube.

The Influence of Organizational Structure On Software Quality

One goal of software metrics is to estimate and forecast the quality of a software product. In recent years, a number of metrics for the software product as well as the process have been developed, which mostly deal with things such as code complexity, code churn or productivity of the process.

But while it is widely known that a software product is largely influenced by the structure of the developing organization, this fact has not been taken into account in existing quality examinations of software products. In their paper “The Influence of Organizational Structure On Software Quality: An Empirical Case Study“, Nagappan, Murphy (both Microsoft Research) and Basili develop a scheme of organizational metrics to evaluate the complexity of an organization.

They identified eight different metrics, among them:

Metric	Assertion
Number of Engineers (NOE)	The more people, who touch the code, the lower the quality
Number of Ex-Engineers (NOEE)	A large loss of team members affects the knowledge retention and thus quality
Edit Frequency (EF)	The more edits to components, the higher the instability and lower the quality
Depth of Master Ownership (DMO)	The lower level the ownership, the better the quality

They evaluated their metrics on the Codebase of Windows Vista (over 3400 Binaries, >50 Million Lines of Code, thousands of developers) with very astonishing results. They tried to estimate which binaries of Vista would have a fault in the field (are failure-prone) and which are not failure-prone. 86.2% of the predicted failure-prone binaries were actually failure-prone (precision) and 84% of all actual failure-prone binaries were correctly predicted (recall). They repeated their prediction with different metrics and compared the results:

Metric	Precision	Recall
Organizational Structure	86.2%	84.0%
Code Churn	78.6%	79.9%
Code Complexity	79.3%	66.0%
Dependencies	74.4%	69.9%
Code Coverage	83.8%	54.4%
Pre-Release Bugs	73.8%	62.9%

As it can be seen, the organizational structure metrics out-performed every other metric in terms of precision as well as recall!

One might argue that this might only be true for such big organizations, but the authors state that the results of a reduced study indicate that 30 developers and 3 levels of organizational depth are sufficient to draw reliable predictions.

The article is very interesting because organizational structure metrics are not widely known (the paper is of January 2008), not even to mention applied in quality estimations, yet. When I first heard about this, I was very suprised that they performed that well in comparison to other established metrics (some of them tens of years old). Even though it might of course be that the results of the authors are not generally applicable, the article is definitely worth reading and I’m sure that these metrics will in future be of great relevance in practice.

Links to the article:
The Influence of Organizational Structure On Software Quality: An Empirical Case Study. By Nachiappan Nagappan; Brendan Murphy; Victor Basili. January 2008

IT doesn’t matter

Although only 5 years old, the article “IT doesn’t matter” by Nicholas G. Carr is already a little classic. The author discusses the current and future role of IT within an enterprise and argues that the current strategic asset IT will soon become a commodity, like for example eletrical energy, which all companies have equal and virtually unlimited access to.

He draws the comparison to the buildout of railroadtracks in the 18th century. As long as only few companies had access to railroad tracks, they represented a valuable strategic advantage over competitors, which still used steamboats. But after the buildout was complete, everybody had access to it and railroads became a commodity. When IT was young, it also gave the managers that first understood it’s value and employed it in their companies, a radical advantage over customers. They therefore tried to exclude others from the use by employing proprietory technologies. But the buildout of the internet drove companies to the need of using more and more standardization to be able to communicate with others. This made it possible to be able to exchange soft- and hardware components more easily. Because of this and the increase of computing power by magnitudes while still being much cheaper, IT became ubiquitous. But it is scarce resources that make a strategic value, not ubiquitous ones to which everyone has virtually unlimited access.

IT being a commodity has some implications on managers. Their focus shifts to efficiency. Since everyone has equal access to IT, only the one with lowest cost has an advantage over the others. The other challenge for managers is to manage the risks that lie in IT. IT may be a commodity, but when it fails it has huge implications on every business, which can be seen similar to an electrical energy outage. Managers have to realize this and prepare for it.

Because of his controversial theses, Carr’s article was widely discussed and there are many people that disagree with him. Carr collected a huge number of responses on his homepage including critical ones.

Link to the article:
IT doesn’t matter (excerpt)