Keys to Chartering an Agile Project

When you’re a project manager for a traditional project, it’s easy to write a project charter. You can sit in your office and write it alone, if necessary. You don’t have to involve the team. On an agile project, is that the right thing to do? Should you even use the same template? Agile projects are collaborative. You might not have an agile project manager for your team. You might have a ScrumMaster or a coach, neither of whom is a project manager. You might not have anyone who fills exactly the same role the project manager used to fill. But you still need a charter–it helps the team see the vision and the release criteria, among other potential other valuable information. How do you charter an agile project? Do you know where you’re headed? The first question I ask teams is this: Do you know where this project is headed? I don’t want to know about this iteration. The team might have an iteration goal. I want to know if they have a vision for the entire project. If you are transitioning to agile, you might have a project that has to fix some technical debt and a number of defects. Do you want to call that vision “Fix the debt project”? I don’t think so. It’s true, but it doesn’t “wow” anyone. It doesn’t explain why you are doing the project and why anyone should care about doing the project. Instead, a vision such as, “Technical debt payoff to make everyone’s lives easier by 10 hours a week” does have a wow factor. If you add a...

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...

What's the Culture on Your Project?

Now that the election is over, we have an opportunity to reflect on some of the project management and hiring practices. I’m going to blog here and over at Hiring Technical People because the bits are just too juicy to leave untouched. If you read nothing else, read Inside Orca: How the Romney Campaign Suppressed Its Own Vote. There are other very interesting articles about Orca, such as The Romney Campaign was a Consultant Con Job. Here’s what stood out for me: The lack of a project dashboard. With no data about the project as the project was built, there was no way to know what was going on at all. No information radiators, no nothing. No evidence, no data at all. It doesn’t matter what lifecycle you use, no data is a no-no. No deliverable-based planning. Again, it doesn’t matter what lifecycle you use, without deliverables, you are up against the immovable election date. No one is going to move the election date just because you haven’t tested or tested enough. Insufficient risk management. If this was the app to save the Republican party, why did they outsource it to consultants who didn’t care and didn’t do (any) risk management? This is beyond me. If they realized in June they had a problem, they still had time to do something different. But they didn’t. They kept charging along. You should read all the comments, too. Or, as many as you can stand. But what this says is this was a project where there was no openness about the potential risks. That is a very dangerous project culture. Makes...

Similarities and Differences in Project Management

I’m in Las Vegas waiting to get on a plan to Los Angeles to go to New Zealand for SDC. I led a workshop yesterday for real estate project managers about how to define success and manage some of the early-in-the-project risks. We discussed issues such as the Hudson Bay start, context-free questions, release criteria, iterative planning, interim milestones, and inch-pebbles. We had many discussions and a couple of simulations. I learned that whether they are in software or real estate, some of the similarities of project managers are: Our customers change their minds, so we need to be able to adapt as the project proceeds. Timeboxes help us and our customers focus on what’s important for now. Finding the right person to help define what’s driving the project may not be easy whether you are in real estate or software. Hudson Bay starts are useful no matter what your project is. Iterative approaches to planning and scheduling are useful because they help other people see where you lack knowledge. Inch-pebbles are a fine tool to help people break down their tasks and help you see where work is progressing and getting stuck. And some of our differences are: Because we have ephemeral product and can release more often, we should take advantage of that, to get feedback. When I ran a simulation that allowed them to get feedback every 8 minutes, some of them said, “We want to do this at work!” Their timeframes are long, because their buildings are big. When I spoke about rolling wave planning and planning for one month at a time, they translated...

What Should Done Mean, Coda

Last week at Agile 2010, Joshua Kerievsky and I facilitated an Open Jam session (open space) about what done means. We discussed a variety of points. I believe we eventually agreed that context matters. It’s important to know what your product success criteria are. If you don’t use a project charter where you define success criteria, consider doing so. (Yes, in Manage It!, I have a discussion on what success means. I have downloadable templates too.) You also need to know what your release criteria are–when is the product good enough to release? Do you have a product that can be continuously deployed, or does it need to be deployed discretely? Success criteria are not the same as release criteria. You may decide to release something now, to get some feedback from some customers, even if it doesn’t meet the product success criteria. Your success criteria might be about the process, not the product. For products that can be continuously deployed, you can obtain customer feedback, so you can consider an approach that says done isn’t done until customers accept it. I didn’t ask then, but I will ask now: what happens if some of your customers really like the feature and some don’t? What do you do? (The benefits of sleep Which customers do you listen to? For products that don’t lend themselves to continuous deployment, you have some options: Make sure you have iteration goals. For each feature on the backlog, before you start it, ask “How does this feature move us closer to our project release criteria and product success criteria?” If you don’t have iteration...