Guest post by Johanna Rothman of Rothman Consulting Group
You have some agile teams who are successful. Good for you!
Now you have a strategic project that will require many agile teams to create a program. You know you need people in several locations. You know you need a cross-functional business team to make sure you address the needs of Marketing, Sales, and even Legal. How the heck can you make this happen?
In the agile project management literature, there is a notion of program management. A program is a collection of projects with one business objective. Each project might have its own deliverables. But the real value is in the program. The sum of all the projects is greater than any of the parts.
How do you scale from an agile project to an agile program without a lot of hierarchy?
What is the Most Efficient Network in Your Organization Right Now?
When I talk to people about scaling agile, I ask this question:
If you want to move information in your organization fast, what do you?
What is the most efficient way to move information in your organization? People often smile and answer, “The rumor mill.”
People in your company have informal networks. They talk to each other. They help each other. They connect to each other in any number of ways which managers don’t know about. You can use these connections to help agile programs succeed.
“When I discovered that one of the testers needed a little help building an automated test framework, I took 15 minutes and did a screen-share. I showed her how I had started our framework for our testers. It wasn’t exactly what she needed, but it was a start for her.
She understood where I was going. She took that framework, improved on it for her team, and got them going on their own framework. It took me 15 minutes. That’s all. Now, they have their own framework, which is different from ours. That’s okay. Our testers got a show-and-tell the other day from their testers. Our testers came back all excited about the refactoring they could do. I knew it would pay off. – Senior developer
This anecdote is an example of small-world networks and communities of practice in action.
In large organizations, people have mailing lists that are the start of communities of practice. In this example, a senior developer answered a question for a tester. He spent a small amount of time coaching someone in another area of the program. The return was tremendous. “His” testers are now improving on their testing.
In small-world networks, people want to work toward a common goal. Many of them share connections, but it’s not necessary that everyone connect to everyone else. If enough people have connections to many other people, that is good enough.
In large organizations, between the project mailing lists, the functional group mailing lists, the project and program blogs and wikis, and whatever else the agile program uses for communication, there is often a way for people to connect with one another.
The small-world network helps people solve problems rapidly. But that doesn’t help people learn what the status is. How can you organize to learn the status in an agile program and elevate risks? Even if the technical folks can solve their technical problems, you still need a way to organize to see the big picture.
How You Organize the Technical Teams in an Agile Program
If you think “scale out, not up,” this is one image of a technical program team. Think spokes of a wheel, not a hierarchy.
The software program manager coordinates the delegate project/program managers of the feature teams. As you can see, some of those teams are small programs themselves.
Sally is an agile program manager for six feature teams. Her teams all collaborate on a significant feature set. They work together on a backlog. Once the product owner decides that the team has done enough for that backlog, the feature teams might work on other features. They might exit the program entirely. It all depends on what the program needs. In an agile program, you want to take advantage of your ability to replan based on feature team availability, and backlogs being “done enough.”
Joe, Tim and Henry have single-team projects. In order to show status and elevate risks, Joe, Tim, Henry and Sally would come to the program team meeting, along with the program product owner, the deployment person, and anyone else you need from the technical side of the program.
If you have a program architect, that person would participate, also. Teams embed architects in an agile program. However, you might need to discuss the risks at the program level with an architect. It all depends on your risks and challenges.
A program team meeting is a problem-solving meeting, not a micro-commitment meeting. Since the technical people can solve problems, you don’t need a daily standup for the program team. You do need to elevate risks, and see product backlog burnup charts, among other metrics, to see if the program is on track from the technical perspective.
That’s just for the technical team. What about cross-functional business interests? Cue the Core Team.
Agile Program Management Works Across the Business
Back in the ‘80s, I facilitated a cross-functional Core Team across the business. We had a person each from Sales, Legal, Marketing, Training, Finance, Marketing Communications and Hardware. We needed to release within a particular market window so we didn’t miss a specific opportunity. I bet this sounds familiar to many of you. We had inter-dependencies up the wazoo.
I didn’t know about agile. I didn’t know about Kanban. I knew about the value of monthly deliverables, and asking people to commit to small, do-able actions. I knew they each had their “own” work to do. I knew that the program’s work was their work, too. But I suspected they wouldn’t see it that way.
At the beginning of the program, eight months before our projected launch, I asked them to meet biweekly for an hour. We had an action-item list at the bottom of our agenda, which you would recognize now as a Kanban board. Everyone had just one item, and the item only took a few hours to accomplish.
By the six-month mark, we met weekly. By now, we understood how to work together across the organization. The Hardware guy understood how to work with the Marketing guy. (These guys are all generic guys. Some of these “guys” were women guys.) The legal guy was happy because we were not going to ship an empty box. So was I!
Best of all, the product came together, as planned. Not as estimated—not even close. But because we worked our inter-dependencies each week, and replanned as we saw our deliverables, and kept our action items small, we were able to release the product in our market window.
We worked in a cadence, kept our WIP (work in progress) limits small. We replanned. We used what we now know as Lean and agile approaches.
Agile Program Management Scales Out, Not Up
Note that the teams don’t try to solve everyone’s problems. The technical teams solve the technical problems. They integrate all the time. They provide good data and insight to the technical program team.
The technical program team solves the risks and understands where the program-level problems are. The program team doesn’t have to solve the technical problems, unless the technical teams are stuck. The technical teams can always ask for help.
Because agile program management uses small-world networks, and is not a hierarchy, this approach scales out well.
The core team solves the cross-business problems. They do not attempt to manage the project portfolio, unless that problem is also in its purview. In small companies, it might also manage the project portfolio.
Program management is not new. Applying agile and Lean methodologies to program management is a new twist on program management.
To read more, see Agile and Lean Program Management: Collaborating Across the Organization, https://leanpub.com/agileprogrammanagement.
About Johanna Rothman
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She has been in the software industry for over 35 years—and she never fell for the waterfall promise. She’s the author of eight books about management and project management. Her most recent book is Manage Your Job Search. Her upcoming book is Agile and Lean Program Management: Collaborating Across the Organization. Read more of her writing on www.jrothman.com and www.createadaptablelife.com.
