The admonishment to managers instructing them to only provide “toys and food” and buffer the team from external distractions implies that leaders in an agile environment should do less work, and be less involved with the team on a day-to-day basis, than in a more traditional environment. In fact a leader in an agile group must do more than he/she would in a more traditional environment and must be even more involved in the day-to-day activities of the team.

The Sabrix development discipline has strong and deeply involved management as one of its keys to success. Management best practices, when applied appropriately and discerningly, do not limit, but rather enhance, the productivity and job satisfaction of the individual members of the engineering teams. This paper discusses ways a manager can and should help the team be more productive, have a better understanding of their fit in the organization as a whole and develop team members by being active and involved with the team and the rest of the company.

Sat is an acceptance test system for testing socket-based servers with multiple clients. The first version used an XML file to define the tests in a test suite. Any errors detected were written to a text log. There were two problems with this first version. The XML format made it difficult to read and edit the tests. When an error was given, it was not easy to identify the place in the test where the problem occurred.

Sat was altered to make use of Fit, a testing framework that uses HTML tables for defining tests and reporting any errors. We found the new version considerably easier to use. The tabular form makes it much simpler to read and alter the tests. Any errors are reported in a copy of the tables, in the place where they occur. We have also found it convenient to include information about the tests in the HTML, providing a form of "literal testing".

The process enabled the defining of each new feature, enhancement, or engineering re-architecture as a set of boxcars on the product train. A “coupled” boxcar was rapidly brought to a supportable level of quality, or “decoupled” for re-evaluation and re-engineering. Frontloading the highest priority boxcars increased predictability of the product train's contents, while the process allowed for greater flexibility with respect to overall content.

“Ready-to-Roll” Boxcar Development kept the product within 2-3 weeks of being supportable and shippable. The process focused on individuals and interactions, working software, customer collaboration and responding to change. Better yet, it worked!

The effort has several challenges:

• It is business critical for the customer, and the output of the project will give the customer a leading position;
• It is the first time Solystic is managing a complete system project, although its mother company Northrop Grumman had previous experience of this business;
• The program is one of the first of the Solystic company in the international field;
• It is a fixed price, fixed time contract with a short time frame.

To face all these challenges, the software development group in charge of the Information System has adopted a number of agile practices and techniques to manage the project. The major project settings are adapted from Alistair Cockburn's Crystal set of methodologies, SCRUM and Jim Coplien's work on organizational patterns.

This paper presents the findings and lessons learned by the team and its manager.

The risk of increased communication costs can be mitigated rather easily.

However, trust is the most complicated element of team dynamics to establish and maintain. A virtual team must address this issue in order to succeed. Remote teams can work quite well. We have been delivering quality software in a timely manner, within the expectations of management for the last two years. We actually are more efficient and successful with a virtual team than when we were all co-located in the same room.

This experience report discusses our successful failure at running fixed time and scope projects. I say successful failure because we actually failed to fix scope but arrived at an acceptable way to vary scope and deliver on time in an environment not normally amenable to variable scope. This paper discusses the methods used and makes recommendations on how you might unfix scope in your development environment.

The contributions of this paper to the agile community are two-fold: describing a practical application of XP concepts to a non-programming project; and making use case style requirements processes more agile.