The difference between Agile and traditional projects
After 2010, the popularity of agile project management has increased day by day, especially in Internet companies, you are embarrassed to say hello to others unless you have the name of “agile“.
Today we will discuss whether the statement that “agile projects are faster than traditional projects” is true or not.
Below, we analyze this problem through a practical and interesting example.
Suppose the manager of a brick factory receives an order for 20,000 bricks.
We simplify the process of making bricks into two steps:
- Making the mud billets for bricks
- Firing them into bricks in a brick kiln.
- The workers in the factory can make 1000 bricks a day;
It takes 2 days to burn a furnace of bricks; my brick kiln is relatively large and can burn 20,000 bricks at a time. We assume that firing bricks requires workers to participate in the whole process and cannot make blanks at the same time.
There are two workers in the factory, “Liu Tradition” and “Wang Agile“, with completely different operations:
According to Liu Tradition, 20,000 bricks are made first, and finally they are put into a brick kiln for firing, and they are delivered to customers at one time. Wang Agile delivered bricks to customers in four batches, 5,000 pieces at one time. Let’s do the elementary school math problems and see the respective construction periods of the two people.
Liu Tradition: 20000÷1000+2 = 22 days
Wang Agile: ( 5000÷1000+2 ) ×4 = 28 days
Liu Tradition seems…faster?
If we map the above brick factory example to the field of software research and development: development corresponds to making bricks, testing corresponds to burning bricks, and bricks represent deliverable software products. For the same software product with a workload of 20 person-days, the “Liu Tradition” team needs 22 days, and the “Wang Agile” team needs 4 iterations for a total of 28 days. So, going back to our original question, if you think this “fast” is the delivery of software, you are wrong. Because: Agile mode does not make software “absolute delivery speed” faster!
As an agile evangelist, if you make your boss think agile is “absolutely” faster, he’s bound to be disappointed. Because in a sense, agile is even slower!
So why are there so many people doing agile?
Let’s take the example of a brick factory. In fact, we came to the conclusion above that the “Liu Tradition” method is better. There are two important “implicit” assumptions.
- The finished bricks produced within the construction period have no value to customers
According to the method of “Liu Tradition”, it takes 22 days for the customer to get the first brick, while “Wang Agile” can give the customer the first brick in 7 days. If this customer only needs 20,000 bricks available after 22 days, it is fine: the bricks you gave me in advance are also piled on the construction site, not only useless, but also occupy my place. There is no doubt that Liu’s traditional way is better.
- The needs of customers have not changed
In our story, the customer who bought the bricks needed to finish the dam repairs in time for the rainy season. According to the past meteorological experience, 22 days after getting the bricks and then starting the construction, the time is very abundant.
It has been raining for the past two days, and the factory manager was resting at home when a phone call interrupted him: “The bricks you have produced will be delivered to me immediately, as many as you have!”
The factory manager was a little confused and looked at the calendar: “Isn’t there a week before the delivery date? What’s the matter?”
“It has been raining in the past two days, and the rain has been particularly heavy. It seems that the rainy season is much earlier this year! According to the meteorological department, it will only get bigger and bigger. ”
By this point, the story will proceed in two lines:
Liu tradition model:
“I have 15,000 bricks in my hands…”
“What’s the use of adobe? I want bricks! Bricks!”
“If you are in a hurry, I will work overtime and give you 15,000 yuan in 2 days…”
“Two days? I can’t wait for two hours! Wait two days for you, let alone your bricks, and our entire city will be flooded…”
“Hello…” Liu Tradition held the hung up phone with a blank face…
Wang Agile Mode:
“We now have 10,000 ready-made bricks in our warehouse…”
“Don’t say anything, just get ready, I’ll send a car to pick it up right away!”
“Let’s use these 10,000 bricks first, this is the first priority!”
Hanging up the phone, Wang Agile put on a raincoat and rushed out…
Let’s take a look at the above scenario and apply it to the field of software delivery.
Assumption 1, most software delivered early would yield some value if fully functional.
Even if it is an experimental product, you can test how the user responds and how to adjust it later. Not to mention a cool new feature that is released in time and could have a big impact on the direction of the product. The most classic example is the WeChat red envelope. It must be the most suitable scene for this function to be used during the Chinese New Year. If it is released after the new year, its effect will definitely be greatly reduced.
Assumption 2, because software tweaks “seem” to be relatively cheap, so change is more likely.
In the example of our brick factory, Liu Tradition can also make 15,000 bricks in 2 days in an emergency. In actual software development, if the waterfall model is used for development, it is highly probable that all functions must be integrated within 22 days before delivery to customers.
It is conceivable that when the external situation has undergone “earth-shaking” changes in the traditional model, we can easily fall into a dilemma: if you continue to complete the project, the customer may no longer need it; if it is not completed, there will be no output from the initial investment, which is really wasteful.
So, to sum up, being agile means faster delivery of value and faster adaptation to changes, not the speed at which projects are completed.