From the course: Agile Foundations

Challenges with software manufacturing

From the course: Agile Foundations

Start my 1-month free trial Buy for my team

Challenges with software manufacturing

“

- A lot of the ways we work comes out of manufacturing. That makes sense because some of the first projects worked with materials like wood, concrete, and steel. Large companies build cars, roads, and buildings. But when you're working with wood and concrete, you have a completely different set of challenges than when you're working with software. You'd never start building a bridge and then change direction midway through the project, but with software that's much more common. It's easier to reprogram software than it is to rip up steel and crack concrete, but many projects are still governed by the ideas that came out of manufacturing. One of the most common is that there's still a lot of focus on planning out the work. In fact, you could spend as much time planning as you do building. That's why it's still common to hear managers say, "Plan the work, then work the plan." That makes a lot of sense if you're building something like a bridge, ship, or a building. Here you want to plan everything that goes into the project before you start. You also want to break up your project in the phases. So first, you want to plan your bridge, then finish planning. Then you want to build your bridge, then finish building. Then you want to test your bridge, then finish testing. Each of these phases happens sequentially, one after the other. It all makes sense in a world of steel and concrete, but software is much more like science than manufacturing. When you're developing software, you're doing a mixture of building and learning. As much as it's tempting to plan everything out, it's just too difficult to predict all the moving pieces. If you think about even a simple software product, it might depend on an operating system like Microsoft Windows. Then it might rely on several different open source projects. The development language might change or get updated. All these different changes are impossible to predict. Most software products have to deal with something called the cone of uncertainty. The best way to think about the cone of uncertainty is to imagine the relationship between time, knowledge, and cost. So think of it this way. I've spent a fair amount of time on the east coast of Florida. This is one of the states in the US that has to deal with a lot of tropical storms. It's sort of a strange experience to be near a tropical storm. At first, the meteorologists only have a general idea of where the storm will land. So they might say it'll hit landfall anywhere along the east coast. Then as time passes, they gain more knowledge about the storm so they can warn which cities to evacuate. Then just before the storm hits, they know exactly who will be affected. So the cone of uncertainty is the widest a few days before landfall. Then the cone narrows as the meteorologists gain more knowledge and time passes. The problem is that the meteorologists know the most about the storm when it's too late. This is also one of the biggest challenges with delivering software products. You know the most about what it takes to deliver the product only when you're nearly finished. So many of the decisions that you make at the start of your project will be the ones that need to change. Unfortunately as you get closer to the end of your project, it also gets more expensive to make changes so you need to find the balance between making the minimum amount of decisions to get started, but still give yourself enough flexibility to make changes. This balance between making decisions and having enough flexibility to make changes is one of the key parts of the agile mindset. That way you can help make lasting decisions even when you're working within a cone of uncertainty.

Contents