If you read my most recent post, Comparing Teams Is Not Useful: Exposing Another Management Myth and the comments, you will see that I rant about the business of normalizing story points for predicting cost or schedule for a program. That led to several comments re SAFe for programs or other frameworks or lifecycles for programs.
Everything Starts With Trust
Does your management trust you? When your management asks you for an estimate that is more than an order of magnitude estimate, it’s because they don’t trust you. That’s because you haven’t been delivering often enough for them.
Now, you can be upset about this, you can leave this alone, or you can fix this. I like fixing. The way you fix this is to work on smaller features (not infrastructure), demo more frequently, and release more often, assuming you have the kind of product that allows you to do so. I didn’t say this was easy to execute.
You build trust by delivering. Period.
Do you trust your management? Trust goes both ways.
Your management has to create an organization in which there is a product owner for each feature team. Each feature team works on one project at a time. No person is yanked off a project onto another project—work flows through the teams.
If you have or are willing to create these conditions, you can make any number of forms of agile work for you.
If you don’t have this level of trust at the project level, why would you try to attempt an agile program? (Go read Agile is Not For Everyone.)
I know, you feel the pressure. Or, someone says, “You must go agile.” Have you read What Lifecycle? Selecting the Right Model for Your Project? You have choices, other than waterfall or agile, especially for programs.
If You Want to Use Agile for Managing Programs…
If you want to use agile for program management, you need several conditions in the organization:
- Teams who commit to delivering features often. They get to done. If not every time, almost every time, so they, the teams are reliable. They don’t have to have predictable velocity, but they have to have predictable throughput. That means they might not realize how large features are, but they continually finish features and release them.
- Management who commits to managing the project portfolio so that work flows through the teams. The teams work on only one project at at time. This allows the team to swarm over a feature and push it through.
- Product owners who understand how to create a product roadmap and know how to create a product backlog for a team/teams to consume.
Why? This is the basis of trust. This allows what we have from the agile manifesto:
Individual and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Why is this so important? Change happens in a program. It occurs even more in a program than it does in a project. If you can’t trust the people working on a program to make decisions, who can you trust?
If you read my series on small world networks, you know that I am a fan of autonomy, collaboration, and exploration for and among the teams. I am also a fan of measurement to see the risks as they occur.
But management wants to know, “How much will this project cost? When will this project be done?” I understand that they want to know. (BTW, this smacks of contract negotiation to me.)
Remember, the definition of estimate is guess.
Estimation is Insufficient as a Basis for the Project Portfolio Evaluation
Leffingwell is correct when he says that many management teams want an estimate for large programs. I wrote a series last year about estimation.
If you fall for estimation as your way of valuing projects in the portfolio, you are doomed to fail. Why? Because you are trying to predict the cost or the date when you know the least about the project. I guarantee you do not have a full backlog. I guarantee you do not know everything about the product. I bet you don’t have everyone on the program. You could spend umpty-ump Iteration Zeros and not get to an accurate estimate. It doesn’t matter.
You have to use value as the basis for ranking the projects in the project portfolio.
You don’t have to go into the project portfolio ranking blind, especially if you use agile approaches. You can say, “Do an iteration (or two or three) and create a walking skeleton. What does that tell us?”
This works if your iterations are short, as in one or two weeks. If your iterations are longer than two weeks, this doesn’t work. Sorry, you are now in contract negotiation.
Now, based on the teams’ knowledge (or some small number of the teams’ knowledge), do a SWAG estimate of how big this program is. I timebox this step. “Is this program worth doing?” is a valid question. This is different than an ROI (return on investment) analysis. This is asking, “If we spend time on this program, will we get something valuable that is releaseable to customers before we’ve spent all our money?”
The “is this program worth doing” is a different question than either “can we release every iteration” or “what is the ROI for this program”. The “worth doing” question is a question of magnitude. The “can we release every iteration” is a question in the small. The ROI question attempts to estimate every item in the backlog, the backlog that in my experience is bound to change, which makes estimation moot. (I have seen teams waste team-years in estimation. Yes, I have.)
If you use estimation as the basis for evaluating projects in your portfolio, you will miss potentially transforming projects. You will miss the projects/programs that have the capacity to push you light-years ahead of your competition. Why? Because you can’t estimate them. Why? Because you haven’t done them before! You have no freaking clue how long they take. You can lie and SWAG them. Or, you can provide a walking skeleton and keep re-estimating them.
Or, you can do what we’ve done since time immemorial: provide interim deliverables at frequent milestones and show your progress. Agile allows us to do this very well. So does staged delivery, because it’s an incremental (not iterative) lifecycle, which is why I like it. You build the product and show your progress. If you are from the Engineering side of the house, this is concurrent engineering.
When you do show progress, you build trust. You can collaborate.
Change is Good, Especially in a Program
Remember, in agile, we welcome change. We want the backlogs to change. Remember in Organizing an Agile Program, Part 4: Start From the Teams and Work Up, I discussed how teams could work across the program on other backlogs? You want that on an agile program. Roadmaps are not set in stone. Program roadmaps are meant to change.
The teams need to be able to release every (short) iteration. That’s what makes the program effective. That allows the program to change. That allows the company to release a valuable product faster.
Remember that feature teams releasing is not the same as releasing a product. Product release is a business decision. Feature team release is an issue of integration.
Varying the Backlog Creates a More Valuable Program
When you vary the backlog, especially in a program, you create more value. This is why estimating, in advance, limits your options in the project portfolio. You might need to know if this project is bigger than a breadbox. But this is why I use cards and stickies with my clients when evaluating the project portfolio. People handle the cards and they create a shared sense of what the project is.
Once they discuss the card, now they understand the magnitude of the project. They say, “Okay, we’ll let this project run until this milestone or until we see this, and then we’ll reevaluate.” That’s great. That’s exactly the discussion you want at the project portfolio level. Maybe the milestone is how much money you’ve spent. But it’s more likely a feature set achieved. Or a feature set achieved in a certain window of time.
This is the strategy of your organization. The sponsors need to discuss it. They need to fight about what is valuable to the organization. As long as the product development organization is delivering, chunk by chunk, they can continue to discuss.
If the sponsors really want you to stop delivering to start estimating, okay. You can do that. As long as they realize the % confidence you attach to your estimate is less than 100% until the end of the project, that’s okay. Because the backlog is going to change, right? So, you can never have 100% confidence in your estimate.
Oh, and if you think you can state a single-point date with assumptions? Hah! No one ever hears your assumptions. No one.
What Management Wants
Management wants comfort. Management wants a crystal ball. Management wants the illusion that it had with Gantt charts. I understand that.
And, if you have a not-quite-steady transition to agile, you can’t release every iteration. Or, your iterations aren’t short, as in two weeks. Which means, you can’t change frequently enough, which means you need to do prediction.
I understand management wants something comforting. But I don’t believe in lying to management. I don’t believe in placating management. I believe in asking management some difficult questions and then telling them the truth. These people get paid big bucks. They can handle the truth.
The questions I ask:
- If I discover the program is not on track, when would you like to know? As soon as I know; after I’ve done some remediation work; when I’ve done everything I can and it’s a disaster?
- Please rank the project driver matrix for this program. See the project pyramid and rank each side as a driver, constraint or float. I explain how to do this in Manage It!
- What does success look like? (I have some other context-free questions, also.)
Being Effective as an Agile Program Manager
When you are transitioning to agile, you have some choices:
- Don’t do a program. (Yeah, right.) Start agile with a project and see what you need to do in your organization.
- Mix the agile parts and the non-agile parts, as I’ve been suggesting in my projectmanagement.com articles, Managing Programs with Agile and Traditional Projects and Using Release Trains to Get on Track. Also see the blog post Managing Programs with Agile and Traditional Projects. (I didn’t realize I had reused the title.)
- Use staged delivery or design-to-schedule as a lifecycle. They are incremental lifecycles, and been around forever. Combine them with timeboxes, and you have close-to-agile approaches without the cultural challenge of an agile transition. The cross-functional teams are still responsible for their work.
- Use SAFe, but don’t call it agile. You don’t get feedback often enough. You don’t allow for change often enough. It’s not agile. It is a framework. It’s an approach. But it’s not agile. For me, it doesn’t build trust on either side. That’s the problem I have with SAFe.
- Experiment with my small world networks and explain to the teams of people what you want.
Oh, the option I didn’t mention: Determine what is wrong with your agile transition and fix it. Why can you not release product every two weeks? What is your “overhead?” Or “impediment?” Why can’t you release every week?
If you can’t release as a single team every two weeks, your not-releasing is not going to get better as a program. It can only get worse as you have more teams. Agile will make this transparent. Any program will make this transparent. Agile will make your problems transparent faster.
What Agile Approach Should You Choose?
I write and consult to help you be more effective in a pragmatic way. That’s why I don’t follow a school of anything. I’m not religious about any agile way. I often mix and meld the agile approaches for my clients. They have found tremendous value in that.
If you are starting a transition to agile, first, ask yourselves, “Why do we want to transition to agile?” Agile is about the ability to respond to change. You get this ability by technical and management discipline. It requires both.
You don’t get it from just the technical teams delivering features. If management doesn’t do their part by creating product ownership, creating a reasonable work environment, and managing the project portfolio, the technical teams can’t deliver.
Practice with one small agile project first, before you move to a program. Become accustomed to delivering features every week. Become accustomed to evaluating the project portfolio based on value. Become accustomed to having a single product owner develop a roadmap for a product and a product backlog for that product. That’s difficult enough.
Once you understand what your organization’s issues are, and you can resolve them, now, you can move to a program. You will have more and different issues and risks. But, at least you won’t be starting your agile transition.
Agile is About Feedback and the Ability to Change
If you transition to agile in some way, but you only get feedback from a product owner once a quarter, is that agile? I don’t see how it is. Maybe that’s not the intent of SAFe. But that’s how I’ve heard of some implementations of it. That’s how I read it. Maybe I just don’t understand it. It’s possible.
When I work with teams, I tell them, “We will start with two-week iterations.” They all groan and tell me the iteration is too short. And then we start to slice and dice their stories. I used to ask How Little Can You Do of the project managers about the requirements for the project. Now I ask it of the product owners and the technical team, “What are the acceptance criteria for this story? What does done mean? How little can we do and still add value?”
You are smart people. You can make anything work. I know that. But, at what human cost?
To me, SAFe looks like Theory X management. I’m a Theory Y person.
Earn Trust and Extend Trust
Whether you are part of a feature team or management, you have to earn and extend trust if you are on your agile journey. On a feature team, your job is to deliver finished features. Period. If you are part of management, your job is to create an environment that allows the feature teams to flourish.
If you trust each other, management can ask for order-of-magnitude estimates, if necessary, and make project portfolio decisions based on value. More often, if the project portfolio team is doing their job, and the team is delivering, they don’t need the estimates. The management team learns to cancel/kill a project before they get emotionally hooked by sunk cost.
Learn to Be Effective
Both the technical teams and the management teams need to learn new behaviors when transitioning to agile. From my reading, SAFe reinforces old behaviors. It postpones feedback and doesn’t help management learn to look for value instead of estimates. As I said, it looks to me as if it’s Theory X management.
Agile is Theory Y management. Tell people what you want. Provide them the resources to do it. Get out of their way. See what they’ve done. See if there is more value in the backlog, a short time later. If so, continue to fund the project/program.
If you want more details on project management and lifecycles and ways to think about projects and programs, see Manage It! Your Guide to Modern, Pragmatic Project Management.
I’m still working on getting the first release of Agile and Lean Program Management: Collaborating Across the Organization ready. “Fall” is my best estimate. Not early fall
For an agile and lean approach project portfolio management see Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.
