During last six  weeks, the PDFImport team in Hamburg experimented with Agile software development, especially using ideas of Scrum. We wanted to know,

• if a development style that adheres to (at least some) agile principles could be used at all in our environment and project,
• if agile development principles  might be promising to enhance our development process.

The Setup

Some of the things we did different than usually (in the hope to reflect agile development principles):

• We put developers and QA (three people altogether) into one physical room, enabling them to communicate any time with fewest effort.
• We practiced continous testing of each step in the development process, as well by unit tests, as by automated document comparisons, as by repeated manual tests.
  
• We used iterations of a fixed length (two weeks). Each iteration was planned by the Product Owner (see below) and the team together.  After each iteration, its results were presented to interested stakeholders - and there was absolutely no possibility of changing this date.
• We had very short, but daily status meetings at a fixed time.
• We installed the institution of a "Product Owner" whose task was to gather, combine and filter all input regarding product features and be the ultimately responsible contact person for the development team regarding which features to reach for, which to leave, and in which sequence.
  The Product Owner gave feedback at least before and after each iteration, but was also asked many times inbetween about the direction to go.
• We tried to give the team the room to focus as much as possible on one task (the PDFImport project) only.
  

Observations 

The experiment is finished for now. About the produced software see Thorsten Behrens' post.
About the "agile" way of working, I'd like to share some observations:

The team absolutely loved the combination of development and QA in space and time! 
Sitting together, being able to get QA feedback on development steps within hours. They loved to be able to communicate directly, e.g.  without the need of involving IssueZilla, because most issues could be resolved immediately.

Continuous testing isn't that easy. Finding ways to automate tests needs time. Often tests broke for reasons within the test or the used tools rather than for the tested code. In the first weeks there needed to be quite some time invested into the infrastructure of building and testing.
On the other hand, the continuous testing found a huge amount of defects that would have been much more costly when found and fixed later.

We found out that an agile development style has high requirements on the building infrastructure:

• New builds are needed at least daily, usually more often.
• Builds need to run absolutely unattended, without any need for human interaction.
  This is challenging, when not only compiling and linking, but as well installing an Office, installing an extension, running smoketest, unit tests and other automated tests - and all those on several platforms.
  

Some team members saw the frequent interaction with the Product Owner (in his role as customer representative) as the single most important factor in having a satisfying result at the end of the experiment. So, asking quite often, if developed features are still moving into in the right direction, seems to be a very good thing.

There were three iterations. While in the first two, many planned work had to be postponed, in the third iteration more than planned could be completed. Doing things in a new way definitley needs time to adapt.

The daily status meetings appeared not to be very useful for communication within the team, because the team communicated the whole day anyway. We kept them nonetheless, because they helped to

• keep aware of status and progress - providing a "beat" in the working rhythm,
  
• communicate blocks to the work, and try to find somebody to address these blocks,
  
• adapt planning, somtimes leading to the involvement of the Product Owner,
• reflect on the way things were done, sometimes inspiring to try things a different way or to use external resources.
  

A complete evaluation of the "agile" experience is still on the way, but one thing can be said: The experiment was promising. We learned a lot and there seem to be at least some practices that may enhance our development style.

tags: development openoffice.org qa software