I am one of 4 Nayima coaches helping 4 Atos Worldline development teams to become more agile.

All these teams belong to the terminals division. One is responsible for providing the terminal platform, two develop applications for specific market segments on top of this platform and the fourth team develops a DEP (Data Encryption Peripheral) aka HSM (Hardware Security Module). The terminal platform is built on top of a Linux kernel. It offers a development environment in C and Java.

We assessed each team, identified their productivity bottlenecks and gave hands-on assistance to implement XP practices to overcome them.

3 of the teams are now using user stories to drive development. User stories are brief statements of an interaction between the system and its users in order to realize some user goal. More generally, stories may describe interactions with non-human actors in the system's environment too. They are used in agile development for planning and tracking progress. As a statement of requirements, stories are incomplete; details that do not affect effort estimates substantially are left to the implementation phase. Acceptance tests, on the other hand, are made explicit. Epics are coarse-grained stories, they have higher level acceptance criteria. Their main purpose is the construction of product or project roadmaps. An epic typically takes too long to implement to be a useful planning unit. Before implementation starts, epics are decomposed into stories.

Epics and user stories are business-oriented. Therefore they provide a common understanding between developers and commercial departments and afford commercial departments the opportunity to set development priorities as we feel they should be. Effort estimates, on the other hand, are the preserve of developers.

Estimates and how long a particular implementation actually took are tracked rigorously by all teams. This data feeds into the development velocity. Each team calculates and charts their velocity on a weekly basis. Estimates are calibrated by velocity and comparing new functionality to previously implemented stories and epics.

Team velocity is also used to predict project delivery dates in 'burndown' charts. These charts plot work done against time and afford project status visibility to all team members, their managers and customers. This, in turn, makes release dates predictable.

Predicted release dates have also become more reliable by short release cycles, and even shorter iterations. Technically, each iteration could be released as the system is fully built and tested. However, features implemented in several iterations are grouped together into releases that deliver clear value to the customer.

Teams are communicating more effectively. Each team has instituted daily standup meetings in which progress is discussed and blocking issues are cleared. Each team has a project whiteboard that clearly shows which stories remain to be done in the current iteration, who is doing what and which stories are finished. Team progress and velocity is shown next to the whiteboard, respectively in burndown and velocity charts. Developers are moving away from individual code ownership to team ownership. Hence they are more aware of the system's architecture and becoming more polyvalent.

Quality is improving through practices such as pair programming and continuous integration and testing.