Bootcamp Mallorca 2008

The bootcamp and workshop was held in Mallorca, Spain September 2008.


This page documents the approach which and how software processes should be performed when developing software products in our company. We discuss the constraints under which the processes will be executed.

Please consult the bbv process page (look for Software Services section) for a detailed presentation of the actual company software development process based on Unified Process, OpenUP and RUP.

A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
  • Waterfall process, also called V model in Germany is dead. Studies of the failure rate of the DOD-STD-2167 specification, which enforced waterfall, have shown that the more closely a project follows its process, specifically in up-front requirements gathering, the more likely the project is to release features that are not used in their current form
  • Iterative process prescribes the construction of initially small but even larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want. For example RUP is a typical iterative process, see "Dinosaur Meets Archaeopteryx?" for a critical discussion.
    Iterative processes use planning to detect and correct discrepancies; therefore assuming that you can identify problems before they occur.
  • Agile software development processes - e.g. Scrum, or XP- are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.
We believe that agile methods are currently the optimal methods to develop time to market, return on investment driven software products. Fact is
  • Agile methods tackle one major weakness of over methods. The last fifteen years has shown that it is impossible to write a complete requirements set before starting a time to market project. The development cycles are way shorter than twenty years ago; no only in software engineering but in general. Cars are now developed in two to four years instead of seven years, mobile phone and computer manufacturers provide new models every six months.
  • Agile methods is current buzz words. Our company must have answers in this area.  Extreme Programming was already published in 1998.
  • Technical universities - e.g. FH Lucerne - teach agile methods. The method of FH Lucerne is called HTAgil. So almost all new engineers hired in our company are trained to use agile methods.
The definition of processes, activities and tasks which should be done in a software project developed by bbv Software Services will be solely in the context of agile methods.

The waterfall process and iterative process are obsolete. We acknowledge that our customers are still working with these processes but our goal is to coach and support them to migrate to state of the industry software development processes.


Agile methods are more effective if major rules are respected. We provide below a list of assumptions related to successful use of agile methods

  • Each iteration is timeboxed and provides a running executable. The duration of an iteration is two weeks in our projects. After the start of the iteration the customer cannot request changes or enhancements to the software, he must wait for the next iteration. He cannot infer with the team but must talk with the Scrum master. This approach empowers the team to concentrate on the current iteration and is quite reasonable for the customer who needs to wait at most one iteration of two weeks. All human created artifacts are tagged at the end of an iteration and a new version of the program is delivered and demonstrated to the customers
  • All human created artifacts are under version control. Each member of the team has full access to all relevant documents for any iteration in the project. Shared drives and version numbers in file names are evil.
  • Everything is online. All information is linked together.Currently if you want an information you must either open various documents, type in each document the search criteria and hope to find the piece of information or you index all your documents and hope the search engine will provide the location. I wish you good luck when trying to index Excel sheets, RequisitePro and ClearQuest/Bugzilla databases. Therefore we postulate that searching is primitive and evil, linking is future. The web has shown us how to do it!
  • Critique is welcome, errors are human. Bring and sell better solutions. Agile approach is about learning. Therefore the team will always find better solutions to solve known problems. As a team member you can always bring better approaches. But please avoid finger pointing and statements like "this is bad". As a learning team we should always use the best known solution!
  • Mundane tasks are all automated. The cycle - compilation, unit testing, integration, deployment - is done with a few mouse clicks and in less than 10 minutes. Integration servers are available for exhaustive integration and regression testing. The results are automatically published and available to the team
