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.
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.
0 comments:
Post a Comment