Donna: This presentation is from Agile UX 2015 held in Sydney. For more presentations from this and other conferences, please visit uxaustralia.com.au.
I'd like to introduce Cameron Grice. He's at the ABC, which you can tell from the slide. I love case studies about stuff I know and stuff we use, so I'm really looking forward to this. Thank you.
Cameron Grice: Thanks Donna. Good morning. As Donna said, I'm from the ABC, the national broadcaster. I've led the delivery of a project over the last nine months. We launched a new website, ABC Radio. Before that I worked as a UX designer on, I guess, the first version of what we launched. I guess today it feels a bit awkward for me, because three years ago I sat in this room. I didn't even know what Agile was, so it's a bit of a change for me to be speaking here now, when it was like what was this mumbo jumbo that I heard about last time.
This is the website that we just launched. It was the first time for ABC Radio that we had live and on-demand content available in the one place. It was also the first time we had all our stations accessible from the one place, so Triple J and Classic Fm, some of the stations that you may know of, they are both accessible from one website. Today my talk has four key points. I'm going to go through how I made the room to have Agile delivery possible in a big organisation, my own personal Agile conversion, how I dealt with complexity in the project and how I worked to resolve cross-team dependencies. They are the four things we'll look at today.
First, making space for Agile delivery. I guess this is more for those who work in-house. You have, I guess, a lot of processes or processes that may not ... They may not be working the way that you want or they may just have always been done that way. How do you make change possible so that people stand up and go, "We can do something different."
When I first started at the ABC, the design and development team was ... They were basically a bit depressed, because everything they needed to do was either a hack. It would be something like JavaScript, front-end hack. Let's just manipulate the DOM and see what happens. Or it was a timely, let's put in a change request to the big CMS project and maybe after a couple of months we'd get a yes or a no, could the change request happen. But it was a very slow process and we didn't really know what we could do.
We were fortunate though that we had management that had kind of ... New management came in from, I guess, a consultancy background and they were receptive to the cries for help that the team had, so they empathised with the team and they listened. Management actually kicked off a research project and in hindsight - and I guess maybe you will have experienced this as well - having management want to kick off a research project is ... We're very fortunate, because I don't think many companies want to spend money just on research.
This research project that we kicked off, it was a very linear process, so I guess at this stage the department wasn't comfortable with the idea of Agile. So we started of with a map of what we were going to do in this research project. It provided certainty to the company, that they knew that we're going to get something at the end and they knew exactly what their resources were doing along the way.
I have a background in advertising so for me, again, I was sceptical of all this. We know we have old websites, we know they don't really work on mobile. Why do we need to go out and do research? Why don't we just start building stuff? We know what to do, we know how to use Photoshop, we know how to make code. Why are we making a research project?
All this effort was going into research and I guess there was that tension there that we had to break or we had this current state in the company. How do we break the tension and go, "We need to have a vision for the future and we need to break the current website support maintenance model that was happening." I'll just go back here for a sec. In that first research phase - and I guess, as Ben and Diana talked about - this is that first diamond, so we're going out to find out what our listeners actually did and then we're going to set a vision for it.
Going out and finding out what our listeners did, we did contextual inquiries and we did over 50 of them. I guess contextual inquiry was just going and spying on people in their house to see how they use radio in their house, in their car and what they do while they're listening to radio. The second bit was we came back and we did all the Affinity diagramming. We had paper everywhere. It kind of looked like a scene from A Beautiful Mind. Just like crazy Post It notes and brown paper everywhere and then we came back and delivered a report. That report led us to have a good, strong vision for the future of radio.
This was, I guess, that future of radio that we got to, so personal radio - the easy to listen to companion to my daily activities. We'd done our research, we knew what our listeners wanted. Now we needed to build momentum again to get people in the organisation to understand what we were doing. With the first part of that diamond we had a project called Audio Future Experience, which you can see here. That red one. I guess that was our first attempt doing this. We went to the organisation, they approved our research, they knew we were out there doing research, but they were kind of like, "Project Future Experience. What does that mean? Or Audio Future Experience." It was a very abstract name to the project that we were doing.
We were still seen as that development website support maintenance team, so we would get that sarcastic remark walking past our offices, "I thought you guys worked with computers. Why is there paper and Post It notes everywhere?" The business was aware of what we were doing, the organisation was aware. They didn't really buy into it at this stage, so we needed to take it to that next step. That next step was personal radio and this happened, I guess, just in a crazy moment in the manager's office. Beautiful Mind scene with Russell Crowe. His office looked like he was a mad man. He just scribbled out, "audio future experience," and we wrote "personal radio."
I think for us the learning experience here was that you need to make it, I guess, tangible for those in your organisation to understand what you're doing. So audio future experience made sense to us. We were trying to define the future of radio. But for stakeholders and management, they wanted to know what are we actually going to get and personal radio was a way for us to explain that to them. We were going to deliver the easy to listen to companion to their daily activities. This was at a time when Spotify was going nuts, Beats had just been bought by Apple. You had things like the Swell app, which had just been also bought by Apple. So that recommended listening experiences was happening. It was in the press and everyone knew about it.
That idea that you need your organisation to pay attention and I guess similar to how Ben and Diana said that person moved on from a company, you need to set it up so that there's momentum, so people buy into the future that you're selling them in the company. We had this slide deck of personal radio that was, I guess, a big slide deck that we presented everywhere to every stakeholder we could. I ended up presenting this presentation about the future we're going to deliver to maybe 30 different boards in the organisation and I even presented it to the Australian Cricket Team for some reason, but that's another story.
They all knew what we were doing now, they kind of understood it, they were excited and we had to sell it to them and again this is where, I guess, that advertising background verse being in-house was very different. In the client consultancy relationship someone says do this for us and they give you money and you kind of do it. You try and do it the best you can for them and you learn with them, but you end up doing it. When you're in-house, you get to kind of make your own pathway. So we had to sell it to the organisation to say, "This is what we're going to deliver for you. Leave us alone and let us do it and trust us that we know how to do it." That's, I guess, putting that spin onto it and giving things title. Sharing with everybody so that everybody knew exactly what you were doing.
I'll quickly go through, I guess, the four insights, so this might be interesting to know. What we got out of our big discovery phase. We learned, I guess, for ABC Radio, that we were basically hiding our content. So to find our audio content you had to troll through all these different websites or you had to troll through iTunes and find the podcast you wanted. We didn't make it easy for people to discover our content online. We also know - and this was an industry thing for us - listening to radio is still hard. It's not simple like turning on the radio at the kitchen sink. We struggle to provide that convenience that the kitchen sink radio does. Or the car radio makes it simple. Just turn on and you get what you want.
We also found, I guess, the older generations are scared of those connectivity and cost issues. They don't want to stream on their mobiles, because they just don't understand what does 500 megabytes a month mean. And then smartphones are becoming people's media hubs. On our first contextual inquiry, this was actually a picture of the street in front of a guy's apartment. Someone had chucked out a HiFi stereo. We know that the younger generations aren't actually ... They don't need their HiFi's when they have their iPhone or their Samsung Galaxy III or whatever it is. They just plug that into a speaker. They don't have a radio anymore.
What we went to sell the organisation was that we need to make it easy for people to listen to just the radio they want to listen to, the same way that Spotify is recommending new content or that Swell or NPR - these other recommended listening apps - they just give you the bits that they know you're interested in. We also wanted to make that discoverability really easy so that you could find the content you wanted. We have such a broad range of programmes at the ABC, but we need to make it easy for people to find those and that was the same with music as well. How do we make it easy for people to jump between the rock music on Triple J, the classical music. We had all this, but it was all spread across different websites, different iTunes podcasts. We didn't provide that single product to make it possible and simple for a listener.
At this point we had people hooked. I guess they'd been used to the organisation doing little promo tiles on the websites or fixing a broken URL. That was kind of the situation we were in. We hadn't had designers and developers and teams go, "We're going to do something that's different for the organisation." This was changing that momentum of how things just normally happened in the ABC. We had people hooked now.
This was part of the deck that I presented internally. As I mentioned, you want to sell it in your organisation, but we had to ... I guess we put it to that degree that we were going to make listening to live music or live radio easy. Listening to on-demand or catch up easy. We had to sell it, "We need to be in the car dashboards in the future." When you have companies like Holden and Ford, not necessarily planning to have AM/FM tuners in the car and that's where ABC's biggest audience is. We had to tell them, "We need these API's so that we could have audio in the car, in the dashboard, in the apps." We knew this was a stretch vision or a stretch goal, but it makes the management or exec that you need that buy-in from to sit up and listen, because it kind of scares them a bit that that's the future.
I guess something on this chapter. Creates base for agile delivery. We needed to create discomfort in the organisation. So this doesn't mean making yourself unemployable or making yourself annoying in the organisation. It just means making people, I guess, upset with how things have always been going, because we're humans. We like the status quo, we like stability. You need to make them go, "We could actually change." The other thing was once you made them uncomfortable, you need to gather support for a future vision and an exit plan. So we don't like what we're currently doing. Our audience knows this. They're not happy with us. Here's a way out. Let us do it and trust us and we'll deliver on this.
Now talk about my Agile conversion. As I mentioned, I didn't really know what it was three years ago. I remember people saying Steve Jobs' book talks about standouts. That was about it. When I left the advertising world and my colleague said to me ... He's like, "Oh, Agile can be done if it's done well. If it's done poorly, it's awful." I think that awful bit stuck with me for a while over the last three years. I've seen Waterfall work. I guess Waterfall gets a bit of a dissing, but in the advertising world, you could get given a large chunk of money, you do your wire frames, you get your sign-off. You had that mad rush in the last two weeks, but that's kind of fun and there's adrenalin there. You have the late nights and you have that train wreck at the end of a project. Then you go live and you go to the pub and it's all fun. That's actually exciting.
I was sceptical of Agile and I guess the next thing that happened was I was getting burnt by cowboys. I don't know ... there's a company that does Agile training. Access Agile. And [Alaan 00:13:51] from there explains it really well that you have the business cowboys, so they're the people that go, "We're doing Agile." Then they'll come and tap you on the shoulder and you're two-week sprint when you're supposed to be focused. They'll say, "We're Agile, we're flexible, can you work on this other thing?" And you lose the stability you're supposed to get.
That other cowboy, that I got burnt by, was a developer cowboy. So, "We're Agile, we don't need to do any planning, any documentation. Let's just start building now." That obviously didn't work either for us. The third one for me that put me off again of this Agile thing was all the jargon. I heard all this jargon - iteration, quick development, standouts, retrospectives. Agile is a way of thinking, but I didn't really understand the benefit of it, so you hear all these terms and you'll hear managers use these terms, but what was actually the point? I was pretty burnt at that stage.
This is the first version of the website. It was like a smaller feature set that we went live with. So we released just live streaming in one place for all the stations. We tried to do this in an Agile process, but I guess it didn't really work and we got to a point where we needed to go live. There was that mad rush. We had the typical manager response - throw more money at it, throw more resources at it - and that didn't fix it of course. After this went live the team lead actually left and I guess that's where ... He didn't leave for that reason. We went live, it was kind of successful. He moved on to another company, greater green pastures for him.
However, this led me to have a shift to move from being a UX designer to leading the project. The team leader role was empty, I had an opportunity to step up, but it was kind of ironic that the way I had to step up first was to do a Chevron chart and this is not Agile. This is kind of awful, but I had to do it at the time, because this is what my managers wanted. They wanted to see these moving forward, Chevron's arrows. We're going to win, we're going to go live. They have certainty. It was the language that the manager spoke and it worked for me, because I got the confidence to go, "You can run the project." At this stage I still wasn't convinced what is Agile, so I was kind of just doing what I thought we could do to get a project going.
I have three things that kind of helped me along my Agile conversion. The first one was I went to a conference and I heard Karen Hughes, the technical director from the Monkeys Talk and he spoke about influencing the advertising process, the way they work. He gave the whole talk without using any jargon, so I kind of picked up he's talking about this Agile thing, but he didn't mention Agile once. He didn't mention user stories, he didn't mention prioritisation. He spoke about how he changed the process so that it wasn't a train wreck in an advertising agency. The example he gave was, I guess, you do a lot of alcohol websites in advertising agencies. The first thing that's going to stop you from going live is not having your 18+ gate at the front of the website. If you're going to go live with that website, he's like, "Well, do that thing first, because we can't go live with a beer website if we don't have the are you over 18 first." He didn't talk any jargon. That was really helpful.
The second point in my conversion was talking to Nicholas Muldoon and he's an Agile coach at Twitter. I actually, ironically, met him on Twitter. Or I guess that's convenient. I tweeted about an article he wrote about fixing inter-team dependencies and then we met up for a coffee and I think the point here was that he again explained that you don't just go away and do Agile. You don't follow this process blindly. It's about what works in your company and in your context. He really gave me an insight into those ... I guess this is when I realised I was working with cowboys, because they said we're going to do these things, we're going to sit in a meeting room for four hours and we're going to write user stories. Even we had a full deck of wire frames already there, we were just doing this process mindlessly.
He kind of helped me to see that you can't just necessarily flick a switch in your organisation and go, "We're going to do Agile." It has to be what works in your company, what works with the developers or resources you have available. You don't want to just change overnight and say, "The way we've been doing it is completely wrong. We're doing it this way now." It can be a gradual process within the context of your company.
I guess I then started to lead this project a bit halfway house between Waterfall and Agile. Maybe that was awful for the team, but it kind of worked and then we had new management come in and that new management helped me to move towards a more structured Scrum process. So we got into having those disciplined sprint planning sessions, those disciplined retrospectives and reviews. We started to do all the Scrum ceremonies. We did it gradually. We didn't just flick the switch overnight.
The third event was Henrik Kniberg. Hopefully many of you have heard about him. He's kind of famous for the Squads, Chapters, Tribes and Guilds model. Hearing him speak resonated with me, because the environment he was working in was very similar to a media organisation. It was an audio ... A music company. He gave really clear examples of what was working for him and what wasn't in Spotify.
Along my Agile conversion I would say that you don't want to follow the processes blindly. Understand the purpose of why the Scrum processes or the Kanbans or the XP. Understand why they're there, so that you get the intent of them and you're not just doing it because the textbook told you to do it. Also if you need to persuade others in your company on why working Agile is the best thing to do, use examples from competitors. Find people in your industry that are working this way and you can show a successful case study or show how it changed their environment or their culture and persuade them that way, because you don't want to be that Agile bashing textbook person going, "We have to do this, because everybody else is doing it." It's just not really convincing.
Overcoming complexity. This is hard for the ABC. The ABC is a big organisation and ABC Radio in particular. We have over 50 broadcast stations and over 20 of these stream online. That's a lot of audio, a lot of content being made and each of these stations have their own website or their own player. Again, a lot of technical legacy things for us to work with. These have been built on top of content management systems that could have been ... There's one that was actually made 15 years ago by one developer and we still use it today. If you think about what the internet was 15 years ago, it wasn't a pretty place.
We had all these different stations, all these different audio players. Each of these had different UI's, the user experience was really different for all of them. You'd have things where it was like, "Oh, do you want Real media player or Windows Media Player?" And it's like seriously? This is 2014. What are those things? It became more of a tension when ... There's a free plugin that makes Windows Media possible to play on a Mac that started to charge money to instal it. We're the ABC. We can't really tell people go and instal this paid-for plugin to listen to our content. They weren't going to buy that. Really awful experiences. They've been working for some people, but there was no consistent user experience or UI.
We also had no centralised data source. So again, all these different stations, all these different CMS's. Each of these stations has a studio that makes audio. They all have different equalisers and different ways of outputting audio. So to make an online presence to get all this in one place was also going to be a challenge. We had different audio on-demand file types. AAC, Windows, MP3, Real player still. How do we get HLS streamings? Different codecs for all the formats.
This was a solutions architect. Really awesome guy. He was the first guy in the ABC to map the whole radio system and how everything connected together. That was his six A3 bits of paper that he mapped together across all the stations, from sound in a studio, getting it onto a website.
With 50 stations, lots of programmes, we also have lots of content. We're trying to build a centralised system here. How do we pick what content goes first? Again, we had programmes from conversations with Richard Pfizer all the way to the heavy metal show. We can't do all this content at once. You have to prioritise things.
What did we do? They were kind of all the problems that we had. Really simple to fix all those things. We started off by being different, I guess. Differentiation. This was a way to explain to the organisation you have your current station websites, they're fine. Your broadcast listeners are happy, they'll come there, they'll catch up on the audio that they might have missed in their car journey. They'll find their programme or their schedules. We were really going to focus on getting those new listeners. The people that may not know a station or a programme name - and targeting a way to reach those people, because that's a really high-value thing for a media organisation to find new people to listen to their content. So instead of going, "We're going to migrate one-for-one, what you already have," it was kind of like, "We're going to focus on this specific gap that we have and work over there so that we don't get tangled up in the complexity of migrating one-for-one."
This also allowed us ... This diagram is showing that those current station websites, if you're going to go play a catch up piece of audio, it would play it in the new website. So we had that existing stable thing for those older listeners who were stuck in their ways - in a really nice way. They could click play and they could listen to it on the new website.
Our new website ... It was going to be responsive, it was going to have the mobile formats that worked. No more of this Windows Media, Real player junk. This is a illustration that is based off Brad [Fosts' 00:25:08] responsive diagram. The tree diagram, it's basically copied from Brad for us, but it kind of shows that our current station websites, they're these awkward trees. They're about to fall over. They're kind of working. They are really old. We're going to plant a seed so that we can leave the old tree standing for now and we're going to go work. We're going to do a limited scope, but it's going to be an immature seed of a new radio website that's kind of linked to the old one, but it allows us to go play and innovate while those station websites stay put. In the future, as we continue to build on the website, it will become more fully-featured. We'll put all the content into it, we'll put all the station websites into it and the old tree will be so obsolete then, that hopefully it can just be turned off.
We also prioritise. So we estimated, based on ... I guess this is from ThoughtWorks. It's Gary O'Brien. It's from a presentation called Lean Enterprise. We prioritise with a formula. We found the formula was really helpful in setting that first prioritisation. However, things didn't really end up how we wanted, so we started with a formula. Then we got top priority - let's build a help page. It didn't really ... We weren't going to build a help page first. The prioritisation was good, but then we had to shuffle it around, because you still have to follow your gut and your instincts.
At this stage I was still sceptical about backlogs, so we prioritised. We had a backlog, we looked at the business value, the complexity and that will give something a score. So we had 100 lines of a backlog of ... 100 lines was limited scope for us, because we had so much complexity. But again, we had contact pages at the top of our prioritised backlog and that wasn't really going to get us new audiences. We estimated with designers and developers - so everybody was there - but I guess this was just ... We were trying to follow the process and it was kind of ... Felt a bit like science, but that wasn't really working for us.
We also prioritised the content. So we put the highest value content first. That would mean that it was either the most popular shows or shows that were really hard to play, so the music shows which were rights-managed that at the moment worked through a flash player. We also took a slice across all the different categories of content.
With those stakeholders, following the textbook for Agile, we only involved the key stakeholders that we wanted. So we avoided meeting and I defended the team from irrelevant meetings that weren't going to help us with our project. And at the point where we couldn't release, we released and internal beta to show everybody inside the organisation what we were doing. We didn't really get that feedback that we wanted.
In overcoming those complexities, we prioritised the high-value items. So we used the formula, but we also used our gut instinct. So the formula was really helpful, but we also needed to go, "What do we feel like we actually need to make first for our audience?" I guess it's following the spirit of the process and not just following the process blindly.
At a micro-level, we also prioritised what we were going to build first. So like [inaudible 00:28:43] in the monkeys, putting that 18+ gateway first on the alcohol website, we needed to put first the thing needs to actually play an audio file stream and we also put up front analytics, because we knew we didn't want to get stuck at a point of launching to go, "We haven't implemented analytics."
The last chapter of today's talk is how I got the teams to align with dependencies. When that first version just went live - just live streams - we really churned with development, because we had an API team in Melbourne that were developing the API. They would change the format of the [inaudible 00:29:24] every five minutes, so we'd make something on the front-end and then two days later it would stop working, because the format of the data had changed.
When I took lead of the project we started with a prototype. This was a really cheap and quick prototype that I just made in a couple of hours in Foundation and HTML, but it was a way to show the vision to everybody. So we had the API team and my team in one room going, "This is what we're going to build." It was actually a real "a-ha" moment for some of the developers. Even the solutions architect - really smart guy - but you could see his face light up because me explaining it in words didn't work. Showing an actually UX experience made him realise what we were doing. So they could go away and start building the new end-points that we needed for the next version of the website.
To find those dependencies, again, I find these things awful. This massive Gantt chart. It helped us ... I was in a situation where management needed this. It took a lot of effort. I wouldn't do it again, but it highlighted those dependencies between the teams, which meant we could go away and communicate and make sure we're all right. It forced us to work together, because we knew where the project was going to need to align. This meant that we would then work at better ways of communicating, because we knew when we were going to be dependent on each other.
Now we had much better communication. So we had a back-end team and a front-end team. The back-end team - before the project started - we would sit down and we'd review what format of the data would be given to us. We negotiated up-front and said, "We're going to do this." It didn't mean that we weren't agile and doing all requirements up-front and then designing it up-front. It just meant that we reviewed and worked together more collaborative. We had two teams and we kind of had an agreed handshake of how we would work together to make sure we weren't making each other churn.
I guess here it also shows that we're moving towards a team structure. Previously I was the only lead, I guess, on the front-end project, but now we'll have two specific product managers. I'll lead the way that the team works, but those product managers will be really key in prioritising what gets done, because I guess you could hear that having someone work with the team and going, "This is the priority. This is how we're going to work as a team," or facilitating that teamwork, you get hand strung between two different things. You have stakeholders asking you when are you going to do this, when are you going to do that? While you're also trying to protect the team. So separating those two roles is really key and I guess it's straight from the Scrum textbook that you have a product owner defining what you're going to build and a Scrum master saying, "This is how we're going to work," or facilitating and removing any impediments for that team.
The big learnings out of those dependencies was negotiate the rules of engagement up-front. We didn't plan how we were going to build the data for the API, we just agreed that, "Before you guys build an end-point, you come talk to us. We'll sit down, we'll review the two teams together." Then we were able to work with, like, a static data format. They are able to go away and build it and it was seamlessly joined together. So if there was changes, it was communicated. It was communicated through joint retrospectives and reviews or it what just making sure that we had the two teams communicating upfront.
I guess the other thing that's good here - a room full of UX people as well - is that that UX prototype was key to making the vision of the product tangible. So those developers that I was working with, we could explain to them what we're going to do, but just actually showing them, it was fundamental to making sure the project was a success.
To conclude my talk today, I guess UX was fundamental in kick starting that Agile delivery. Having that research tasks, those contextual inquiries, that was what helped us to get momentum in the organisation to make us able to not be maintaining websites, but build and innovate on a new product. The website has now become a strategic priority for the organisation. Because of that momentum that was created through presenting to every board we could find, giving full demonstrations to all the staff in a station, presenting to the Australian Cricket Team, it made it that the organisation new what radio was doing. Therefore, even if we have changes in people and resources, we still have that momentum, because everybody is aware of what we're trying to complete.
I guess I'm more than a convert now. I guess I'm an advocate. So working with other people to have their teams work in an agile way. Going from not knowing what it is to telling people, "Let's fix the way we're working so we can get stuff done." And have a good compass upfront. You have to prioritise ruthlessly, you have to set your scope, but you really need to know where you're going, because that will make it a lot easier to prioritise and choose features that you should build or you shouldn't build. It was really easy for us to have stakeholders come and say, "Why aren't we doing this?" But we could go back to that research that was like, "We've talked to over 50 Australians around the country. We didn't really get a sense that anybody would use that kind of feature." Or we could go an test it.
Always reflect on the intent of the process. So we all know those different ceremonies of Scrum or Kanban, but it's going back. "Why are we actually doing this. What's the benefit that we're supposed to see from it?" Because if you're not seeing the benefit, it may not be worth doing it or you might not be doing it right.
So that's the end of my talk. I hope that was helpful. You can find me on Twitter. We are looking for UX designers, so that's the URL to go to if you want to come and work in a great place.
Thank you.
Donna: Thank you very much. I reckon it would rock working in the ABC. I just reckon that would be so cool.
We have time for questions for Cameron. So any questions about what he just talked about?
Audience member: Thanks for the talk Cameron. One of your last comments actually poses a question for me. You said you're more than a convert, you're an advocate. Why?
Cameron Grice: Why? I guess having been in an organisation where I saw projects not getting finished or not getting done to a good quality, I saw that when we actually worked in those two-week shorter sprints, we had stakeholders coming into our reviews. So we were able to show a stakeholder every two weeks. I guess getting that feedback straight away, I saw that the project actually progressed and got better. Those ways that we worked in Agile, I saw the benefit to our project and also to the team. So the team got a lot more motivated, because I guess they normally are further away from management. Having management in the room as they're demonstrating - whether it's, "Here's a visual design, here's this new feature." Getting good feedback or corrective feedback from a management directly to a developer or a designer, just gave them energy to keep doing it in those two-week sprints that we completed the project.
Audience member: It was a great talk, Cameron. I have to ask this question. Why the Australian Cricket Team?
Cameron Grice: Why the Australian Cricket Team. Obviously ABC has a sports programme called Grandstand. So we actually went to the Australian Cricket Team, one, to show them what we're doing in radio, but also just because my manager wanted to meet [inaudible 00:37:36]. So we got to meet [inaudible 00:37:41] and I shook Mitch Johnson's hand and that was all the office heard about for the next two weeks, so yeah.
Audience member: Hi. How did you start with roll out the Agile from the ... Obviously you've had a quite few products and quite a few teams working the same time on different products with a massive backlog. How did you start? Did you start with one team and make one team work in Agile and then rolling out the other teams?
Cameron Grice: I guess that was what I hinted at with that we had teams that were just doing maintenance on websites. By going out and selling the vision of the future products, we actually got the organisation to allow us to move people around into teams. So teams were allocated to a website. So here's your Triple J team, here's your Classic FM team. We said, "Well, hang on. We're not going to win radio online if we keep just maintaining websites. We need to do this new thing" and that allowed us to actually break up those teams and move resources into having a dedicated front-end team for the new website and having a dedicated team to build an API for us. It was really fundamental that we shared with those managers that got to decide where people worked to go, "We need to change how we work to build this thing. Do you want it or not? And if you want it, we need these people."
Audience member: Hi Cameron. [inaudible 00:39:04]. You talked about dependencies for a while. I'd like to know how you manage a situation where you fall behind and you're starting to miss deadlines and dropping those dependencies. Particularly because you also mentioned you got a shortage of UX resources in there as well.
Cameron Grice: I guess in that beautiful agile world, you don't fall behind. You work to your two-week sprint. We were lucky because we'd experience it go poorly, we had planned two-week sprints. We did sprint planning separately with the two teams, so we only had two teams to be dependent on each other. We sprint-planned separately, but we did our reviews and our retrospectives together. I think that's where the retrospectives were key, because we were able to open up and go, "Well, I thought you guys were going to do that for us this week and you didn't." Or "You did it this way and maybe we didn't communicate it correctly.
So in those retrospectives, having the API back-end developers with the UX designers and the front-end devs, it kind of just opened up communication channels to go, "We didn't really like how you gave that to us this way. Can you give it to us another way?" So the dependencies kind of got smoothed out just because of communication between the two teams. We didn't have a situation where one team fell behind and that affected the other team greatly. So that communication was key to that.
Audience member: Hey Cameron. Thanks for the talk. I saw one of the slides. You had a relatively large HL team. About eight or nine members in a team. Did you have any problems managing such a large team in your practise and how do you handle conflicts and collaboration between the team members? If everyone takes five minutes to take a standup in the morning, that will be like ... I don't know, an hour in the morning probably?
Cameron Grice: Yeah.
Audience member: How do you handle these?
Cameron Grice: That's a good question. I think that's another ... Maybe that's kind of one of those myths that comes around with Agile, is like the purpose of the standup. If your standup's longer than 15 minutes, you're probably doing it wrong and people aren't going to want to come to it. It was keeping people short to those, "What did you do yesterday? What are you going to do today? Do you have any blockers." I'm kind of pretty strict, so I would basically tell people to be quiet if they were having conversations in our stand ups.
The team ... We had two separate teams, so the team was only five and we would have other people come in and the backend team was only five. The stand ups were separate as well, so we sprint-planned separately, we had stand ups separately, but we had reviews and retrospectives together.
We got to a point, though, where I cancelled a retrospective and I had a developer complain to me and I think that's unusual. So I cancelled a meeting and a developer was like, "Why did you cancel the meeting? We had things to talk about." I think that's when you know that you're doing Scrum or agile right.
Donna: Great. Thank you very much.
Cameron Grice: Thank you.
Donna: We hope you enjoyed this presentation from Agile UX 2015. For more presentations from this and other conferences, please visit uxaustralia.com.au.
