Escalation level

I'm not quite sure what do you mean of escalation on your question, but as I understand it, you're problem is more on team relationships, e.g. not trusting each other due to multiple reasons such as culture and behavior.

Team member differences can be discuss during sprint retrospective, I'm not sure if such thing needs to go all the way to the stakeholders.

It's also a good practice to have a "working agreement" properly defined and pasted on your boards to remind everyone on how to be a better team.

> I am trying to understand best escalation mechanism in agile...

In agile practice, any corrective action should be taken as close as possible to the time and place of inspection. This is in order to reduce waste.

On that basis, what do you think the "best agile escalation mechanism" ought to be?

reporting issues as soon its found is important.
But overdoing also can kill its importance.
I don't think there is any tool or proven mechanism yet in Agile.
Something like Risk Management.

Hi Samridh,

Agile product development is about people, collaboration and self-organisation, working with the customer and trying to get out product often and in small, high quality bits that work. So when we discover 'issues' we prioritise them in terms of expected value, with a view to getting maximum value out of development work.

So you are right, there is no such thing as the 'Agile escalation mechanism'. Where I work now we have several systems to help us understand the importance and urgency of issues. Our POs value bugs with a label - show stopper, critical, non-critical and unimportant. New issues are discussed with the customers or stakeholders and assigned a 'business value by the PO'. I have also had business stakeholders that liked to play 'value poker' - a kind of story point poker but for value as the stakeholders perceive it.

None of these are necessarily Agile, except the principle that we want as little time and distance as possible between the discovery of an issue and its solution - adjusted for value. If you are more concrete about you problem, perhaps we can be more concrete in our answers.

Hi Dennis,
issue is more towards reporting issue to different stake holders not necessarily PO's.
We do present weekly report to Director and even VP level.
This is a double edged sword i.e. whether we should report critical issues before weekly update or as soon its found.
There is no mechanism to tell us whether it should be reported or what action to be taken.
Sole discretion is with PO's to label issues and owner and putting us in tight spot in front of others.

Samridh,

Assuming that your team is not working in 1-week sprint increments, why is your team constructing a weekly report to executive-level staff? Is this "status" information something that can be communicated by your PO?

Any team interaction with "stakeholders" should occur only on two separate occasions, and stakeholder presence is optional at these times: when the team and PO are grooming a story, and when the team presents the solution for a story.

There really is no need for the team to coordinate "issue" communication with anyone else except the Product Owner. The Product Owner must represent the interests of the business and all relevant stakeholders, and communicate with those entities as needed. If this is not happening, then that is an impediment to proper Scrum that must be made visible to the organization, so that either changes can be made, or they are informed as to the risks and negative aspects of that practice.