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 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. |