Webinar recap: virtualized agile

Work smarter, better, and faster with weekly tips and how-tos.

A big thank you to Mike Hansen and Mark Kilby at Sonatype for hosting our first customer webinar. They shared the Sonatype story and how the team tackles agile development on a daily basis with a completely distributed team. Our customers are what make Atlassian awesome, and we love hearing their success stories.

Here’s a link to watch the webinar again and share with your team. Keep reading for the top 10 questions and answers. Enjoy!

Mike & Mark’s Q&A Top Ten:

Q1: You mentioned that product managers are not responsible for the management of the project resources. Who is responsible for managing the sprint objectives and the resources?

A1: There is a collaboration between product management, the product owner, and the sprint teams. The team is responsible for organizing to get the sprint objectives they’ve committed to complete within the sprint. (We do not have project-based work.) We have a number of product-specific workflows which have a general static team assigned. Product management decides priorities, and the development team estimates size and commits to what can be delivered. As the nature of overall work changes (e.g. strategic investment priorities are changed), resource allocation changes. This is handled by overall engineering management with help from many people across engineering to maintain an effective balance of disciplines overall.

Q2: What resources did you utilize when integrating the agile process into your organization?

A2: We leveraged a few experienced individuals to help get the process in place. We arguably had elements of agile already, though we’ve certainly become more disciplined the past few years. Having strong agile coaching expertise contributing to such an initiative is definitely going to better ensure success.

Q3: Do you have dedicated QA for each team or are they shared resources?

A3: We have extensive automated testing (unit, functional, integration), primarily driven by the developers. We have very limited dedicated QA, though generally that is focused on driving the overall quality discipline working with developers in crafting effective tests.

Q4: What “variations” to scrum & agile do you have due to your distributed nature?

A4: We continue to iterate on what we have and so things have evolved over a period of years. That said, we do have a basic scrum framework, based on two week sprints, with routine backlog management and grooming and classic sprint planning, daily standups etc. We didn’t do anything specifically because we are a fully distributed organization, but we’ve undoubtedly converged on certain practices that have helped us because of this.

Q5: How do you introduce new team members and get them familiar with your tool stack?

A5: We have generally hired people with a decent amount of experience, so getting people up to speed has not been a limitation. For example, when we initially began ramping, I expected it would take several months to get to a productive state. That turned out to be a matter of weeks. We have reasonable onboarding materials and a bunch of people who are eager to help others when they need it. We tend to throw people in the deep end, as they say, and pretty much everyone swims without a problem. But, new members of the team also know they won’t be allowed to drown.

Q6: You’ve mentioned easier access to talent. How do you pick people that you believe will add the most value? How do you keep them with the company? And if they’re not a good fit, how eager/quick are you to let them go?

A6: We have a very strong bunch of engineers, and half of the organization was here before I joined Sonatype, so I won’t take any credit for that. However, having a very strong bunch to begin with has allowed us to recruit additional strength. Great developers want to work with other great developers, and great developers can very easily detect not so great developers. In terms of keeping them, I fundamentally believe you have to strive/iterate towards an ideal work environment, one that the team is very much responsible for creating and refining. Combine that with solid product management execution and a careful balancing of overall engineer disciplines and you have a rewarding/fulfilling environment. Also, “hire slow, fire fast” is ideal advice. We are quite careful in hiring, and while we are not merciless, if someone is not working out *and* it is clear they are not going to work out, then they need to move on.

Q7: How is the performance of individual team members assessed and corrected by the team as a whole?

A7: Individual performance has not been an issue. People do make mistakes and sometimes they need guidance and help. It tends to be rather obvious when this is the case given the transparency that agile provides. We have a well functioning code review process in place as well, which provides ample opportunity for everyone to see what everyone else is doing and provide constructive/corrective feedback. There is nowhere to hide, but honestly, no one has anything to hide.

Q8: How does top management vision and participation help or interfere with the team’s self organization and learning cycles?

A8: We tend to over communicate, providing the engineering organization with a lot more detail about the business than most people are probably used to. Sometimes there’s good news. Sometimes, not such good news. But open and honest dialog maintains a strong foundation of trust. The remote nature of the team has had an interesting dynamic. Corporate BS, drama, politics, etc. (and we, like any other organization, have some of this) has had very little net impact on engineering as a whole. We’ve spent a lot of time and energy refining our product management practices, aligning from the CEO on down (which is only two levels in our case due to the flat nature of the organization). Once you have a framework for continuous improvement, people truly feel empowered to make changes and there is clarity in terms of where they need to go. Things just fall into place. This doesn’t happen overnight, but over time a very strong foundation is built, one that is created by the organization rather than being imposed on it.

Q9: What regular connections do you have with all team members to help them feel connected to the other team members?

A9: As the head of engineering, I try to have some kind of interaction with everyone every few months. Sometimes these are at meet-ups, sometimes on the phone, sometimes in Hipchat. As we’ve continued to scale, this has become more difficult, but I am also confident that people have what they need to be effective. They know unequivocally that they have my full support. Our agile discipline is such that there is natural interaction and collaboration with other team members daily and in many cases, across teams. We also set up a room in Hipchat called “The Lounge” for random (sometimes inane, sometimes funny, sometimes even inappropriate) topics. That has been a surprisingly valuable forum to help hold the organization together and it’s really a “must have.”

Q10: How do you ensure the jelling of the team without co-location? What about eating lunch together and doing other social activities? Also, how do you ensure osmotic communication?

A10: This is more difficult, but we don’t have to deal with standing up completely new teams with people that don’t know each other. We incrementally add new people to teams, so there is cultural continuity. We have an annual engineering summit where everyone gets together and smaller meet-ups throughout the year, which helps as well. And, as mentioned above, we have “The Lounge” room in Hipchat for random conversation and topics.

Bonus Q: Where is that blog referenced on growing team size deliberately?