Stretching Crystal Clear to Yellow


Many people have noticed the gap between Crystal Clear (38 people) and Crystal Orange (3050 people). What does Crystal Yellow look like, for 1530 people?

I am indebted to Géry Derbier, of Solystic, now a French subsidiary of Northrop Grumman, for deriving a version of Crystal Yellow and reporting back on it.

Solystic won a bid to build a new post office just outside Paris to handle all the international mail going into and out of northern France. The overall project included the building itself, plus the mechanical, optoelectronics, and information processing systems and also hiring and training the staff. Géry was the project manager for the information processing software.

It was significant that the purchasing sponsor, the French Post Office, was looking for a supplier that was willing to do incremental development and get paid every six weeks in exchange for demonstrating integrated features that often. It was also significant that the external test team was located at the site of the new post office building, not at Géry's location.

Here are the highlights of Géry's team's conventions:

  • Seating. The software development team occupied one floor, which was shaped rather like a donut. It was less than a minute's walk from anyone's office to anyone else's. The programmers sat several people to a room in several adjacent rooms. There was a "common room" where they held stand-up, status, and other meetings.

  • Time cycles.

    • Iterations. Iterations were one month, and started off with a planning session and a reflection about the previous month's work.

    • Stand-ups. They experimented with daily stand-ups and moved to stand-ups on Monday, Wednesday, and Friday.

    • Integration. They tried but never got down to daily builds. Full builds were done three times a week.

  • Programming. The team tried and rejected pair programming, so they programmed in near proximity to each other.

  • Deliveries and user viewings. The key representative from the Post Office visited one day each week. Integrated code was evaluated for acceptability and payment each six weeks.

  • External test collaboration A representative from the external test team visited and worked with the development team one day each week.

In terms of the agile evaluation framework presented at the end of the last chapter, we see for this project the following:

Number of People

25

Frequent Delivery

1 year (a danger signal), but early integration with acceptance tests attached to payments every six weeks (a safety factor mitigating the danger signal)

User Viewings

1 week (a safety factor mitigating the danger signal)

Reflection Workshops

Monthly

Osmotic Communication

1 floor

Personal Safety

Yes

Focus (priorities, time)

Both

Easy Access to Expert Users

1 day/week

Configuration Management

Yes

Automated Testing

No

Frequent Integration

3/week

Collaboration across
Organizational Boundaries

Yes

Iteration length

1 month


In terms of technique and strategy use, we see the following:

Exploratory 360°

Yes

Early Victory

Yes

Walking Skeleton

Yes

Incremental Rearchitecture

Yes

Information Radiators

Yes

Pair Programming

No

Side-by-Side Programming

No

Test-First Development

No

Blitz Planning

Yes

Daily Stand-up Meeting

Yes

Agile Interaction Design

No

Burn Charts

Yes

Dynamic Priority Lists

No


I am happy to report that the project delivered on time and the development team was recognized for their success.

I asked Géry what contributed to the success, particularly given a schedule that looked overly optimistic when I visited the project. He answered that monthly incremental development was key. Developers who might otherwise have spent weeks worrying over what was the "right" or "best" way to do something recognized that with only one month to deliver function, getting an acceptable design out the door was better than a perfect design that didn't get delivered.

What I noticed was how much attention Géry gave to the quality of the community, morale, and communication and how much attention he gave to the quality of the team's linkage to the sponsors in the Post Office and to the external test department. He was able to build close collaboration across organizational boundaries.

Finally, we can't overlook the effect of having a sponsor who paid for integrated, running features every six weeks. Whatever Géry's bosses may have been thinking higher up the management chain in Solystic and Northrop Grumman, they saw a team presenting features to a customer every six weeks and a corresponding check coming from the customer shortly thereafter. That simplifies discussion with management a whole lot.

Here is Géry's story.

Tailoring Crystal Yellow

by Géry Derbier

The project had several challenging aspects:

  • It was business-critical for the customer.

  • It was the first time the customer was contracting with an integrator to provide a turnkey system.

  • It was the first time Solystic was leading a complete system project, although its mother company Northrop Grumman had previous experience in this business.

  • Though Solystic has much experience in the automation of domestic mail processing, this program was one of the first in the international field.

  • It was a fixed-price, fixed-time contract to be delivered in a short timeframe.

I started with pretty few ideas and guiding principles. The cooperative game model was the framework I would always come back to in order to make sense of what I was seeing happening. The "team = product" formula, which I consider a stronger form of Conway's law (see Software for Your Head [McCarthy 2002]) was how I understood how to influence the final product quality through the group shape and characteristics. Incremental growth of both product and process requiring periodic reflection and adaptation was at the core of the method. We employed use cases to specify the system because among the qualities of use cases was that they act as a tool to link several teams, especially development and integration teams.

