Agile Debate: Self - organizing or self - destructive team

There is a fundamental agile principle that is at stake and that is TRUST.

Agile has grown into the mainstream software development and project management methodology, how to build a highly effective team also become the hot debate in professional agile community, is it possible that your self-organizing Agile team turns to be self-destructive, and what's the mechanism you can think of to put a check around such Agile pitfalls?

There is a fundamental agile principle that is at stake and that is TRUST. Something is happening within the organization that prevents the team from trusting the business and communicating openly about what they feel should be the appropriate course of action. For whatever reason the team decided, there was a significant technical risk that needed to be addressed by the sizable changes, but the team did not feel comfortable communicating on time. Most likely the team took the approach of asking for forgiveness, rather than permission. This is a classic Trust Anti-Pattern. So first check - Why the team did not discuss/communicate the change (improvement plan) with product owner / business stake holders etc? (find the root cause),  is it because of the "ignorance" of the team (about the real impact of the changes - especially on other modules / applications or how to "manage" changes : "externally triggered" or "internally triggered" etc.) - If so, basic solution would be to provide appropriate "Training" / "Coaching" to the team

A team can become "self organized" only when the team "understand" what, when, how, & why they should do what they are supposed to do. As we cannot go back to the past, what best can be done (by the team, product owner, and all associated stake holders) is to see how such scenarios can be avoided in future (learning from mistakes & not blaming and regretting for what already happened - which might only worsen the situation) making everyone aware of the basic "philosophy" and "value" of becoming "agile".

Self-Organizing means the team has latitude to determine the 'HOW' of implementation. Self-organizing team might become "destructive" when the development teams have misunderstood the power granted by the authority of self-organization and applied it without considering the consequences or the input of the Product Owner and stakeholders who would be affected by their decisions. The team seems to have taken additional latitude in determining WHAT they would deliver..."additional scope" as well as what other teams needed to deliver...However, normal inspect-and-adapt principles should ensure such misconceptions are addressed, otherwise, it would cause the real (long term) concern if the team did not learn from the experience and persisted with this behavior.

The team wasn't being very Agile, given this outcome. Every iteration is another opportunity for testing approaches, such as ones that might not have severe architectural ramifications. Every iteration is an opportunity to get outside technical feedback, from people like architects who might know how to avoid these situations. Every iteration is an opportunity to tell the business what you're doing, not just in the context of the demo (showing what you've done), but also future work (sprint and release planning, in which customers can certainly be involved). The team might not put adequate feedback loops in place. If they had, then the problem would have been noticed before they had gone very far down to  the 'unexpected' path, and people could have communicated their concerns and arrived at a "Go/No-Go" decision. 

Certain 'brands' of agility will give you common solutions at the outset; others will let people find out for themselves. Certainly communication and leadership are parts of the problem. However fundamentally the problem was something the team didn't know they didn't know, and that is inherent in development work. For the "unknown unknowns", usually the best solution is to try something out and see what happens. Here you had "unknown unknowns" that didn't come to the surface until integration. The team didn't know that they should integrate sooner to discover these things sooner. Well, you all learned this at some point (unless you still haven't learned), so possibly this is a case of the team being "left out in the wild". 
Good leadership will never cease to be important; good communication even impact more. Being truly agile means to well understand the basic philosophy – iterative communication, cross-team interaction and incremental improvement, self-organizing team has better discipline to understand WHY and know HOW, always navigate through the agile journey with well planning and communication, and deliver value with priority and consistency.