There are many pitfalls in agile transformation. Have you jumped today?
1. Can I choose between Agile and Waterfall? X
1. It is possible to combine agile development and waterfall development. For example, when there is a new project idea, we can use agile methods to quickly trial and error, quickly obtain market feedback, and output that meets customer and market needs However, if the subsequent market and demand are relatively stable, we can completely return to the waterfall development model.
2. On the other hand, if an organization’s original model is waterfall development, and now it is to be transformed into an agile model, there must be a transition period. This transformation process is by no means "one size fits all", and there will be a long period of time to adopt hybrid mode!
2. Agile project is enough (apply for resources if there is a project, and return to the resource pool when it ends); ×
This is a very improper practice. This model hopes to achieve project agility, rather than organization agility. Ideally, the project can be managed using agile methods. When the project is over, return to the functional team, so whenever there is a new project There must be a running- in period, and the role of the project must be re-determined, and the functional organization cannot effectively support it. As a result, the organization will always stay in the original mode, and the project agile will eventually become pseudo-agile.
3. TDD and ATDD are the practice of the test team; ×
Regardless of whether TDD or ATDD is the practice of the team as a whole, TDD blurs the boundaries between testing and development, and ATDD blurs the boundaries between requirements and testing; so in the final analysis, it is the practice of cooperation between various roles, rather than testing their own changes;
4. Value-driven; ×
Value-driven is actually not wrong. This is exactly the delivery principle advocated by Agile, but is there only value-driven? If all situations only consider value, it will bring a lot of problems, high value risk is low, low value risk is high In such a situation, must the value be high first? It seems not necessarily, so in the final analysis, the priority of demand is affected by multiple factors such as value, risk, market window, cost, etc. The value-driven is correct but not all. Don't be biased by "value" just by shouting slogans!
5. We have SA and BA, they are responsible for the work of PO; ×
There is no problem at all when the existing role is transformed into a product owner, but if one more role is added in the middle, many problems will be introduced. For example, if SA is used as a bridge between the PO and the R&D team, this fake PO (SA) becomes responsible. Unauthorized product owner, the real product owner does not work with R&D; therefore, what SA can do is to pass the microphone, which can neither replace PO decision-making nor give the team the necessary guidance, while the real product owner only Will say: "Welcome to adopt the agile development model, you can definitely become more efficient, let me participate? This may be difficult, let SA replace me!", crying!
6. The quality manager formulates DOD standards; ×
If your team is set by the quality manager to set the DOD standard and require each team to follow and execute it, then you are not agile enough. The DOD should be formulated by the team, which is the result of the negotiation of the various roles within the team. The quality manager may be experienced. But it can never represent the self-management willingness of the team, and we expect that each work handover node should have a clear DOD standard!
7. The agile coach is the liaison of the team! X
An agile coach can never become a contact person or representative of the team. Communication should be the team’s own business; coordination and promotion of coordination are different; what an agile coach should do is to promote communication and coordination. If the team is completely dependent on the agile coach for communication, The communication ability of the team will degrade. For example, it is an obvious mistake to participate in the SOS meeting by the scrum master on behalf of the team! Let me say one more thing here, SOS meetings should not repeat the team stand-up issues, but should focus on issues that affect the inter-team relationship, such as: what features we have done recently will affect other teams, we What functions are planned to affect other teams. Are there any problems that need the cooperation of each team to solve?
8. Team speed competition! X
We know that Agile recommends scale estimation, so we will use story points for estimation, but the selection criteria of story points for each team is not relevant and naturally not comparable, so if your team engages in a high rate of team iteration Competition, not only is it worthless, but also hurts the hearts of some teams!
9. Continuous integration is to use the best tool! X
持续集成绝不是工具而是实践，而且非常核心的一点是需要研发人员改变工作习惯；所以如果你的团队花了很多钱上了好用的工具，但是却做不到短周期的集成，那工具就没有发挥价值，并且持续集成还有很多方面需要关注，比如：快速修复问题（安灯拉绳）、小批量变更、每日集成、自动化测试的支持、可视化管理；以上内容都不是工具层面的问题，而是团队策略、流程改进的关注点！
10、外来的和尚会念经！×
首先，我们承认外部教练的价值，但是如果一味的信奉外部教练能够帮我们解决所有问题，恐怕最后的结果会让你大失所望，外部教练应该是与内部教练相辅相成的 如果外部教练只帮助你推动实践和工具的落地，而不注重内部教练的培养，那您可能上当了！
