Thoughts on the Quality of things delivered by agile demonstration under the product R & D system

I have been practicing agile ideas and some agile processes, but for many reasons I have not completely copied agile processes for practice, but have cropped and explored them according to some restrictions. On Wednesday, I communicated with the company's R & D management department and found that an essential conflict between our practice and agile thinking is that the quality standards for the deliverables of the presentation are different. (The first is shanzhai agility, and the second is formal agility)

 

Our process defines the deliverables delivered by the presentation as self-testing standards for R & D personnel, and the deliverables delivered by the agile process demonstration conducted by the R & D Management Department as the standards verified by testers, the two standards differ greatly, and their thoughts are also quite different. The first figure shows our practice process. After self-testing by R & D personnel, the status is complete. The second figure shows the agile process defined by the R & D Management Department. After R & D, it must be tested and verified before it enters the completed state. The results of our processes are deliverables of testable states, while those of the management processes are deliverables of users.

The main reason for the divergence is that, under the product R & D system, the overall R & D process is still biased towards waterfall-based processes, and risk control is also biased towards waterfall-based thinking. Before products go public and target customers, all activities are carried out in a black box. From the perspective of R & D, if the agile process is followed, there will be product R & D activities in the time when products are listed. This is unacceptable from the perspective of the old waterfall thinking, therefore, we adopted the first process. In the final stage, only testers can perform tests, rather than R & D.

The agile process advocated by the R & D Management Department can release products at any stage, and can be listed in advance at any stage to enter the market and gain market opportunities. In this case, the essential difference is great. If the date of release remains the same, the effect of the second agility is not particularly impact compared with that of the first agility, and at any point in time, the agile process of the first kind of shanzhai certainly has more functions than the formal process of the second kind, because the second kind will naturally spend more time to achieve deliverables, of course, in the later stages, the two are almost the same.

Other thoughts on the two:

1. Shanzhai agility is testing and demand-oriented. The product beneficiaries can also see the product. Some differences of this product will be solved before the tester gets involved. In the case of formal agility, early intervention by testers may result in a portion of the workload becoming ineffective.

2. Shanzhai agility is delivered to testers after being tested by R & D personnel. It ensures certain product quality and enhances employees' deep understanding of product quality. The formal process may cause R & D personnel to ignore the self-testing quality because of the early intervention of the test, because there will be testers to check the quality and do not focus on self-testing, of course, you can also introduce self-testing standards to solve the problem.

3. Shanzhai agility is delivered to the tester after demonstration, so that the tester can test the product problem during the next iteration of the employee, which is relatively less stressful. Formal agility is the process of testing personnel in the iteration process, so there is a lot of pressure on testing, testers must verify all the products before the end date of the iteration, ensure that the product can be delivered. If the ratio of the R & D personnel and the testing personnel is out of balance, the pressure on the testing personnel will gradually increase as the proportion increases, at the same time, testers may become bottlenecks, resulting in a large amount of free time for R & D personnel.