In her OnAgile2016 presentation titled "Scaling Agile Projects to Programs: Small-World Networks of Autonomy, Collaboration, and Exploration," Johanna Rothman encouraged her audience to use the existing small-world networks within the organization to help with change, communication, and integration. Additionally, she recommended different methods to strengthen those small networks, allowing them to improve on processes for delivering large programs of functionality.
Rothman, author of Agile and Lean Program Management: Scaling Collaboration Across the Organization, indicated that most organizations have an informal network, frequently used to spread rumors, that can also support the needs of the organization in powerful ways. This network can contribute to project success when used in conjunction with communities of practice and roadmaps.
Rothman said that "To go big, think small," and indicated that many of the small, team-based processes used in agile practices work well with larger programs as well. Moving features or stories to done at regular intervals allows for greater transparency, and more frequent information about risks of the project. Practices like running iterations of two weeks or less, and working with small deliverables that can be completed in a day or two help teams receive frequent feedback on the work they are doing. Measuring the delivery of features is also useful, as these building blocks can be tracked by both the business and technology to see progress toward completion of the program.
One practice to help with managing programs that Rothman recommends is using a rolling wave roadmap – frequently planning for short horizons of time, and building on those short timeframes for slightly longer views of about three months. Internal deliveries about every month help to build out quarterly releases to production (or a production staging area). Updating plans after each internal delivery will help keep everyone aware of changes and impediments. In large programs, these roadmap planning sessions can be where interdependencies are managed, rather than within two or more teams.
Additionally, Rothman encourages working on architecture in a fluid and evolving manner. She notes that delivering a draft architecture at the "most responsible moment" is more useful than trying to identify a working architecture before any development occurs. Software frequently evolves, and Rothman recommends allowing for that to ensure that teams have guidance in that architecture.
As part of managing a program, Rothman recommends creating two major teams to drive delivery of large programs – the Core Team and Technical Program Team. The Core Team is designed to coordinate efforts across all areas of the company that are affected by the program (technical, HR, legal, marketing, etc.). This team shepherds the business value of the program across the organization. The Technical Program Team looks at risk assessment, manages problems, and identifies change within the technical area of the organization. This team works well when led by a trio representing Program Architecture, Software Program Management, and a Program Product Owner.
In closing her presentation, Rothman provides a few pointers. First, recognize where inertia blocks the program. Second, build momentum where you can. And finally, any program's success depends on collaboration – using the small networks already in place, and guiding progress with roadmaps that keep the vision clear and defined.