Pols Consulting > Agile Zone > Papers
Here are a collection of interesting papers, articles and presentations on (or related to) Agile Software Development:
( A | C | G | H | J | K | L | M | P | S )
A
* An Initial Investigation Of Test Driven Development In Industry
(Boby George and Laurie Williams)
Some research on the use of Test Driven Development (TDD). They ran a set of structured experiments with 24 professional pair programmers.
One group developed code using TDD while the other a waterfall-like approach. Both groups developed a small Java program. We found that the TDD developers produced higher quality code, which passed 18% more functional black box test cases. However, TDD developer pairs took 16% more time for development. A moderate correlation between time spent and the resulting quality was established upon analysis.
* Post- Mortems Key To Successful Future Projects
(Michael Pastore)
A short article in CIO update discussing the importance of project Post-Mortems (I prefer to call them retrospectives).
Anyway, regardless of what you call them, I also think they are critical. The only difference with an agile project is that you should not wait until the end of the project. You should do them every time you deliver a new release to the Customer. That way, you continually improve the way you develop software.
* What Is Agile Software Development?
(Jim Highsmith)
Jim provides a nice introduction to the philosophy and ideas behind Agile Software Development, a case study and a (very) brief overview of the key agile methodologies.
This article is adapted from Jim Highsmith's book "Agile Software Development Ecosystems." Addison-Wesley, 2002. It provides a nice taster of the book.
C
* The Cooperative Game Manifesto For Software Development
(Alistair Cockburn)
Alistair describes software development as a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system.
The residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game.
Too many agile teams forget the next game. This paper is a nice reminder of how important the next game is.
G
* Agile Methodologies Applied To Embedded Firmware Development
(Bill Greene)
Bill Green came to ADC2003 and commented that he seemed to be the only person there who coded in assembler and C! Saying that, it did not stop him applying agile ideas to and sharing that experience in this paper.
* Extreme Interviewing
(Clement James Goebel III, Thomas Meloche, and Richard Sheridan)
How can you ensure potential candidates will operate effectively in an open and collaborative work environment and embrace paired-programming?
Some interesting ideas on how raise the bar on recruiting developers into an existing Extreme Programming team.
H
* Emergent Database Design: Liberating Database Development With Agile Practices
(Alan Harriman, Michael Leo, Caribou Lake, and Paul Hodgetts)
This ADC2004 experience report discusses a team's experience keeping a system's database in sync as the project evolved.
They started out believing that the entire data model should be carefully designed up front and protected from change thereafter. But the incompatible nature of traditional database practices and agile development practices caused them significant pain! Fortunately, they were able to adapt and start applying a more agile approach to their database development.
* Refactoring The Development Process: Experiences With The Incremental Adoption Of Agile Practices
(Paul Hodgetts)
Paul talks about his experience with big bang adoption of XP practices vs doing it more incrementally - one practice at a time. This supports my experience working with teams transitioning to agile. I like this paper a lot.
J
* R O I- It's Your Job
(Jim Johnson)
Jim Johnson (of the Standish Group) presented this, now classic, presentation on ROI at XP2002. In the presentation he states that 45% of features are never used and 19% are rarely used. To double your productivity, simply don't build the stuff that people do not need!
K
* X P Anti Practices
(Yoshihito Kuranuki and Kenji Hiranabe)
This was one of the highlights of ADC2004 for me. Yoshihito Kuranuki and Kenji Hiranabe presented a superb paper on the problems (anti-patterns) they had in using XP. They are typical things an XP coach should look out for. They used cartoons, play acting to totally captivate the audience.
There include:
* Brownie's Works - The boss refactored our code!
* This Anybody Syndrome - I'm not necessary here
* Pairing Prison - I'm always under observation!
L
* Iterative And Incremental Development A Brief History
(Craig Larman and Victor R. Basili)
You may think of iterative and incremental development as a morden idea. This paper presents the ideas in their historical context, dating back to the mid-1950s.
The bit I like is the discussion with the Son of Winston Royce (the author of the famous paper on Waterfall development ~ "Managing the Development of Large Software Systems")
He [Winston Royce] was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes [iterative practices] within the context of the 60s/70s government-contracting models (a serious set of constraints).
* Subclassing X P: Breaking Its Rules The Right Way
(Greg Luck)
Greg Luck talked at ADC2004 about his experience on a project. I really did not like this paper when I read it! They did not subclass XP, and he talkes about only allowing refactoring at the end of the iterations!! Ummm, not convinced about that at all!
Anyway, it turns out that he ment defer large design changes to the end of/future iterations. Phew, now I can see where he's coming from. He also talked about a pair being too small a unit to make large design decisions. I agree with that. I always use team white board sessions to discuss designs with the team. Shame the paper does not explain the story properly.
M
* Acceptance Testing
(Roy Miller and Chris Collins)
Acceptance tests represent the customer's interests. The acceptance tests give the customer confidence that the application has the required features and that they behave correctly. In theory when all the acceptance tests pass the project is done.
Not many XP teams I have seen manage this, but Customers shoukd write acceptance tests to determine if the system is doing the right things. This is one solution to the poblem of how to write automatied acceptance tests.
* Agile Software Teams: The Secrets Of Software Success
(The Menlo Institute)
This is a nice desciption of what agile software development is all about. They have the following killer definition of agile teams:
Before you can build a team that rocks, you must first become agile. If you don't already know what an Agile software team is, let me help:
An agile software development team can add features in any order and can release a working version of the product at any iteration.
I often use this definition when talking to development teams.
* Business Value Driven Software Development
(Chris Matts and Andy Pols)
Most IT projects traditionally focus on delivering working software, features, functionality and/or a service to the business.
We (Chris and I) believe that IT departments should focus purely on delivering frequent business value. We have seen countless projects focusing on delivering software that does not help the business at all. This paper talks about some of the things you can do to change that.
P
* Make More Money: Improve Our Standard Of Living
(Mary Poppendieck)
This is Mary Poppendieck's excellent keynote presentation from XP Day 3. Mary's presentation showed a number of ways we could be more effective. I really enjoyed her talk.
Tom Poppendieck has some photo's of XPDay3 on his website (http://www.poppendieck.com/photogallery/XP_Day_2003.htm if you would like to see Mary in action!
S
* An Agile Approach To A Legacy System
(Chris Stevenson and Andy Pols)
This is an experience report presented at XP2004 . It describes how we (Chris and I) used Agile software development techniques to rewrite a legacy system by focusing on delivering new features!
Abstract: We describe how a small, successful, self-selected XP team approached a seemingly intractable problem with panache, flair and immodesty. We rewrote a legacy application by delivering new features, a radically different approach to those previously applied. This proved to be a low cost, low risk proposition with a very high payoff for success. Most importantly it provided users with new functionality quickly that could never have been retrofitted into the legacy system. In the longer term it may give a migration strategy for replacing the legacy system.
* Why Is Agile Development So Scary?
(Preston Smith)
This is a pragmatic overview of why Agile works. I particularly liked the reference to Donald Reinertsen?s research that showed:
* Out of hundreds of projects, there is no case in which requirements remained stable throughout design.
* Of more than 200 product developers, fewer than 5% had complete requirements before beginning design.
* On average, design commenced with only 58% of requirements specified.
If requirements are going to change, wouldn't we be better off acknowledging this and building our processes to accommodate it.
