Daily Retrospective?

A team can inspect and adapt its way-of-working at any time. Why would another formal opportunity to do so be of benefit?

I agree with Ian, there is no need for yet another meeting that takes the Dev team away from their daily work. I suppose you could include this into the Daily Scrum only if you have time available for it. I would not set this as a separate event. If your daily scrum only takes 10 minutes, use the remaining 5 minutes so people can call out things they noticed that could be improved. Otherwise, wait for the sprint retro and not force another meeting that impedes the team from reaching their goal.

I've found that newer teams often have trouble connecting the Retrospective with issues that may have occurred throughout the sprint, especially early on in the sprints. 

Curtis:  The meeting commitment wouldn't be too different if the daily replaced the single event Retro.  There are different purposes for the Daily Scrum and the Retrospective, so cutting the Daily Scrum for Retro items might not fit.    

If there are now retrospective tickets in the sprint, shortening the feedback loop for how the team is working together doesn't seem too abstract.     

Ian: With your logic, the team wouldn't need a Retro at all.      

I definitely was not suggesting to cut the Daily Scrum to fit in the Retro. I said if the Daily typically only takes 10 minutes of the 15 minute time box, use the last 5 minutes for Retro items. Any time the dev team is taken away from their tasks at hand it can spell disaster by not meeting the sprint goal and timeline. In some cases, where deadlines are not important, I guess adding another 10-15 minute meeting would be OK because the dev team is not under the gun, so to speak, to get the work done. Personally, I think as time goes on this would be a completely unnecessary meeting. Teams begin to grow accustomed to each other and learn how to work together so they may not have much if anything to call out for CI on a daily basis. 

Something that could be work is a weekly Retro as opposed to a daily retro. This would help for long sprints because people will forget important things that should be discussed in the Retro that happened on week 1 of a 4 week sprint. 

Ultimately, this is an area where it boils down to "what does the team want?" If the team thinks this would be helpful and useful, go for it and make the time for it. If they don't think it would be useful, don't do it.

> With your logic, the team wouldn’t need a Retro at all

Each event within a Sprint is a formal opportunity to inspect and adapt. It is a minimal prescription to ensure that critical things happen. A team is not obliged to wait for a prescribed event to make improvements. If team members inspect and adapt conscientiously on an ongoing basis, then they might require very little of the allowed event time-box.

If a team decides to add further prescribed events then that is of course up to them. Only they can decide if doing so is useful in their context. However such additions ought to be viewed critically, since they may limit informal collaborative opportunity and put change in delay.

Curtis:  Agile processes are sustainable, so a Development team should never be under any "gun."  I think you would agree, a team facing that problem is having a different one than the feedback loop length of Retrospectives.  I would also agree that a Daily Retro wouldn't be expected to be for the life of the team, all of our processes/practices are open to continuous improvement and the team should grow.  A weekly Retro would still be an experiment with a shortened feedback loop, which was the original intended purpose of my discussion post.

Ian:  I understand the theory.  The Scrum Framework itself is minimally prescriptive to allow it to be as effective as possible.  However, growing a team into a high performing Scrum Team is a journey that includes growing a team to understand self-organization.  I was more curious about experimenting with helping teams become better inspecting and adapting, not theory impacting theory.            

Any team member can call a Scrum for any reason at any time, including for the retrospection of process. The Daily Scrum is not necessarily the only Scrum. My advice would be for a team to inspect and adapt its way-of-working as soon as the need and opportunity arises. Team members ought to be trusted as professionals to call a Scrum as and when there is due cause, whatever that cause may be. Encouraging this standard of behavior is probably better than organizing additional events for a specific purpose, although teams are free to do so if they think it appropriate for their situation.

Brian,

Teams have deadlines and goals to meet don't they? Therefore, they are "under the gun". Sometimes it is more extreme and others not so much. Not all companies that use Scrum get so on board that deadlines are thrown out the door. 

Getting back to the main issue, if the team wants to daily, every other day, weekly, etc etc Retros; it's up to the team to fit those in to their schedules. I'm not against the practice by any means but for my team and in my current company, daily Retros would take away from the goal that we have and cause us not to meet the goal. Absolutely, inspect and adapt constantly but adding an extra meeting may do more harm for the team than good depending on the situation of the team.

Curtis:  I just don't agree with your premise.  Teams have deadlines & goals.  Development Teams should have equal buy-in to the product to deliver the most technical excellence business value possible. "Under the gun" makes it sounds like they are being forced into it by external forces.  If I encounter a team that feels this way, this is usually a source problem causing a lot of other symptoms in the environment.           

