Managing Programs With Agile and Traditional Projects

Imagine you are transitioning to agile. You are a program manager, with a couple of agile projects, and a couple of traditional projects. How do you manage the program? Here’s what a program team looks like. For the sake of argument, assume that Sally is an agile program manager, because we can tell she’s working by feature sets. But, maybe Henry doesn’t know anything about agile. Henry’s team is still working on a feature set. It’s just that it’s working on a feature set as if it’s a waterfall team. If you are the software program manager, how do you manage the program? If you work in iterations, what happens at the end of every two weeks? Henry has nothing useful to say and is bored. He can’t tell you anything about risks. He wants specs. Sally’s program wants to know when Henry’s team is going to be ready to integrate, and of course, there is risk with Josh’s and Tim’s team. You know that if this continues, you will be in trouble. What do you do?  Use deliverable-based planning for all projects. It doesn’t matter if a project is agile or not. Every project must have deliverables. It happens that the agile projects will deliver those as features at the end of iterations. The non-agile projects have to deliver the deliverables at interim milestones. All projects use an incremental approach to delivery. No one can wait until the end of the program to deliver. For some project managers, this is a huge change. For some testers, this is a huge change. Use rolling wave planning to plan the...

Why Does Management Care About Velocity?

I’ve been talking to people whose management cares about their velocity. “My management wants us to double our velocity.” Or, “My management wants us to do more in a sprint.” Or, “My management wants to know when we will be a hyper-performing team, so they want to know when we will get 12x velocity like Scrum promised.” “Double Your Velocity” is an agile schedule game. It’s easy to manage–you double the points you assign to your stories. Whee! You’ve just doubled your velocity. No muss, no fuss. But let’s understand what management really wants. What your management wants is for the team to do more in a given time period. That’s why they want more in a sprint, or for the team to become a hyper-performing team. So, let’s look at the project conditions for a hyper-performing team: No multitasking. Management must manage the project portfolio. You can ask your managers to do this. Really, you can. The customer or product owner must rank the features. The project team must already know how to work together. That means you can’t add or subtract people. The team must have already formed, stormed, and have normed. They have to know how to work together. They have the physical infrastructure: build servers, phone lines, computers, whatever that they need, and they know how to use them. Do not underestimate this part. If you don’t have this part, you can’t do continuous integration, for example. The team needs enough people who play enough cross-functional roles: developer, tester, and whatever else the team needs, so that the team can finish its work. I am...

Roll Your Own (Agile Lifecycle)

Imagine this scenario: you want to transition to agile, and you have a geographically dispersed team with people all over the world. You have two developers in the UK and two in Boston, two testers in Portland, Oregon, a product manager in Brazil, and you, the project manager are in Sweden. And, you are pretty sure that transitioning to agile would make a difference to your project, because you’ve used agile before on a different project in a different organization. And, because you are geographically distributed, you know can’t use agile-out-of-the-box. What do you do? One approach is to start with the principles of agile and decide how to create an agile environment that works for you, your team, and your context. You create your own agile lifecycle. That’s what Joakim, a Swedish project manager did. Joakim and I spoke when he was organizing the team. He asked about the iteration length. I asked if the thought the team could manage a one-week iteration. He thought not; he thought a two-iteration would be a big-enough shock to their system. Why a short iteration, such as one or two weeks? Because the team needs the feedback about everything, not just the code. They need the feedback about their planning, about their standups, about their stories, about how they work together, everything. Everything about their transition to agile is an experiment, so they need to start with a short iteration. One week is even better, but for many teams that seems impossible to imagine, so they start with a two-week iteration. This team was lucky, and the product manager flew up...

What’s an Agile PM to Do?

You interviewed with a team a month ago, and you were a little concerned. It didn’t seem as if they were keeping to their iterations. Their product owner wasn’t grooming the backlog often enough to keep the backlog filled for the release meeting. They seemed to have an awful lot of defects piling up at the end of the iteration. And, it sure looked as if they finished only two or three stories every four-week iteration. But you really like the product domain—it’s where you want to go with your career. And you think you can learn a lot from your VP, so you decided to take the job. Now, it’s your second day on the job, and you realize that your original concerns have understated the problem. Not only does your project have all of those problems, but everyone is working on several other projects simultaneously, including the testers. The iterations are too long. The stories are humungous. Everyone is multitasking. The product owner is not available enough. This is a rich problem-solving environment—the project has a ton of problems. You know you can help the team fix these problems. You just have one problem. Where do you start? Gather Current Data When I spoke with my colleague, Mike, in this position, I suggested he start with a retrospective to help people see the current reality. “But Johanna, it’s not the end of the iteration. How can we do a retrospective?” You can call it something else, such as an “intraspective,” so that people realize you are looking at data between the beginning and the end of an...

The Silent Project Killer

Agile projects, especially if you are starting your agile transition, can have plenty of problems. Some are technical debt problems, such as the build taking too long or having insufficient automated tests to know if your changes are helping or hurting the system. But there’s another insidious management problem when many teams transition to agile: when the project team is supposed to work on more than one project at a time. Sometimes, the team perceives this problem and solves it during their retrospectives. But if the team members have been accustomed to multitasking for years, they may not even realize this is a problem. Or if the team realizes that they’re multitasking, they may not know how to solve the problem. That’s when a few observations or measurements may just be what your team needs. The Silent Project Killer If you have people multitasking in a non-agile project, you might not know until the end of the project (or until some interim milestone) that the team members have not spent enough time on your project for far too long. But on an agile project, you can tell inside of one iteration. Multitasking slows everything down and makes people forget where they were. When developers and testers multitask, they create problems or lose track of where to look for problems. So why do managers insist on asking people to multitask? There are two chief reasons. The first is that managers multitask all the time, so they forget that that technical work is different and that technical people can’t afford to multitask. The second is that when you have a large...