Waiting for Retro to Make Process Changes

The retrospective is a formal opportunity to ensure the team is taking the time to inspect and adapt their process, however, this does not mean the team must only do it at that time. 

Would addressing the process improvements Mid-Sprint aid in the achievement of the Sprint Goal?

It may be beneficial to acknowledge that there's something that needs fixed and then determine the appropriate timing to address it further. 

As a Scrum Master, sometimes it's hard to watch large problems not be addressed until the Retro when Sprint lengths are longer at three or four weeks.

Do the "large problems" you refer to put the Sprint Goal at risk?

There's nothing that precludes the team from making process changes at any point in time. However, I would want to understand the risk to the Sprint Goal. What is the risk of not making a process change? What is the risk of making the process change? Any change has some chance to possibly be detrimental to the team and put the goals at risk, since the team planned for and began executing against one process. Personally, I'd try to avoid changes mid-Sprint unless there were very good reasons to make the changes.

I really appreciate your heart in this matter because it seems to me that your goal is to protect the team and make sure they can focus on the sprint. With that said, what if the big problem were not a process issue but an interpersonal issue. Say a dev and tester were at odds and it was so bad that it was causing morale issue with the team overall. Would you wait for the Retro to address or would you try to address it before the retro? Same kind of concept with the process issues. If it is causing problems, talk about it, it's worth investing the time into. If it's a minor inconvenience, I'd wait for the retro.

Thanks for the advice everyone.  The issues I am seeing definitely put the Sprint Goal at risk.  Sticking to facts, in this team's first three-week Sprint, zero stories were completed to the DOD, even though the story point estimates averaged only three days!  I have identified a few issues so far - there are likely more - but unless we can start *somewhere* with improvements to process and transparency, we won't be able to dig much deeper.  The team is really resistant/sensitive to any change and was using Kanban before.

even though the story point estimates averaged only three days

Are the estimates converted to hours/Days ? 

The issues I am seeing definitely put the Sprint Goal at risk.  Sticking to facts, in this team's first three-week Sprint, zero stories were completed to the DOD,

Do you think these stories were well planned and refined before ? What do you think is taking more efforts to complete these stories ? 

The team is really resistant/sensitive to any change and was using Kanban before.

What was it that made them switch to Scrum? 

The issues I am seeing definitely put the Sprint Goal at risk.  Sticking to facts, in this team's first three-week Sprint, zero stories were completed to the DOD,

If Scrum is the framework to adhere to, then the focus must be on the Sprint Goal.

Granted, completing zero stories likely means that the Sprint Goal was also missed, but story completion should always be secondary to Sprint Goal completion.

Tony - the main motivation in moving to Scrum was to add estimation to be able to get a velocity for forecasting.  Those were the main reasons but I think added benefits are that (a) we now have more planning (sprint goals) where before there was none and (b) we can work to consistently prioritize by value instead of shifting focus all the time.

Timothy - I understand what you are saying and it was good to point out that there may have been a deeper root cause.  That wasn't the case in this case though, our Sprint Goal was valid, relevant, and achievable.

the main motivation in moving to Scrum was to add estimation to be able to get a velocity for forecasting.  

Kanban : a strategy for optimizing the flow of value through a process that uses a visual, WIP limit pull system.

Scrum - A framework within which people can address complex adaptive problems, while productively and creatively delivering products (increments) of the highest possible value in small iterations. 

Now, lets say if your team does not do the estimation and velocity calculation , does the outcome will still be Scrum ? Or will you need the Scrum ? 

Tony - the main motivation in moving to Scrum was to add estimation to be able to get a velocity for forecasting.  Those were the main reasons but I think added benefits are that (a) we now have more planning (sprint goals) where before there was none and (b) we can work to consistently prioritize by value instead of shifting focus all the time.

I'm not saying don't do Scrum but I believe the team could achieve all three of those points using Kanban if they wanted to. The team could develop flow metrics for forecasting, create shared goals that could span the course of several weeks, and work with the Product Owner to ensure the top valued items are at the top of the backlog for them to pull in when they finish work. 

Everyone experiences change differently and at different paces. Do you feel the team overall has the desire to put in the effort to transition from Kanban to the Scrum Framework? I'm curious to hear how they move forward as a result of a tough Sprint like that. 

in this case though, our Sprint Goal was valid, relevant, and achievable.

Katherine, was the Sprint Goal relevant to more than 1 item forecast by the team for the sprint, and did the team as a whole work on the Sprint Goal?

To echo some of what Tony said, there are a number of strategies to promote more certainty around delivery (estimation, forecasting) that do not involve Scrum.   In my opinion, one should look to Scrum if the desire is around promoting the 5 Scrum values(Focus, Openness, Respect, Courage, Commitment) and working Agile-ly (quick feedback loops).

Yes to the first question.  Not so much for the second - the team is still very focused on their individual tasks at this point.  I hope to have the opportunity to help them align to more of a team mentality over time.

the team is still very focused on their individual tasks at this point.  I hope to have the opportunity to help them align to more of a team mentality over time.

Katherine, one tactic you may want to try is to ask the team what their strategy is for moving work forward if for some reason the individual working on an item (in a silo) becomes unavailable for some reason (i.e. - illness, personal reason).

By placing the focus on the work (business value), and away from the "busy-ness" of each individual, you can help craft a conversation around mitigating such single point-of-failures and bottlenecks that promote a very fragile process for getting things done.

Be advised - team members may have a deer-in-headlights reaction when presented with such a question.   That isn't necessarily a bad thing.

Good luck!