The Situation at Tree Business Publishing

Tree Business Publishing (Tree), a division of Tree Holdings, publishes professional journals across a diverse range of industries. It has been almost a decade since Tree decided to publish its journals not only in print but also on the Web. The editors in charge of Tree ‚ s trade publications were told to have journals on the Web as soon as possible. However, two years after this directive had been issued, only one journal was Web live. The delay was in part because Web publishing turned out not to be as similar to print publishing as everyone had thought. Progress had been stymied because Tree had yet to answer a series of questions specific to Web publishing:

• How could a journal be presented tastefully and effectively online?

• How would internal editorial and production processes change as journals began to publish online as well as in print?

• What was the best mechanism for getting content onto the Web?

Tree ‚ s editors, writers, and software development teams had spent some time trying to arrive at an acceptable solution. At first, all of the editors attempted to construct ‚“media-neutral ‚½ publishing solutions. The publishing process would generate XML data streams that could be used to render content in any format the business wanted. Even though the managers at Tree had decided that this was the right thing to do, they had also decided that media- neutral content development and management was more challenging than they had first thought. The goal of moving over to a media-neutral mode of operation had added a level of complexity that stymied any progress toward the immediate goal of getting Tree ‚ s trade journals up on the Web.

In desperation, Tree ‚ s managers sought a way to speed up delivery of the journals to the Web. They lighted upon WebPub, a small two-year-old dot-com capable of quickly generating content-rich Web sites. WebPub already had a number of customers that had already successfully used its products to publish online. Tree bought WebPub and declared it to be the Web publishing solution for all of the Tree journals. These journals were to rethink their Web publishing efforts and center them on WebPub.

Unfortunately, Tree ‚ s purchase of WebPub made the Web publishing problem more complex than ever. WebPub ‚ s Web publishing platform required enhancements before it would be able to publish Tree journals. Although Tree thought it had purchased a generalized solution, WebPub ‚ s platform had peculiarities that were specific to its legacy customer base. Now Tree had to decide whether to upgrade the WebPub platform so that it would be able to publish Tree journals or to turn the WebPub platform into a generalized publishing platform that could handle all kinds of Web publishing.

The following decisions were made to stop the floundering and enable progress:

• The WebPub platform would be enhanced with generalized publishing in mind, but the first enhancements to be made would be those that enabled Tree journals to get online.

• XML media-neutral feeds would be generated from each journal ‚ s editorial process to feed the WebPub platform. XML was already the primary input for this platform. A generalized XML data type definition would have to be constructed to handle the requirements of all of the journals.

• The journals ‚ respective Web developers would halt all journal-specific Web development, learn to use the WebPub platform, and work to integrate the editorial process with the XML feeds into the WebPub platform.

These decisions represented a critical breakthrough for Tree in large part because they reduced the number of options available to the journals, to WebPub, and to the Tree business unit. However, these decisions also had harmful side effects: managers now felt that they could impose new deadlines for the Web publication of the journals. These deadlines were imminent, in large part because the company had to justify its rather costly acquisition of WebPub.

The WebPub developers were dependent on the results of two incomplete and undefined projects. Everything they did was subject to change as the journals ‚ XML feeds were formalized and the WebPub platform was enhanced. The developers were shooting at a moving target, and that target was not slowing down.

Application of Scrum

Tree hired me to introduce Scrum at WebPub. I had first presented Scrum to them several years before. Managers remembered the presentation and felt that Scrum offered a possible solution. They particularly liked its incremental delivery of functionality providing a tangible demonstration of progress. Everyone felt an urgent need to get the journals published online. Over 100 people were involved in the effort to do so, but no progress was being made.

The individual efforts to enhance the WebPub platform, to standardize XML, and to publish journals on the Web were all completely and inextricably intertwined. Fortunately, Scrum teams are cross-functional. A Scrum of Scrums is the usual mechanism that coordinates multiple teams working on a single project, much as the Daily Scrum is the mechanism that coordinates the work of multiple people on a single team. A Scrum of Scrums is a Daily Scrum consisting of one member from each team in a multi-team project. Before a project officially begins, the planners of the project parse the work among teams to minimize dependencies. Teams then work on parts of the project architecture that are orthogonal to each other. However, this coordination mechanism is effective only when there are minor couplings or dependencies that require resolution. The dependencies at Tree were so significant that a Scrum of Scrums wouldn ‚ t work.

