Most agile teams may proudly claim that they're cross-functional – often mentioning how the developers also test and how the designer sometimes makes small changes to the code on his own. However, the odds are that most of those teams could do much more. In this talk you will learn how a team can benefit from incorporating a broad set of responsibilities ranging from the usual design/code/test to not so common activities for a team to take over, such as infrastructure, marketing, public relations, social media presence, and customer support.
Target Audience: Members and managers of Agile teams
Prerequisites: Basic knowledge of agile development
Most of the development teams I've seen or been part of have been really small. Yet, most of them have also been very cross-functional making the team capable of doing pretty much anything and everything there is to do about designing, building and shipping software. However, one particular team has struck me as an exceptionally satisfying team to be part of and reignited my drive to go out and share with the community what I’ve seen (I used to tour many, many agile conferences every year since 2005 but more or less stopped a couple of years ago).
In that one inspiring team we took the concept of being "cross-functional" to a new extreme. We didn't only design and build our awesome online radio application squarely within our small team room. (The service in question is called “radiot.fi” and it’s a joint venture between the Finnish national broadcasting company and the association of commercial radio broadcasters in Finland.) We also took on tasks and responsibilities normally taken up by our clients or their marketing department, or a separate project management role.
With a team of 3-4 engineers we would go out to meet the radio channels we were integrating with and help them produce good-looking image assets. We would draft press releases on behalf of our client and we managed the various social media outlets for the online radio application. We managed our budget and burn rate ourselves, and visualised key business metrics such as average session length (of listening to radio via our app) and total minutes of radio content being consumed in a rolling 30-day window.
Doing all of that brought us so close to the core business of running the online radio service that we felt like we’re running our own company here. We were committed – and connected – to the business. However, perhaps the most important sense of connectedness was towards our end users – the people who listened to their favourite radio channels through our app. Striving to be as connected with our users as we possibly can, we set out to build simple feedback channels right into the software itself as well as analytics to tell us whether our users are becoming more engaged. We also put a stake in the ground and decided to channel all customer feedback through our development team rather than let our customer respond to them.
We read and responded to every single email received, directly from our own email accounts. We wanted our users to know that we are listening and responding so we also kept record of the feedback and reached out to the individuals who’d asked for a feature or complained about a glitch as we made progress and fixed those issues or implemented those features. (Also, one of the main prioritisation factors was in fact the number of feedback messages mentioning a given feature or issue.)
In this talk, I’d like to present the Radiot.fi team’s practices as a case study type of narrative and a source of inspiration, and invite the audience to brainstorm other practices for getting “up close and personal” with 1) their customers or business sponsors and 2) their end users.
The resulting connectedness towards all directions was so powerful for us that I'd love to see the practice spread to more and more teams out there.