What is "successful projects": Talking about the value of software

Before starting the text, I want to tell two stories: The story about software projects.

Story 1

There are two software projects (called "Project A" and "Project B"), whose budget at the beginning is 50 individual months and the time is 5 months.

Project A is completed in five months, costing 50 people a month

Project B is completed six months later, costing 70 people a month.

Readers who have been in the software circle for many years must have their own judgment on this story-and I can roughly guess what the judgment is. But don't worry. We have another story.

 

Story 2

There are two software projects (also known as "project a" and "Project B") that both plan to deliver 200 features at the beginning.

Project A delivered 200 originally planned features at the end of the project, but the customer found that about 30 of them were not very useful, the other 30 useful functions can be implemented only in the next project.

Project B delivered the first version at the end of the first month, and then delivered a new version every two weeks. During the project, the customer made a business adjustment, added 90 new features, and shelved 50 functions that were of little use. In the end, the project delivered 240 features.

Smart readers may have noticed that the two stories are the same thing, the same two projects. Now, my question is: which project is more successful?

This question is not easy to answer-in fact it does not have a standard answer. From the standpoint of many software companies, Project A is an ideal success project: to complete predefined tasks by time and by cost. Please note that I use the word "ideal". I will explain this interesting word later, because the actual software project is often less ideal.

What if I stand on the customer's standpoint from another angle? Customers who pay for software may have different ideas. Project B has delivered the first workable version one month after the start. Since then, the customer has started to use some of the features of the software, and constantly feedback the feelings you use to the development team. In the real business operation process, the customer even found a new profit model and made a large-scale business adjustment. The results of this adjustment are also intuitively reflected in the software project. Although Project B's overall delivery speed is lower than Project A's, all the features it provides are what customers really need and they provide real value to customers-not to mention, the customer started using the software several months in advance.

In fact, this is an article about the value of software.Article. Similar to "successful projects", different people have different definitions of "software value. However, as a customer who pays for software, his definition of software value is clear: how much value he can create from the use of software, how much value the software can provide for his business, this is the value of software. Or a little more concise:

 

Software value comes from use

This is why many customers prefer "Project B"-I do not intend to claim that all customers share the same view. I will give a counterexample later, however, there are at least a few customers who support this view. Because they are in a cruel and fast-changing business environment: their suppliers are changing, their customers are changing, and their economic and policy environments are changing. All these changes force their business to change. What's even worse is that today's era of economic globalization is an era of Fast fish and slow fish, the customer is eager for a new software system to bring them a competitive advantage-even if the software system is not completed, as long as it can be put into use. Finally, the customer is not sure about what the new software system should look like, and their ideas will often emerge after the software is actually used. These factors make these customers more willing to use the software as soon as possible, provide feedback, and continuously improve the software, instead of putting forward a set of requirements, and then waiting for a few months to get these functions intact

 

A real case

In a thoughtworks project, developers released the first version within one month after the project began-only some simple data collection functions. This conversation occurred at the release presentation ......

 

Developer: This is our first feature. We collect data from text files, Excel data tables, and legacy databases. Our database now has this data ...... (Display database structure)

Customer: Mm ...... Interesting. If you can make such a query (write the query requirements), the results may be useful.

Developer: however, there is no such query operation on our interface.

Customer: Ah, I don't need to operate the interface. I just need to make a query every night and send the report to my mailbox.

Developer: So ...... Another problem is that it takes us a few days.

Customer: It doesn't matter. I have to release other tasks for a few days. I 'd like to see this report.

Developer: Well, we will start providing this report next week.

How is the result? One week later, the customer began to receive the report every day and made some analysis and decisions based on the report content. Just a few months later, the benefits of this report to the customer have exceeded the investment of the entire project-the development of other parts of the project has not been completed yet.

How can this customer define a "successful software project "? Well, maybe this project has been over the expected time and may have invested more manpower, but this does not mean "project failure"-it is just a higher cost. The key lies in how much benefit the cost will bring to Him, and whether his return on investment is cost-effective. For this customer, if the project can provide him with software that is available and can create maximum value at any time, it is a successful project to realize valuable ideas at any time, as mentioned in the story.

So, dear readers, please forget the word "agile" in the title of this article. What we are talking about here is nothing more than a software development method that creates maximum value for customers. There are many such methods, but they share a common feature: deliver the software that can work as frequently as possible, so that customers can start using the software as soon as possible, create value from use, clarify ideas, and provide feedback. Taking thoughtworks projects as an example, these projects usually release the first version within one month after the development phase is started, next, a new version is released every week or every two weeks. Each version is a working software, and each version has more functions than the previous version, and each version contains the features that the customer deems to be the most valuable so far. The process of developing the next version is called iteration ", the biggest commonality of these development methods is "iterative development"-instead of delivering all the functions in one brain, it is to add and incrementally deliver the most valuable functions each time.

 

The dream and truth of Software Development

Return to the two stories at the beginning of the article. As I have said, Project A is an ideal success project for many software companies. So what makes the situation less ideal?

The answer is a word familiar to all software developers: demand changes. In a real project, the customer generally does not wait until the last day to accept the entire project, because he knows that his business is changing. At this time, demand changes will emerge, along with round-trip competition and bargaining. What's worse, a large number of demand changes occur in the late stages of the project-because many of his ideas came into being only when the customer saw and used the software. With this "last-minute demand change", project expiration and budget exceeding have become commonplace. It's really lucky to be able to complete delivery like Project.

To address the nightmare of demand change, software developers also invented another word: Change control. This interesting word implies that demand change is a "bad" thing that requires "control. But from the customer's point of view, isn't it the most valuable thing that he asks after using the software himself? Is it reasonable to "control" the requirement for truly creating business value?

As I mentioned earlier, not all customers prefer iterative development. Which software projects do not necessarily require iterative development? From the content of the entire article, it is not difficult to see that if the customer's business will never change, if the customer's demand is extremely detailed, if the customer does not need to start using the software as soon as possible to recover the cost, so iterative development will be much less helpful to him. However, if you think carefully, there may not be many such examples-maybe much less than you initially thought. A good example is the computer control system used by the Shenzhou 6 rocket. How many examples are there? Readers may wish to think about it on their own.

If I am lucky enough, some readers may have been tempted by this article: Since there is such a good software development method, since it can create greater value for us, so what are you waiting for? Let's get started right away. It's not that easy. To make iterative development a reality, to ensure fast and frequent delivery as possible, to ensure that each delivery is the most valuable function, we-including software developers, software companies, and customers-need a lot of changes. There are both duties and rights, development process and team restructuring, as well as practical guidance at the technical level. These are the content covered by Agile Methodology. Without these things, "creating the maximum value for the customer" can only be a blank saying. In subsequent articles, we will gradually introduce all aspects of Agile Methods Based on the practical experience of thoughtworks.