Reasons for Continuous Planning

I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective. There is a problem with commitments and the need for planning for an entire quarter. This is legacy (waterfall) thinking. Committing is not what the company actually wants. Delivery is what the company wants. The more often you deliver, the more often you can change. That means changing how often you release and replan. Consider these challenges for a one-quarter commitment: Even if you have small stories, you might not be able to estimate perfectly. You might finish something in less time than you had planned. Do you want to take advantage of schedule advances? In the case of too-large stories, where you can’t easily provide a good estimate, (where you need a percent confidence or some other mechanism to explain risk,) you are (in my experience) likely to under-estimate. What if something changes mid-quarter, and you want more options or a change in what the feature teams can deliver? Do you want to wait until the end of a quarter to change the program’s direction? If you “commit” on a shorter cadence, you can manage these problems. (I prefer the term replan.) If you consider a no-more-than-one-monthly-duration “commit,” you can see the product evolve, provide feedback across the program, and change what you do at every month milestone. That’s better. Here’s a novel idea: Don’t commit to anything at all. Use continuous planning....

Embracing the Zen of Program Management

The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management.  I hope you like the information there. If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta...

Small Internal Releases Lead to Happy Customers

If you saw Large Program? Release More Often, you might have noted that I said, You want to release all the time inside your building. You need the feedback, to watch the product grow. Some of my clients have said, “But my customers don’t want the software that often.” That might be true.  You may have product constraints, also. If you are working on a hardware/software product, you can’t integrate the software with the hardware either until the hardware is ready or that often. I’m not talking about releasing the product to the customers. I’m not talking about integrating the software with the hardware. I’m talking about small, frequent, fully functional releases that help you know that your software is actually done. You don’t need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don’t believe in hardening sprints. Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can’t finish the tests. Your testers might not be automating enough. Let’s not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn’t you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix. Here’s an example. I have a number of clients who develop software for the education market.  One...

Large Program? Release More Often

I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month. Yes, have a real, honest-to-goodness release once a month. I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?” Okay, release every three weeks. I’m easy. Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum. Large programs magnify this problem. If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly. Here’s what you do: Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks. If you have three-week iterations, plan to release every three weeks. Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams...

Pragmatic Manager Posted: Time for a Decision

I published another Pragmatic Manager this week, Time for a Decision. It’s about program management decisions, and collaborating across the organization. Do you receive my Pragmatic Manager emails? If you think you are on my list, but are not receiving my emails, let me know. Some of you long-time subscribers are not receiving my emails because of your hosts. I am working on that. Some of you don’t subscribe yet. You can subscribe. I write something valuable at least once a month. I post the newsletter on my site when I get around to it, later. I hope you enjoy this newsletter. If you don’t already subscribe, I hope you decide to sign...

Scaling Agile? Think Out, Not Up

I taught the Influential Agile Leader workshop with Gil Broza last week in Edinburgh. (That’s why I was quiet. I was traveling and teaching. No time for writing, blogging or tweeting.) One of the participants asked me what I thought about scaling agile. Before I could explain about small-world networks, not hierarchies, he said, “I am sure the way you scale agile is out, not up. Well, blow me over with a feather. He said it more simply than I did. If you look at my picture of a technical program team, you can see that’s how it works. The technical program team has feature teams alone, if they can be alone. Joe, Tim, and Henry all have stand-alone feature teams. If they need to be “collected” because they work on related features, they collect themselves. Sally has collected feature teams. The teams scale out, at the technical level, not up. The technical program team does not have to get to bigger. When I ran programs in the past, I emailed the program team meeting agenda (it was a problem solving meeting) to everyone, and say, “Here are the people I need to attend. Everyone else: let me know if you are attending.” Now, there’s a limit to how big a program can get for the software program or the hardware program. At some point, the it’s so hard to coordinate the interdependencies, it’s not worth the bigness. If the teams are delivering small features all the time, you don’t need as many people as you think you do. The smaller the batch size, the fewer the people required....