Landing Agile Typical Problems: Two Lessons from New Product Development
I started to use the agile development model to lead the team to deliver quickly in 2004, and I have a lot of experience and lessons along the way. Here are two lessons from past failures:
1. The role of PO is not properly understood: PO must communicate directly with customers and truly represent the customer's intention, otherwise the product is likely to fail
The key customer communication is not in place, which leads to the launch soon, and the customer thinks that the key function PO does not know. At the beginning of product development, the company had no product owner (PO) and no agile development model. The business department communicated directly with customers and then fed back to the R&D department. The problem at that time was that the business department did not have time to communicate with the R&D department, which was often a one-page requirement, and the details were not communicated clearly with customers. Later, the company established a product department, the business department fed back the demand to the product department, and the full-time PO communicated with the R&D department. Please pay attention to the way of information flow: customer -> business department -> PO -> R&D department. Indeed, the needs are very clear and the quality of the R&D department is constantly improving. However, the biggest problem has arisen: the customer's needs deviate from the customer's original intention after being relayed by the business department, the product department has not communicated directly with the customer, and the Demo business department after Sprint has not communicated with the customer. The deviation of demand is constantly accumulating ...In agile development, the end customer must be involved in the development process, especially Backlog and Demo. This problem arises when the PO does not represent the customer, especially when the PO is not in direct contact with the customer.
2. Don’t think it will give the R&D team a good time to refactor
At the beginning of product development, in order to go online as soon as possible, the technical architecture, performance, load balancing, high reliability, etc. of the product were not considered. I always thought that it could be continuously refactored, but in fact, the company would not give the team a complete time to do it. Refactoring, constant business demands take up almost all of the team's time. As a result, the fragile architecture becomes weaker and weaker, and it takes longer and longer to complete a new requirement. To sum up now, the high scalability and stability of the architecture are the highest priority and can be continuously expanded to meet business needs. Website performance is a secondary priority, especially static pages before login. CMS (content management system) is also very important. It is best to do it in the early stage of the project. You can choose the way of outsourcing. Otherwise, a large number of page modifications will be made according to the release process. It is necessary to consider clearly that Agile Modeling is indeed practical in practice.