Agility in product R & D: deficiencies and directions

(View Original: http://gigix.thoughtworkers.org/2007/11/13/improving-agile-in-product-designing)

Infoq reported that agile methods are not a silver bullet in product development. Of course, we have long known that there is no silver bullet, but it is still necessary to emphasize it again, especially when this agile method is getting popular in China.

One thing is certain, that is, agile methods cannot solve fundamental problems in the business, especially when the business itself cannot decide how to do or how to determine the priority, agile Methods cannot help.

Almost at the same time, javaeye posted a post entitled "XP or not" and put forward almost the same point of view. The author said, "XP isn' t suitable for every type of software development, it has its own suitable area", obviously this is beyond doubt and we don't even need to discuss it. What we should do is to find out why and how agile methods (XP) are not suitable for product development, and find out the direction for improvement. As I replied in the infoq article,

Only agility is insufficient for product R & D. AgilityWhat you wantBut there is no way to guaranteeOkay.OrCorrectOrPopular. As an agile method derived from internal IT projects, it has a tendency to implement functionsUsableRatherPerfect. This is good for internal IT projects. The two functions that can be used often provide much more value than a perfect one. However, you are in trouble for public users, because imperfect functions are very likelyNo one is using it..

Wang Xiaoming apparently had a lot of ideas after discussions with me on the plane, and these ideas seem quite reliable. The root cause of the problem is that, in the face of internal enterprise users and public users, the concept Integrity Assessment (priority) is completely different. Similarly, there are also availability-do not misunderstand, I am not planning to say that agile projects must ignore conceptual integrity or availability. But the experience of many agile teams comes from enterprise IT projects like C3, which blinded them and made them unable to see changes in software feature valuation. This problem is easy to solve. As long as they realize that the functionality is not good enough, no one will be able to create any value, they will re-adjust their valuation of various software features, because the core of agility lies in value-driven.

The less easily solved problems are the lack of methods and tools. That's why I say "only agility isNot enough". For example, to improve availability, we need interactive design. There are also many such methods and tools for product development that affect software features from different perspectives. AgilityWhat you wantBut if you only have agility and lack these methods and tools, you may never know yourself.ExactlyWhat. However, the more serious problem is the attitude towards these methods and tools,

Interaction design is one of the ways to improve. However, many agile organizations do not fully understand this. They only ask the interaction designer to perform an evaluation and design in the project. This is not enough, as if QA is not enough before the software project is delivered. The quality comes from the entire process, and the same good interaction design also comes from the whole process.

The agile team is fully aware that quality assurance must run through the entire process, which is the root cause of the higher software quality brought by agile methods-test-driven and continuous integration are of course good practices, however, these practices can work because we pay attention to quality at the process layer. Do we pay attention to this process for conceptual integrity, availability, and other software features? As I mentioned in infoq's reply, a complete set of product design methods must be supported in order to make a good product. This is the direction for us to learn and explore.