Agile Misconceptions: Agile is Just a Project Management Framework

If you read least week’s post about agile misconceptions, There is One Right Approach, you will like this one. This week’s article is Agile Misconceptions: Agile is Just a Project Management Framework. If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. We offer discounts for multiple people from your organization. Sign up...

Capacity Planning and the Project Portfolio

I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1) The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2) Problem #1: They have a very large program, not a series of unrelated projects. They also have projects. Problem #2: They want to use capacity planning, instead of flowing work through teams. They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization. If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole. Don’t Predict the Project Portfolio Based on Capacity If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it. First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways. When you have component teams, not feature teams, their interdependencies are significant and unpredictable....

Cost of Delay Due to Multitasking, Part 2

In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk. Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part. You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects. In Manage It!, I have this nice picture of what happens when you try to multitask between two projects. Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point. You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week. But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time...

Cost of Delay: Not Shipping on Time, Part 1

Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development. One of my managers many years ago had a back of the napkin approach to cost of delay. “Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.” I got it. There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point. We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it. We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because...

InfoQ Interviews Posted

While I was on vacation in early January, there were two interviews posted on InfoQ: Ben Linders interviewed Esther Derby, Don Gray, and me about the Change Artistry book. I’m really pleased about the way the interview came out. Thanks, Ben! Back at Agile 2013, Shane Hastie interviewed me. The interview is here. We spoke about many things: the dangers of multitasking, hiring, and agile program management. We had a great time. I only with you could have seen Shane on camera too. Oh...