Process discussion and / or improvements

Interesting question. My initial thought is that these types of conversations and improvement exercises may detract from the sprint goal (team capacity).

That said, I would still promote having such conversations during the retrospective, as then any improvement initiatives can be tried out for a full sprint and then evaluated. It would not be good if a mid-sprint improvement initiative actually made things worse.

Unless it is a significant constraint or issue, I would not want the team to focus on the process. It is ok for the sprint to not function at 100% efficiency - that is what the retrospective and feedback loop are for.

I'd also be unsure how to gauge the success of any improvement experiment based on metrics or observations from a portion of a sprint only.

Improvements can be made at ANY time. The retro is the main formal event for improvement/inspect/adapt of the people and processes, but these improvements can happen at any time. Improvements, inspect and adapt can also occur during any other Scrum Event, and even outside of Scrum events.

> Can process related discussion and / or
> improvements happen during the sprint or the
> process can only be inspected and adapted
> during retrospective meeting ?

If it is clear that the process isn't working out and that the Sprint Goal is at risk, then it should be improved immediately. Waste and risk should not be allowed to accumulate or to be compounded.

The Retrospective is a formal opportunity for improvements to occur no later than the Sprint boundary.

Hi Abhinav,

I'd like to quote the Agile Manifesto:
"Individuals and interactions over processes and tools"

So, if process improvements serve individuals or interactions it would be nonsense to wait for the formal process opportunity to implement them. If (and only if of course) they don't
* endanger the Sprint Goal
* contradict the other agile values.

(my opinion)

Best regards,
Anke.

I still maintain that unless the sprint goal is endangered, I would be [I]very[/I] reluctant to introduce any variability into the current sprint that might jeopardize the current sprint.

You simply cannot know beforehand whether a change or improvement experiment will have a positive effect. Why would you knowingly and willingly introduce risk into the middle of your sprint?

> Why would you knowingly and willingly
> introduce risk into the middle of your sprint?

Why would you knowingly and willingly accept a greater risk? Introducing a process adaptation mid-sprint will of course incur risk, and it will very likely reduce velocity. However risks are not uniform and a team should be able to assess their likely impact.

Changing the way peer reviewers are selected could be one example of a reasonable mid-sprint adjustment. Changing the review process they follow might not be.

Introducing a process adaptation mid-sprint will of course incur risk, and it will very likely reduce velocity. However risks are not uniform and a team should be able to assess their likely impact.

Agreed. It is of course my own filter that is reluctant to introduce process change in the middle of a sprint, but ultimately it is the team's decision on what they feel works best for them.

However, I do believe I would not be effective in my role as SM if I did not communicate the potential risks and impacts of such decisions. It would certainly make for an interesting discussion during the retrospective - not only the effect of the change on the team and the sprint, but also the effectiveness of mid-sprint process changes.