BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Johanna Rothman – Scaling Agile Projects to Programs

| by Susan McIntosh Follow 7 Followers on Oct 27, 2016. Estimated reading time: 2 minutes |

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

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Product not Program or Project by Eric Naiburg

Another way to look at this and something absolutely described in Scrum is not to look at Agile Projects or Programs, but look at Products. What is the Product you are trying to deliver and organize around Products with a Product Owner per product...

Re: Product not Program or Project by Johanna Rothman

Eric, in the book, I say to take a "Product perspective." A program is one release across the organization. You still need some organization for a given release once you have hundreds of people working on one product for one release.

I think I'm violently agreeing with you :-)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT