Agile Leaders Interviews: Kerry Bayles of SolutionStream

Kerry Bayles became converted to Agile the moment he discovered it 3 years ago.  Since then he has helped empower teams at Deseret Digital Media, Deseret News, and currently works as a Scrum Master for Solution Stream in Lehi, Utah.

What have been the most unexpected changes you've encountered in your software development process and/or team post-COVID?

The fact that people don't turn their cameras on.  I kind of assumed that would be a given since we were only ever going to see each other on video calls anyway, but it turns out most people still prefer to have them off.  It makes it a lot harder to connect as a team and for me as a scrum master to gauge how people are doing. It also makes it impossible to know whether people are engaged during a meeting or off doing something else on their computer.

What have you learned from a full year of all (or mostly) remote development?

Retros can work remotely!  I would have argued against that possibility prior to Covid-19, but now I saw that they can still be very effective.  I will never enjoy them as much as in-person retros, but teams can still gain a lot from retrospectives, even over Zoom.

What's one lesson that you want to apply (or thing that you want to do differently) in the coming year?

Find more ways for my team to spend time together online that are not work-related.  Also, encourage more pair-programming and swarm sessions.

Any other lessons you must also apply?

Having 1 on 1s with team members is more important than ever.  Also, take advantage of the fact that people are interrupting each other less throughout the day by making sure there are blocks of time for programming in your team's schedule.  We just have all our meetings in the morning and leave the afternoon open for development.

There's a lot of talk about creating a blameless engineering culture. Do you agree with this as a goal? How is this currently supported in your organization?

I haven't heard about this.  I'll have to look into blameless engineering culture.

Retrospectives tend to be fairly qualitative. Would quantitative data contribute to sprint retros? If so, what would you want access to – and how could it assist?

I think sprint retrospectives need both qualitative and quantitative data. Some of the best data we have used is comparing the percentage of completed work that was related to the sprint goal to the percentage of other work (sprint busters, customer support, etc.).

‍