Discouraging solutioning of user stories during Agile PI planning ceremony

Question

I work as a technical lead / team lead in the IT security team at my workplace. We currently use the SAFe Scaled Agile methodology of organizing our features and user stories.

During the most recent program increment planning event last week, team members on our team were trying to solution / design the work for user stories when it is my understanding that the PI event should focus on the business objectives from product owner and the "what" of the upcoming sprints, not the how of technical implementation.I felt that while technical discussion of how to implement is valuable, such ideas detract from planning of the bigger iteration roadmap.

The whole of the IT security team us about 70 folks, divided into several units, e.g: AppSec,controls and compliance, security architecture etc. We have a product owner and scum master. However, our scrum master is not the most assertive team member which somewhat hinders us, as usually maintaining team discipline and prioritzation is usually their responsibility in an Agile work culture.

To give some examples of solutioning that team members started to discuss that I feel is distracting during planning ceremony:

How to actually pen test an application and the viable attack vectors to attack with, rather than when or agreeing on the rules of engagement first with asset owners

Actual brainstorming of test cases to verify a vulnerability has been remediated, rather than the bigger strategy of how to approach such testing itself

• How do you discourage in the moment solutioning during Agile PI events without team members feeling shut out as if their ideas dont matter? If I raise this point, I want to appear supportive of all on the team.

• As I am neither the product owner nor scrum master , is it appropriate for me to raise this issue at all, i.e: Inefficient use of time and possible misunderstanding of the objectives of Agile PI planning?

Answer 1

We also use SAFe. While I agree these sorts of conversations can feel less than productive in PI planning, agile is not supposed to be about keeping strictly to a script. People are getting value from those conversations, or they wouldn't be having them. A certain amount of detail has to be discussed in order to know if you've broken down features enough, or if it fits in a PI, or if there's something you need to do first, or a risk that needs to be addressed, or another team you need to bring in.

A lot of people also plan better "bottom up." They need to brainstorm some actual test cases in order to determine a larger strategy. As they brainstorm, the larger patterns become more apparent.

Sometimes, people need to get the details "out of their head" in order to focus on a larger picture. You'll have a hard time getting them to focus if you don't let them offload mentally a bit.

Often, some or all of the team members are not familiar with the item you are trying to plan, so you need to go into some detail in order for the entire team to fully participate.

It's also comparatively fun to brainstorm solutions, and in the context of a long boring planning meeting, you need some fun.

The trick is to not try to eliminate out-of-scope conversation altogether, but to cut it off before it consumes too much time but after its purpose has been served. At that point, you can just say something like, "I think we've gone into enough detail to plan this." Sometimes someone will respond a reason why they think further conversation is needed, and you can address that as a team.

Answer 2

How do you discourage in the moment solutioning during Agile PI events without team members feeling shut out as if their ideas dont matter?

Politely and professionally. Also, with an alternative proposal or solution to the one given.

Avoid phrasing it like "This approach is wrong because...". Instead, phrase it more like "What you say is an option. However, I think that we should do ... instead, because ...".

This way you are acknowledging their effort and proposal, but also giving yours (and one that perhaps is better).

As I am neither the product owner nor scrum master , is it appropriate for me to raise this issue at all, i.e: Inefficient use of time and possible misunderstanding of Agile PI planning?

I think it is ok, yes. This is a project that's done as a team, and you are part of that team. Thus, it is of your interest that resources are used properly and that the result is good.

As long as you do it politely, respectfully, and in a timely manner, you can hardly come out as inappropriate.

Answer 3

In a meeting that is usually here for a given purpose, it's completely possible for any participant to remind others they are not here to discuss something else than the meeting purpose. You don't need any more credibility than being in the meeting yourself and your role or responsibility doesn't matter.

There are numerous reasons things are more difficult in reality than it could be in theory, though; people usually come in meetings with expectations their time will be well spent on learning something new and useful, which is not always guaranteed with rituals. They could already know the business objectives by other means, or find it irrelevant to their work, which could be the reason why they would "fill" the meeting with something they would do find more purposeful. Or they could be unaware of the meeting purpose and think their discussions are related.

I would try the following:

• Politely ask if the meeting participants can discuss a given point after the meeting if it's unrelated to the Agile PI event. We regularly schedule similar ad-hoc meetings when we realize something is worth discussing, but not worth all the participants time right now

• Time-box the meeting and try to give it rhythm. This something you can suggest to the Scrum Master, or whoever is responsible for the meeting. When a discussion is quick and time boxed, it is less tempting to digress, and digressions are less lengthy.

Some other meta reflections on the purpose and right frequency of the meeting could be fruitful as well; perhaps the team is updated too frequently to find the update purposeful. Perhaps you would have a technical mean to broadcast business objectives information another way without any meeting, or prior to the meeting, to make communication more focused and efficient.

In any way there is no silver bullet to the problem of digressions in meetings, but is not something to be ashamed to point out as a problem, as being part of an agile process is all about reflecting on improvements and process changes.

Answer 4

In general, here's what I have found ...

During any meeting where the objective is to determine "what to do," you're always going to encounter folks who immediately jump to "a solution." And, on the one hand, "that's to be expected, because 'that's what they do.'"

But on the other hand: You should quickly try to (ask them to ...) assess whether "what they are now saying" is relevant to the definition of what the meeting is right-now talking about. If the answer is "no," then the discussion should be deferred. But, if the answer is "yes," probably you should have another meeting tomorrow. "Table" the issue for further exploration, then move the meeting on to the next agenda item.

"Yes, the raised issue appears to be important. But we don't have to decide it right now. Instead, the raised issue tells us that we need to explore it further, instead of trying to decide it today."