To quickly develop increments of product functionality, I needed XML, WebPub, and journal functionality developed in parallel. The XML and WebPub aspects of the work were extensive and of an infrastructural nature. How could the effort in these areas be coordinated with the work of teams building journal functionality? How could the XML and WebPub teams satisfy the requirements of the journal teams while working in parallel to deliver their own functionality?

I decided that the best option was for the individuals on each effort to coordinate these dependencies. The dependencies were too complex to parse before work began, so the teams would have to self-organize to resolve the dependencies. I asked Tree to select the four journals that it wanted online first. Each team was staffed with developers. We then assigned someone from the XML team and someone from the WebPub team to each of these journal teams.

I held a Sprint planning meeting for each journal team. Each journal team had about nine members , including the part-time XML member and the part-time WebPub member. I worked with the first team and its journal editor, who was designated the Product Owner. We constructed a Product Backlog of functionality. We inserted into the top-priority Product Backlog those nonfunctional requirements for XML structures and WebPub capabilities that were needed to publish that part of the journal. The team committed to building that functionality into an increment of potentially shippable product functionality during the next Sprint.

I then met with the next three journal teams. At these meetings, the Product Owner, the XML member, and the WebPub member from the first journal team reviewed their team ‚ s Product Backlog and explained the functional and nonfunctional requirements it addressed. The other three editors, or Product Owners, agreed to adopt this Product Backlog for their own journals after updating it to make it specific to the particularities of their publications.

Because each of the three new teams also had part-time members of the XML and WebPub efforts and the XML and WebPub team members had committed to getting a certain amount of XML defined and WebPub capability achieved for the first team within the next Sprint, the three new teams would benefit from the same nonfunctional Product Backlog. Their Sprint tasks built the capabilities that the four journals depended upon. The part-time XML and WebPub team members resolved the dependencies when they returned to their XML and WebPub teams. They were aware of the needs of the individual journal teams and ensured that the functionality to support them was developed in parallel in their XML and WebPub teams.

Lessons Learned

Sometimes projects are so complex that they require something more than the normal implementation of Scrum. In the case of Tree, the dependencies among teams were simply too great for Scrum to handle without some modifications. I had to go back to thinking about the basics. Scrum is based in empirical process control theory. As the degree of complexity rises, the number of inspections must be increased. Because of the increased frequency of inspections, the opportunity for adaptation also increases . Scrum relies on individual and team commitments rather than on top-down control through planning. Self-organization and human commitment are far more powerful mechanisms than imposed controls, plans, and even loyalty.

At Tree, the complexity was overwhelming, and the situation was nearly chaotic . The XML, WebPub, and journal teams were all developing dependent functionality in parallel. Their Sprint increment functionality was heavily intertwined and interdependent. Scrum ‚ s usual mechanisms for inspections and adaptation would have been overwhelmed if I had constituted the teams as usual: one for XML, one for WebPub, and one team for each journal. The Daily Scrum wouldn ‚ t offer enough opportunities for inspection of progress and detection of dependencies at play, and inspection is required for the necessary adaptations to be selected and implemented.

The key modification to Scrum in this case was the alteration of team constitution. I populated the teams so that each team included someone who was familiar with each component of this complex situation and had the authority to influence it. The XML part-time team member would commit to the part of XML that was needed to support the increment of journal functionality in the Sprint. The WebPub part-time team member would do the same. Because they were part of the journal teams as well as the XML and WebPub teams, these individuals were responsible for coordinating the product development that the journal, XML, and WebPub product teams accomplished during each Sprint. These people then went back to their XML and WebPub teams and ensured that the teams built only functionality that met the needs of the journal teams. At the same time, they synchronized the work of the journal teams with that of XML and WebPub teams. This cross-team coordination is very similar to what later became known as a Scrum of Scrums, in which the work of many teams is coordinated by individuals from each of the teams. This worked well at Tree, and trade journals started appearing within three months with a rapid ramp-up of the rest of the journals thereafter.