Brian,

With all due respect, you can disagree with me but my points are not invalid because my company is not the only company that continues to put deadlines on the development team without a care to what the team says. Is it the best or even a good practice? Of course not but in reality it is quite common, unfortunately.  

You're right that teams SHOULD have equal buy in for the development timeline, but many companies do not allow that. For the companies that are 100% on board with Scrum, this is not a problem and developers truly have the power to set the goals and deadlines. You may not agree but my point comes from a company that like many, are not 100% on board with Scrum and agile. This is also not uncommon. There are countless companies that are just getting on board with Scrum that are not ready to dive into the deep end and fully abandon everything they have done throughout their existence. I'm having to prove to my company that Scrum is beneficial but I have to fit into the confines set by upper management in order to win them over so they will start relinquishing control and give it to the developers. That means for the time being, my team will have hard deadlines that we don't have much a say in whether it can be met or not. Therefore, for teams that deal with similar situations like mine, adding another meeting may in fact be more detrimental than beneficial to the team. 

Curtis:  With same due respect,  I'm not attempting comment on the state of your company's environment.  I would love to but in a different post.  I think that is a pretty significant problem with Agile adoption at companies these days. 

I was hoping to discuss the idea of experimenting with replacing a single Retrospective event for a Daily Scrum style event for teams having trouble with self-organizing.  Honestly, in my short time on this forum, I'm beginning to feel this isn't actually the place to discuss Scrum.           

I fully understand your theory of doing that and I don't disagree. I just wanted to point out that from the perspective of a team that doesn't have the extra time in the day for that to happen; it may not work. It is fully a team by team basis as to whether it will work and/or be beneficial. 

As to using this forum for discussing Scrum, I actually learn a lot from this forum but the problem is some resolutions don't work for certain situations. My company, for instance, is not fully on board with scrum so during my time of working to get them to transition; there may steps that I have to take that don't fall within the Scrum Guide and Scrum Rules. On the flip side, we have to be mindful of the advice given that deviates from the Scrum guide because it could be taken out of context by a random reader and all of a sudden they are doing practices that are not allowed based on the advice of the forum. 

This is a great forum for Scrum discussion, just keep in mind that there will be differing opinions and I like to play the Devil's Advocate a lot because it makes people think deeper than just reading what the Scrum Guide says. Consider your question you posed, will it work? If your team thinks it will, absolutely. Does it fall within the Scrum Framework? It sure does. Will it work for all teams? No, but that doesn't mean it is a bad idea. I do apologize if I seemed rude at all during this and hope it didn't deter you from using this forum. Like I said, I just wanted to throw out a "yes, but..." point, you know what I mean?  

As to my company's situation, man it's crappy LOL. But They are slowly seeing the light, but it will be a long road before they fully adopt Scrum; but it won't stop me from trying to implement it where it makes sense. 

Has anyone found this useful for scaled scrum teams?

Scenario: Two (out of Four) scrum teams are unable to deliver not more than 15% of sprint commits even after Sprint # 6 for Team 1 and Sprint # 12 for Team 2 even though they had few Hardening Sprints in between. Now, the EAT decides to form a 'core' team from four scum teams, then scraps Daily Stand-Ups to introduce Daily Retro with the core teams (so 85% of the Devs can spend 100% of their workday coding). 

Specifically, I wanted to know if this is a tried and tested approach for teams who are relatively new to Agile and have been sort of "relaxing" with 4 weeks sprints since Q2, 2020.

P.S. There was only one scrum team Q2 through Q4, 2020 where the team used to work together on two separate modules.

Two (out of Four) scrum teams are unable to deliver not more than 15% of sprint commits 

What do the teams actually commit to, and who decides this supposed commitment? How does the Product Owner determine whether or not value is being delivered?

even after Sprint # 6 for Team 1 and Sprint # 12 for Team 2 even though they had few Hardening Sprints in between

Perhaps if there was a commitment to a Definition of Done, so-called "Hardening Sprints" would not be needed at all, and empirical process control would be better established. What are your thoughts about that?

Now, the EAT decides to form a 'core' team from four scum teams, then scraps Daily Stand-Ups to introduce Daily Retro with the core teams (so 85% of the Devs can spend 100% of their workday coding). 

The people doing the work are disenfranchised from the ability to inspect and adapt. What do you think that says about the application of the Scrum Values?