I have been asked the same question twice recently: If a software requires a lot of Intensive design work, resulting in an independent design and development team, how should we implement agile development?
On the whole, agile development does not want the separation of design and development, because it will produce a "design document". Because the two teams are separated, the design documents must be quite detailed, in addition, most of the reviews should be conducted during the handover. Otherwise, it is difficult for the development team to understand and compile the documents according to the requirements.CodeAnd may lead to conflicts between the two teams.
In Agile development, this is generally the case: developers are put to the development team, because they generally have a higher level of technology than developers, therefore, you can serve as the backbone of the 139 Team (refer to the blog related to the "139 team"). On the one hand, you can continue your design work, and on the other hand, lead your team for development. As the relationship between the two is getting closer, even if the design documents cannot be canceled, they will not need to be written too detailed. In particular, you can ignore those "products cannot be developed without them, the product is useless after it is developed. In addition, the high level of design personnel will also drive the developer's design consciousness in daily work, to achieve "design personnel while considering how to develop, while developing, developers can understand why such a design is like this.
For the architecture design work that really requires multiple people to meet each other, these design personnel need to work together (that is, 13 of 139 ). By the way, another question just asked: how should we plan human resources if the agile team is still expanding as a new project engineer? The answer is to prioritize the selection and recruitment of key personnel so that they can do the difficult work of Requirement Analysis/architecture design first (base on sprint0 and complete each Sprint ), later, it gradually absorbed junior personnel in the iteration, and those who have done game development must be familiar with this process.
Another related problem is: do not combine a bunch of new users into a development team to do low-level coding work alone. This person who is fond of playing ball games must know that if there is no expert in the team, the level of everyone will not be substantially improved because of the accumulation of work experience. On the contrary, he will introduce several experts to guide his work, it is the best strategy for the team to grow as soon as possible. This also supports the integration of design and coding teams.
Click to download the free agile development textbook: Martian agile development manual