Agreed. Retro would be a great place to give kudos to individuals that really went above and beyond or to the whole team in general! If you can highlight at least one thing each person did well, that will help boost morale!

Thanks for taking the time to read it :)

Thank you, Alex! Appreciate the kind words.

Thanks for the comment, Mohd! Hopefully, this post didn't come off as too critical of the way most people work. There's nothing necessarily wrong with working "left to right" and it all varies from team to team. Don't be afraid to try new ways of working and do what's best for you and your team at the end of the day :)

Appreciate the comment, Sandeep! Totally agree that a team that works together, succeeds together. We definitely follow this practice at DraftKings on my team (though I can't say for sure with every team).

My manager is great and encourages this type of collaboration between us. He's enabled us with slack threads for things like code reviews for maximum visibility.

I would call it a success :)

Hey Stoyan. Thanks for the comment. Really appreciate it!

I think you're absolutely right that Jira is an incredibly priceless tool when it comes to ensuring accurate forecasting of work. Unfortunately, in some companies, these kinds of metrics can be used to create a bit of a competitive and toxic landscape for developers through internal stack ranking by upper management. As long as they aren't used as such, they are totally acceptable in my mind.

I'm incredibly thankful that I haven't had to go through that at DraftKings or previous employers, but I've heard horror stories from friends at other companies.

You bring up a great point about the funnel of work for QA teams being blocked downstream by this process. We only recently started working with a QA team at DraftKings for our front end so I can't say for sure if we have this problem.

Perhaps the best way to solve this problem would be to make sure the QA team is not dedicated to a single team, but instead acts as a resource for a minimum of two teams? That would likely create a more consistent stream of work flowing in (especially if the sprints start at different periods between the two dev teams). I'm pretty sure our QA team is set up this way.

I will admit that my team is relatively social and we all get along so that helps us with our consistent communication. Even then, it's not something that is perfect and with time it should get better.

I think the key here is to ensure that the team feels that they have a judgment-free zone to be able to share their opinions. A developer will forget when they are praised 100 times, but they'll for sure remember the one time they were embarrassed for sharing their thoughts with the team. They need to trust one another.

Encourage those who may not speak as much to share their opinions because they are valuable to the team and praise them for when they do speak up (bringing specific examples to them is best).

I would do this in private though and let the improvement occur naturally. Folks who are more introverted, may not appreciate being singled out in a meeting. Persistent instances like "I haven't heard Eric say anything yet" are more likely to make someone shut up than to speak up.

To be honest, I'm not sure if this is a special form of Agile or Scrum at all. I think it's more of a productivity/efficiency hack. At DraftKings, I kind of stepped into the team with this already established to some degree, though my manager did slowly introduce little changes here and there (like slack threads for daily code review I mentioned above and encouraging the team to post publicly when a ticket moved to code review, QA, etc.). The biggest challenge with this seems to be consistency. At first, we mostly forgot (and still sometimes do) to communicate when a task has transitioned to a new swim lane that required action from the team.

I had also tried to establish this mindset of working at my last company where I was a tech lead for the team, but I would say it was less of a success. Not because the process is bad, but it just ended up not working for the team. That team, in particular, was very junior in terms of experience and there were issues with micromanagement because of that. The trust needed just wasn't there. It definitely helps to make sure your team has a wide variety of experience (with enough senior developers to support junior developers).

Let me know if you decide to try this out in your company at all and how it goes! Hope this helped to answer some of your questions and thanks again for the comment!