The above assumptions were interpreted and a set of corollaries was derived and is described below
  • Away from document centric processes to solution centric processes. V-Model or RUP are document centric processes. RUP requires that more than 17 documents are updated during each iteration to formally complete the iteration and respect the associated milestones. Try to update all these documents with a team of ten engineers every two weeks!
  • Linking is information, no duplication of information. Searching is evil, linking contains information
  • Written language is English. Programming language, libraries, frameworks and standards are written in English. So you have two choices. Either you write everything in English or you use two languages at different abstraction levels and write a glossary mapping definitions and domain words from one language to another. I do not believe that human brains are build to switch non stop between two languages
  • Conventions over rules; no policeman is needed. Agile methods emphasize the learning aspect in projects. The team increases his software and domain specific knowledge - e.g. PCR DNA replication - to create better and better products. The members of the team provides an optimal solution in terms of return on investmentandtime to market. Scrum method eliminates the project leader and delegates the responsibility to the team
  • Refactoring is the key mechanism to ameliorate the product. Refactoring is done in each iteration, each day, for each line of code you write. See the Test Driven Development (TDD) credo


Software engineering projects have a set of tasks and activities. The processes define how these tasks and activities are done and which outputs are created. They also define what conditions must be fulfilled before a task or activity can be executed.

Agile methods have one central concept: the iteration. The iteration is timeboxed and always delivers an executable. All over activities, tasks, artifacts are subordinated to it. Below a set of potential processes.

Requirements Analysis

  • Requirements and Use Cases: Requirements analysis is performed during the whole project lifecycle. At the beginning of each iteration the set of stories and requirements to implement in the iteration are selected. The selection of requirements is the responsibility of the product owner.
  • Errors and Change Requests: Identified errors and change requests are either implemented in the iteration or are considered as new requirements to ameliorate the actual product.
  • Risks: Identified risks are handled in the iteration cycle
  • Quality Control: Tracking of each requirement and use case to the associated code and unit tests, and the first iteration it was implemented

Analysis and Design

This activity is quite unclear in agile methods. Only Feature Driven Development has a clear answer when and how analysis and design is done.

Our current approach is as follow. One or two experienced architects define a feasible architecture based on the key  features available in the project backlog. They run to provide the initial architecture and application framework before the team needs it. Because this approach is never fully sucessfull major architecture refactoring must be performed later. These refactoring tasks often a branch to work outside the iteration rythm before merging again.

On the other side standard problems such asynchronous communication, multi-threaded application, application startup, configuration and shutdown, recurring tasks are always implemented with the same approach and are already included in the architecture. This is the major difference between a senior and a junior architect. A senior one knows how recurring architecture functions are implemented and has already the associated design and source code with unit tests and documentation at hand.

This approach works best if the company masters incremental technology changes when new technologies appears or current ones are updated - This occurs quite often in the Microsoft and Java universes -

Quality Control: Architecture review with pairs to increase the odds the architecture is the best one we can provide

Coding, Unit Testing and Comments

  • Coding, detailed design and Unit Testing: Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.
  • Version Control: Currently we are using Subversion as version control tool. The red book of Subversion defines all the processes and concepts how you should work with version control.
  • Quality Control: Continuous refactoring, code walkthrough, coding guidelines, code documentation

Planning and Controlling

  • Scrum has a clear approach how planning and controlling is done in the context of iterations. More extensive information can be found in  [1].
  • Quality Control: The book cited above describes checks after each iteration used to validate iteration planning, effort estimation and project progress. Naturally some constraints exist on the change speed of requirements.
  • Releasing and Deployment
  • Release and deployment are performed at the end of each iteration. The whole process is automated and does not require any human interaction
  • Quality Control: The delivered software application must run without errors - for the implemented features -. Pretty clear control rule!


Team using agile methods release executables at each iteration starting with the first iteration. Therefore the team should provide 3rd level support for the last release currently used by the customers. Agile approach also require that all clients are using the same released version.


We put quite a few statements on this page. Feel free to refute or refine them.

Agile Credo

You could also define agile approach with the following statements. Agile methods are controlled chaos. The agile rules could almost be seen as strange attractors :-)
  • Productive, innovative, flexible
  • You always know where you are
  • Only the running error free program is of relevance
  • All other activities and artifacts are secondar
  • Traceability should be implicit and supported by tools


[1] Agile Estimating and Planning, Mike Cohn, Prentice Hall 2006


back to  Agile Methods or Home
Marcel Baumann,
Oct 29, 2009, 6:19 AM