Agile: How to deal with bottle neck approvals outside of SCRUM?

Question

Is there an Agile term for when there is a stakeholder that acts as a bottleneck by jumping in only occasionally to trump decisions made collectively by the team? (ie, upper management who never partake in the process, but will occasionally review work and decide they don't like it)? I'm familiar with Pig and Chickens. Would this simply be a 'type of chicken'?

Is there any Agile technique to deal with said type of person? Is there a particular role on the Agile team that should be in charge of managing this type of issue?

An example might be that the product owner is happy, IT is happy, UX is happy, various business roles are happy, and sprints are underway, but suddenly someone's boss's boss has decided they want everything put into a PPT deck for them to 'approve' where we're at.

Answer 1

This is the Product Owner's job.

The whole point of the product owner is to act as the point of contact between all the stakeholders (including people like someone's boss's boss) and the team itself. In theory, the rest of the team should only ever have to deal with the Product Owner. The Product Owner goes and does all the work of talking to various stakeholders, puts together the stories, and then the team just works on them in order of the set priority, and ignores who requested what. (In practice, it never quite works this way, but close enough.)

However, it is also important to remember what a stakeholder is. A stakeholder is the person who writes the checks. The team gets a list of business requirements, and then fulfills them. Sometimes you get stakeholders who either want something stupid, or who change their mind over and over. That is, unfortunately, their prerogative, after all, the whole point of agile is to let stakeholders change their minds often and to catch stupid decisions faster. Ideally, it is mostly the Product Owner that deals with the stress of all that while the team just takes the stories as they come. Really, the whole point of agile is for stakeholders to determine they don't like something and actually want something different.

Now this is all business requirements. If this boss's boss is mucking about with technical decisions, then, well, you have my sympathy. There is no real Agile term for this other than "not agile". In Agile, the team makes technical decisions, not the stakeholders.

TL;DR - If a stakeholder is overturning business decisions, then this is their prerogative, and it is the Product Owner job to deal with that. If the stakeholder is overturning technical decisions, or overturning any decision mid-sprint, then this is something the Product Owner and Scrum Master should be demanding stop.

Answer 2

More examples of interruptions will be helpful to understand the reasoning why your skip manager or another stakeholder requires "stop everything and do this" type of work.

For "put a PPT together to approve", could this be the lack of transparency up?

Does your team invite all the stakeholders to attend the demos showing the status/progress of sprint's deliverables?

What's the outcome of your planning sessions? Is it something that only your team owns? Do you communicate the stories and priorities you've agreed on to your top management (Is this information easily accessible/discoverable?)

I do agree with Steven, if the mid-sprint change is driven by a business need or is the result of a micro-management are two different cases.

When business requires changing the direction - that's the whole reason you do agile then. If that's the case and you think it happens quite often, consider shortening your iterations or going full-blown Kanban instead?

If that's a micromanagement issue, protect your team, communicate the ground rules to your management - once the planning is done, no new work can be injected into sprint - it will have to wait until the next sprint. Usually, if the iterations are short - a week long - hardly anyone objects waiting a week max if they have a request. Back it up with data - showing how velocity suffers when sprints are interrupted, explaining how context switching is wasteful, etc.