During the RFP process, I elaborated a development plan built on the principle of fixed-length iterations and frequent interactions with the customer team. I later was told that the customer considered this feature to be a competitive advantage. Timeboxed iterations came to me through Jim Highsmith's (2000) book Adaptive Software Development and the reading of DSDM (Stapleton 2005). At that time, I borrowed the iteration structure from Stapleton's book. During the project, we created small variations in the form of communications with the customer during an iteration.

The overall project had a phase-and-gate structure. Six months after the contract was awarded, we had to have an approved system specification, a so-called baseline. The thirteen-month milestone was the beginning of the site's full-system integration. Then, eighteen months into the project, the sorting center would open to real production with a six-month period of staged ramp-up, concluding with the final acceptance of the system.

We had to demonstrate running features as early as nine months after the contract was awarded. These contractual demonstrations were interim acceptance tests linked to payment by the customer. All these milestones were defined in the contract with a very high-level functional description of the content.

Organizational patterns (Coplien 2005) was the body of knowledge we used to design the group structure and communications. As an example, we started with a limited number of roles ("few roles" pattern), including

  • Project leader

  • Sub-team leader

  • Business expert

  • Lead designer-programmer

  • Other designer-programmer

  • Tester

We estimated that the team would peak at 25 people. However, we quickly assembled a team with the necessary core competencies: the project leader, the test lead, the database lead with a database designer, the application development lead, and a couple of designer-programmers. The application development lead was assigned the architecture responsibility (the "Architect Also Implements" pattern). Then we slowly incorporated additional programmers.

One sub-team leader was the overall project leader. Sub-teams were application domain teams (e.g., real-time operation control, production management tools) or technical teams (we had one DBA team and one test team for the whole group). The leader and business expert roles were filled by one person. In the early part of the project, the team leaders were writing the uses cases. During the last third of the project, the leaders' time was mainly devoted to integration and test.

We got several adjacent two- to four-person offices on the same floor of the building. The leaders were grouped in the same office. Developers were grouped per office as much as possible by application domain or technical activity.

It was a core practice to hold regular reflection sessions. It happened every month after the team was mostly staffed, then every two months by the end of the project. These sessions were essentially informal discussions on what was happening in the project. I played the role of a facilitator. During the discussions, when I would recognize the need for a common decision to be made on a given subject, I would formulate a proposal and try to come to a consensus. Among the subjects I led the team to explore: conventions between the developers and the internal test team, values (courage to tell things), fear, configuration management, coding standards, integration frequency, and the relationship with the external test team.

So, during the course of the project, we changed several working conventions and stuck to others. We tried a number of strategies and techniques; some attempts worked, but many more failed miserably. Here are some pieces of the story.

It was my plan to split the leaders group seating in the same room and seat each of them in their sub-team room when the system specification was sufficiently completed. However, we recognized the advantage of leaving things as they were.

Because the project was about automation and evolution of the customer's process, we knew we had to face progressive discovery of the customer's needs until relatively far into the project. So it was clear that we would not succeed without a fair amount of concurrency of the different development activities (the "Gold Rush" strategy [Cockburn 1998]). We naturally resorted to the "Build Prototypes" pattern.

We soon recognized the need for a specific build-manager role and a rolling assignment strategy for this role.

Despite several discussions and commitments during the reflection sessions, we failed to have a disciplined protocol for internal software delivery to the test team.

The number of unit tests was not satisfactory until we decided to have one team member responsible for monitoring the unit test coverage and have him get the other developers to invest time in writing their tests (we were far from doing TDD!).

I encouraged people to pair-program. Because they worked in near proximity, people would occasionally work by pair to analyze or debug a piece of code, but the true practice of pair programming never got adopted. I did not insist on having it because I knew we were asking many new things from this team, iterative and incremental development not being the least change for most people in the group.

I borrowed from the Scrum methodology for the way we implemented the "stand-up meeting" pattern. Given the number of people, we considered splitting the stand-up meeting into "scrum of scrums" several times during the project. However, because we did not have sufficiently automated integration tests, we decided to keep the stand-up meeting with the full team to hold the team together. We adopted small strategies to cope with the team size: The meeting would occur every two days instead of every day; during the meeting we would focus on functional aspects. Technical aspects would be raised if necessary or mentioned only briefly. The meeting duration was targeted for thirty minutes.

I insisted on having two dedicated spaces for the project: a meeting room and the testing lab. The meeting room was a place with many whiteboards where the team could hold collective design sessions. On the whiteboards was an information radiator dedicated to the iteration planning and tracking: the team progress was tracked during the stand-up meeting by moving around the sticky notes on this task board. The room was big enough to permit the stand-up meeting with the full team.

Despite all my efforts to build a collaborative culture within the team, not all members worked in perfect amicability. A good deal of storming occurred, and unresolved tensions remained all along the project. However, a small part of the team was truly willing to ignore positional games and invest all their energy to get successful software out the door.

All along this project I had been a little nervous about the lightness of the process, fearing missing something that should have been present. I retrospectively think that this lightness is precisely what helped me to be always efficiently on-guard instead of being stiffly in-guard.




Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net