How Do You Manage a Large Agile Program?
In the same way that good project management was never about command-and-control, good program management is not command-and-control. Program management is about coordinating several subprojects or a series of projects to meet some specific business objectives.
What’s the operative word? Coordination. Program managers are not order-takers. Oh, no, no, no. They are not victims, or wimps. They are the face of the program to the rest of the organization. One of my clients long ago said that they are the “grease and glue”—they grease the way for the program to succeed, and they glue the projects together. They help the projects expose the risks. They facilitate the projects. They are servant leaders.
And, if you have recently transitioned to agile or are transitioning to agile, you are going to have confusion. The larger the program, the more confusion you will have. This is why you need small world networks. You want people to talk more to each other, and not wait for a standup. You want to use the power of the rumor mill to keep momentum going.
Inertia Is Bad, Momentum is Good
In a large program, you know how hard it is to get things moving. Not everyone has access to the same tools, you can’t find a time to meet, what works in this location doesn’t work there. Even if that location is just on another floor or across town, not across the world. Inertia is not your friend.
To prevent inertia, or if you have just transitioned to agile, here is my little trick to gain a little momentum and help people discover the value of the small world network. This also works if you have too many people on your program and you need something for them to do.
Ask everyone to start one iteration with one objective: to learn how to work together. You want to learn what done means for the program, how to ask questions of each other, if the iteration duration is the right length, whatever else you need. At the end of this iteration with any luck, you will have some features complete, an updated picture of the architecture, and you have have some questions answered. You will have started to build a little momentum, or you will know why. You will have bought yourself some knowledge. And, if you have an already-existing product, maybe you will have paid off a little technical debt. But, you will have learned.
If you don’t have anything done, you will have learned why. You and the entire program can spend the next iteration fixing those impediments. Now, isn’t that a better use of your time than a Sprint Zero where you don’t deliver features?
I am opposed to a formal Sprint Zero in a program. Why? It increases inertia and decreases momentum. Do you need to write stories? Fine, allocate time in the first two-week iteration and write stories. How much time do you need to write stories? Timebox that your story-writing to no more than four hours. Why four? Because any more time and you have Parkinson’s Law.
How long should your iterations be? Not longer than two weeks. Why? Because you have all these teams, and your run rate is high. But you say you need more time. WHY? Because you need to determine the architecture. Why? (I could go on with the five whys but I’ll stop here.) You cannot possibly determine the architecture in advance on a large program and be correct. No, you need to implement features, get some feedback and learn.
The larger your program and product, the more you need to be agile and lean. You need feedback and you need it fast.
The larger your product, the less work in progress you must have. Otherwise, your cumulative flow is off the charts and you have no idea if you can ever release. There is no reason your program cannot release every two weeks. No reason at all, unless you create technical debt.
I say, you must release every two weeks, to create momentum, to obtain feedback, and to make sure your program is not going off the rails. It’s the only way you, as a program manager can verify your program has momentum and not inertia. It’s a terrific risk management tool.
Now, you get to choose if you release to your users or just release into the code base. Release to the users is always a business decision. But release-able code? You want that in your program. Yes, you do. And the bigger your program is, the more you want it.
Sidebar: A Story From My Past
In 1988, I ran my first large software program. I had run projects and beta programs before, but this was the software effort for Symbolics’ MacIvory, the first lisp-on-a-chip. I was so excited. I’d never managed anything like this before. We had over 100 people working on the software, integrating the software with digital hardware, analog hardware, mechanical parts, and there was documentation, also. We were not Software as a Service.
We didn’t know about agile back then. But, we used Lisp, and were able to continuously integrate, or pretty much continuously integrate across the platform by feature.
Since the program was so long ago and I no longer have my notebooks, I have to reconstruct much of it from my most-likely faulty memory. I believe I asked everyone to deliver a significant milestone/demo every month. The first few months, there wasn’t much to see. You had to know what you were looking at. I used rolling wave planning to manage the schedule: What did we think we could deliver in the next month? Then, we did we do? Let’s replan based on reality.
Every day, we came in, loaded patches—yes, I ran the current experimental OS on my machine—and tried what would work on the new chip. We used the one-month timeboxes to keep our deliverables in sync with each other. We used a staged-delivery lifecycle (it’s incremental, not agile), so we could work in features and test as we went. In staged delivery, we worked by risk, not by business value.
Did we deliver everything in the nine months from the time we conceived of the idea until the demo at conference? Not everything. Did we have problems? Of course. It was a program! But, because I didn’t try to control anything, and I tried to facilitate the program and the people, it was a success.
No, MacIvory didn’t save the company. That’s because we didn’t deliver what the market needed. It was a great product, but it was not a software-only product And, we did not have a ranked backlog by business value. We worked by risk, remember? And, we never did get the marketing right. I already said it wasn’t agile.
But, that program was successful in the sense that we had a product that we could show at the trade show nine months after the program started. I didn’t generate one Gantt chart that predicted anything. We used data, the data of what we had delivered to predict the future.
We delivered feature, after feature, after feature. More importantly, the feature teams didn’t coordinate themselves through me. They coordinated themselves. They cooperated, solving problems as the problems arose. They elevated the problems and risks to me that they could not solve. They acted as small world networks. I solved problems at the program level and facilitated solutions they could not fix themselves.
I conducted a program team meeting once a week where I invited the project team managers, the people named in this picture. We didn’t have a single architect, so that person wasn’t invited. We didn’t have a product owner, so that person wasn’t invited. We did have a Marketing person, and a Sales person, and a Release person, and several project “managers.” I put them in quotes, because our project managers never used Gantt charts and were fairly technical. Or, they were like me, and used deliverable-based planning and rolling wave planning to ask, “How will we see the next deliverable in about a month?”
We solved problems at the program team meetings. We tracked action items. We monitored our work in progress, although none of us knew that’s what it was called. All I knew is that we had to keep finishing features and see the product evolve. No, we didn’t show demos to product owners. I said this wasn’t agile.
We could see the product evolve every day on our machines. That’s how we knew we were making progress. And, when people had questions or a problem, there was an entire community available to help.
I used that approach in a distributed voicemail system a few years later. I was unable to convince all the teams to use continuous integration. The teams that did use continuous integration had a working system from Day One. The teams that didn’t? Well, they had a difficult time, and when they started integrating finally realized what they had given up.
Fast Forward to the Almost-Present
When I started helping some of my clients with their large programs of greater than nine teams several years ago, I kept remembering MacIvory and how it worked. I remembered what we did wrong: not having a Product Owner to check that we were working on the most valuable work. I remembered what we did right: being able to see the system evolve from the beginning. How could I use the MacIvory experience to help my clients? What they were doing wasn’t working for their large programs.
One client had 17 teams. They were having trouble finding time for their Scrum-of-Scrums, never mind their demos or their retrospectives. They were not solving problems fast enough. And, they needed to put more people on the program because they were not moving fast enough. Remember, 17 teams of 5-6 people is only about 100 people. That’s not a large program as large goes. Their management wanted to put another 50-60 people on the program to increase the speed. They had more features that they could develop in parallel, so this was a reasonable approach. What were they going to do?
I met with the Scrum Masters separately and asked, “Are the Scrum-of-Scrums working for you?” Each person said, “No, they are not.” Then they explained how they were not working. Some of the Scrum Masters were not working as Scrum Masters, but as command-and-control project managers, which was a problem. Some of the Scrum Masters didn’t know what to do, which was a different problem. Some of the Scrum Masters were successful and their teams were delivering on time. (I bet you’ve seen this, too.) In a program, you get to see all kinds of patterns and anti-patterns.
Ask for Results
The first thing we did was ask for the results we wanted. Remember, agile is also a cultural transition, and Scrum demands an entire upheaval in culture. If you ask for the results you want, you might get them, and then you can use the agile principles to generate the behaviors.
If you think about servant leadership, it paves the way for these conversations. With servant leadership, you don’t tell people how to do their jobs in detail. You tell people the results you want. You create an environment in which they can perform well. You provide feedback and offer coaching with support.
In this program, I worked with the program manager who then worked with the project managers/Scrum Masters. Some of them were Scrum Masters and some were project managers. Does it matter what they were? No, because all of them worked in two-week iterations and delivered what they agreed to at the end of those timeboxes.
And, that is the point of program management. You don’t care how people work in their iterations, or even if they do work in iterations. All you care about is when people commit to deliver certain deliverables and if they deliver them. And, yes, I worked with the command-and-control people to help them turn into facilitators.
For Larger Programs, Deliverables Matter
The larger your program, the more you need to see demos and working product. That means you need momentum. How do you see momentum? By having people work together, integrating something every day.
Can you predict any of this? No. But if you have a product roadmap, you have a direction that people can see. If you have an architecture that they can keep in mind, they can work towards and refine it.
Remember, if you keep delivering, you can change your mind. The Product Owner can say, “Oh, now that I see this feature, I can re-rank that feature. We don’t need all of this now. We can go there, now.” This is a huge thing on programs. You can buy yourself a ton of market time if you implement across a set of features instead of deep, if that’s what the market wants.
Your project teams need to deliver fast so you gain feedback. That’s what matters, especially in a large program, because your run rate is so high. A large program is expensive. That’s why your organizations want to know how much this program will cost.
How Do You Organize Program Team Meetings?
When I worked with this large program, they decided to develop a roadmap for the program, so everyone could visualize where they wanted to go. That helped a lot. Next, they had once-weekly program team meetings of all the Scrum Masters. Yes, that was 17 people and that was craziness. That’s when the Scrum Masters decided they were at different levels.
The program manager said, “You folks decide. Should you be at this meeting? If not, decide how you will get the information. I will leave it up to you. I work for you.” She sat back down and let them work for 30 minutes.
As in this picture, some of the teams were like Sally, projects that were really small programs of their own. Those Scrum Masters did not need to be at the big Program Team meeting. They needed to coordinate among themselves, but not at the big meeting.
At the end of the 30-minute timebox, the big program team meeting had seven members, a workable number. Three of those people had small programs as Sally does in this image of a program here. They each had three or four teams for their programs, instead of Sally’s six. They had the responsibility to manage their programs as they wished.
This is all facilitating an environment for problem solving. There is no prediction. No forcing. It’s all about risk management, helping people to be more agile and lean.
Enough for today. See, this is why I’m writing a book about this. I’ll talk more in Part 4 about how to organize the backlogs. No, I’m not done with this series yet!