110 likes
·
934 reads
16 comments
It sounds like an interesting approach, however, I have to disagree on your point for tracking with Jira. In the world of Agile, these metrics are intended purely to predict time needed to develop future tasks/stories, mainly because companies like predictable, they feel better knowing that once they have these metrics promises to clients can be made and kept(at least most of the time).
I am curious, how would you handle the workload problem, where QAs are waiting for Devs to finish a certain functionality in order to get "unblocked". This is always a tricky balance to keep in my view. And if devs are focusing on helping others, surely, there will be delays in the development process. Another thing to mention is that a lot of people feel uncomfortable asking for help, and motivating people to communicate more and ask for assistance is another challenge on its own, it will be interesting to hear/read your opinion on this topic as well.
And last.. is this an official framework like Scrum or is it something internal that you came up with in your company? What steps did you take to reach to this "framework" and what challenges did you face when going through this process change?
Thanks for the article!
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!
Great read. It definitely helps if team members can help each other out by reviewing PRs. It takes a lot of load from the EM. Do you currently practise this in your company? Would you say it was a success?
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 :)
Great read. You dropped some truth bombs here 😅. I'll try to take lesson from this and work better.
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 :)
Exellent 👍
Thank you, Alex! Appreciate the kind words.
I agree with many of the points made in this article. It's a shame that it seems so hard for the concept of true teamwork to be accepted in the workplace. I have only experienced one working environment that I can truly say was successful in this respect in my 15 year plus career. I will admit though the transition to a different way of working was met with a lot of resistance at first (including from me) but in the end we achieved and surpassed our goals. Some of the key phrases we used were "stop starting and start finishing", "slow down to speed up" etc. Now I have a new one "working right to left!". Great article.
Hey Stuart. Thanks for sharing your experience! I agree that it can be really tough to find an environment that allows these kinds of ideas to flourish. I like the other key phrases you brought up. I'll be sure to keep those variations in mind :)
Love this . Thanks for sharing
Thanks for taking the time to read it :)
Nicely explained.
As a team we need to understand that in a sprint we deliver a set of stories as a team which is Devs + QAs.
Also, I don't recall if any team gives away Man/Woman of the Sprint award for an exceptional individual performance in a sprint.
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!
I really love this. My former manager at Botany was one of the first people to introduce this concept to me of taking a little break between tickets to learn and do code reviews. This blog post was a great reminder.
That's awesome to hear, Rizel! It's such a great way to split up the day and get some variety in your daily work.