Tag Archives: research results

What is the proper size and time for an Agile Retrospective?

I often hear the same complaint about Agile Retrospectives: They are not held at the right level in the organization! Or, at least, that is the conclusion that people draw from one fact: Many issues brought up in the Retrospective need resolution at a much higher level in the organization. There is no one in the room who can address or resolve them. Continue reading

Test Driven Development: Ten Years Later - Steve Freeman, Michael Feathers

TDD Improves Quality

TDD improves quality! That might sound obvious, but evidently it isn’t. Test driven development (TDD) is often cited as a key agile practice (1,2). But still, the evidence has been equivocal until now. Continue reading

A selection of repeating tiles.

Regression Test Selection Twenty Years

Last year Regression Test Selection celebrated its twentieth year as a field of research. It was in 1993 that G Rothermel and MJ Harrold published their seminal paper on regression test selection. With Continuous Integration being the top agile practice, RTS remains important. How did scholars celebrate “regression test selection twenty years”? Continue reading

Peppers are a good example of generalists versus specialists.

Generalists versus Specialists in Agile

Generalists versus specialists — it is an ongoing debate. Is it better with generalist or specialist team members in agile software development or elsewhere? Continue reading

Planning poker is a first step towards improved agile estimates.

Improved Agile Estimates


Do you need improved agile estimates? If your agile process is heavily reliant on effort estimates, then chances are that you need to have the best possible estimates. Are your estimates already as good as they can be or do you need improved agile estimates?

Continue reading

Laurie Williams presenting a slide. She is the researcher behind the list of Key Agile Practices.

Key Agile Practices You Need

Laurie Williams has presented a “top thirty” list of key agile practices. The list defines what you need to do to be seen as being agile. Continuous integration, short iterations and done criteria are at the top of the list. Continue reading

Agile software development methodology from Wikimedia, used under CC BY SA 3.0.

Agile is NOT new and not enough

So people keep talking about the Agile – Waterfall dichotomy. About agile and un-agile practices. I decided to have an unscientific look at what Agile isn’t. If there is a true dichotomy between Agile and Waterfall, then things opposite of Agile should be either entirely out of scope for projects and software development or they should be characteristic of Waterfall methods. And since anyone would bother to mention them in the context of Agile, one would assume that this would be because they are distinguishing between Agile and Waterfall. Continue reading

Agile Offshoring in Practice

How is Agile offshoring done in practice? Julian Bass studied seven different companies doing off-shoring London-Bengaluru. He had expected that the companies would have adapted a continuum of practices from Scrum and XP.

Findings about Agile Offshoring

A picture of a team of Indian engineers.
A stereotypical view of a team of Indian agile offshoring engineers. By C. Frank Starmer. Used under a creative commons license. Click image for details.
To his surprise he found that this was not true. Instead, all of the companies had adopted scrum with the exception of iteration demos. All companies did enforce coding standards. This was not really related to agile practices. It was a corporate standard enforced regardless of agile. All companies also claimed that they had collective ownership of code. There were two projects which did pair programming and TDD; none of the others did. Finally, only one project / company had implemented any other XP practices, most notably Continuous Integration. So, is the cost of continuous integration too high for your agile offshoring project?

Continuous Integration for Agile Offshoring

There were two agile practices that I missed most. Only few of the agile offshoring project did iteration demos or continuous integration. Continuous integration requires a lot of work to setup and maintain. But the alternative, late and manual integration is so risky and complicated. Agile software development methods are very much about avoiding building up a debt of unfinished work. It is also about doing the most risky things first. Extreme programming has the right attitude about continuous integration. Regardless if you are in an agile offshoring project or not you should always do continuous integration. You do not need to do test driven development (TDD) to do CI. Just having a build running is enough to catch many errors.

Iteration Demos

Why did so few agile offshoring projects perform iteration demos? I have always found that iteration demos are really useful. They provide an opportunity to interact with the users. To gather feedback from the users. To make sure that they actually look at it before it is to late. This should be more, not less important in agile offshoring. When you are far from the user you should spend more time on iteration demos, not less. Be extreme, try doing it twice per iteration. I have tried and it really worked.

References for Agile Offshoring

Evidence for XP Practices

In a small study, three different projects were examined with respect to the degree that they used eXtreme Programming practices and what the code looked like in terms of size, complexity and coupling. The conclusion was that more agile practices used in a project lead to lower size, complexity and coupling in the product. The study is too small for any definitive conclusions but it is evidence pointing in the right direction.

References

Automated Bug Fixing, Innovation and the Small World of SE Research

With automated bug fixing, we can automatically fix 50% of all bugs at a cost of $8. A fantastic research result from the small world of Software Engineering research. But how can we turn these inventions into innovations?

References