An Agile Approach to a House Remodel

You might have noticed I’ve slowed my blogging in the past few weeks. I’m fine. I’ve been a product owner/customer for our new-to-us house remodel. In the last several weeks, almost every single day, Mark and I have taken some time to go over to the new house to see the progress and provide feedback to the guys working on site. We do work directly with the site project manager. I don’t know how he meets with the subcontractors (painters, plasterers, tilers, etc.) All I know is that we provide him feedback just about every day. He tells us when it’s time to select the: tile, faucets, bathtubs,  paint colors, new front door, decide on kitchen design, everything. We meet with the people who are our vendors. They send the specs or material to our builder. When we were working on the design of the house, we iterated on it with the builder. We had at least three iterations on paper. Maybe four. We discussed how we would live in the house with him. As we discovered things about the house, we modified the design. (Does any of this sound familiar?) Since it’s a house, we haven’t modified structural things, such as how big the addition is, or where the windows are. However, this week, we changed my bedroom closet. That was because I didn’t understand the initial design, and I called a halt to where we were. Our builder is great. We are trying to be great customers, too. It’s a two-way street. This is why my blogging has been slow. I’m spending time at the house. Today,...

Fixing—or Not—Healthcare Dot Gov

Did you see Dwayne Phillips’ post today, Adding People to a Late Project? Dwayne says: Adding people to a late project only makes it later. We have known this for decades. Especially in the article he refers to, it seems as if there might be no end to the number of people added. Did anyone ask the people on the project if they needed more people? Maybe they needed to know which requirement is top on the list. Maybe they needed acceptance criteria for each feature. Maybe they needed each feature to stay put for more than a nanosecond. There is more than enough blame to go around for this particular project. Most of the blame has nothing to do with the developers and testers. Now, if they had asked me what I would do, here is my plan. What is the most important thing people need to do to sign up for health care? Get a cross-functional team to work on that, get it to done, and make sure it works. Use reviews, acceptance criteria, release criteria, whatever it takes to finish the work. Timebox that work to one week. Make sure you have performance tests. Roll it out. (Oh, do not let people work overtime. Make sure they can keep to a sustainable pace.) What’s the next most important thing? Do that in the second week. What’s the third most important thing? Do that in the third week. Now you have a shot of understanding the architectural needs. Go fix the underlying architecture. Make sure you have unit tests, integration tests, database tests, performance tests, and oh...

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

Are You Making Progress or Spinning Your Wheels?

Summary: While managing a long project, it’s easy to lose track of progress. And, when that happens, how do you even know whether you’re still making progress? In this article, Johanna Rothman offers suggestions to help you take your project one step at a time and keep it under control. When I coach managers or leads, one of the most frequent questions I hear is: “How do I know I’m making progress?” Typically, the manager or lead is working on a long project or a long initiative, such as transitioning to agile, and it can be difficult to know if you are making progress or spinning your wheels. Plan in Small Chunks No matter what project you are working on, plan in small chunks. Sure, keep the vision of the end product in mind, but know that you can only do so much in a given time period and plan what you can do for the short term. One way to do this is with rolling-wave planning. As an example, suppose you want to plan a large Web application release. You would note your major milestones, such as “UI walkthrough for shopping interface,” “financial integration with financials package,” or “limited release to trusted users,” in addition to “release for general public.” Now, take the first milestone and ask yourself and the project team, what do we need to do—in detail—to get to that milestone? I like making rolling-wave plans on sticky notes on the wall, not in Gantt charts. I ask people to plan in inch pebbles—one- or two-day tasks that are either done or not done. With inch...

When You're in Chaos, Try Baby Steps

About a month ago, I spoke with a project manager who’d inherited a project in chaos. No one was making progress. He was stumped–he’d never worked on a project where the developers couldn’t do anything, the testers couldn’t do anything, and time was just slipping away. I suggested he try baby steps. What’s the first thing the project needs to deliver? Just focus on one small thing. He did have an answer, but the feature was large. He thought it would take 2-3 weeks to deliver it, coded as well as tested. Since he knew what the team needed to do, he could use timeboxes to focus people’s attention on that work. I suggested he use one-week timeboxes, to make sure people figured out what they needed to do, just for the first week, and that the project team work together to make sure they were all working towards the same goal. Once he got the first week working, he could do the same thing for the second and third weeks. The reason one-week timeboxes work to focus people is that when a project is in chaos, people tend to be in chaos too. They get easily distracted. A timebox, especially a short timebox is really good for helping people make progress and breathe. He had never done week-by-week planning, so I suggested yellow sticky scheduling, focusing on the deliverables that would finish the feature. It’s not a hard concept, so he was able to do it. I caught up with him last week, and sure enough the timeboxes along with focusing on one feature at a time worked....