BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Sharon Robson on Enterprise Agility at Tatts Group

Sharon Robson on Enterprise Agility at Tatts Group

Bookmarks
   

1. Good day, folks, this is Shane Hastie, we are here at Agile 2015 and I am with Sharon Robson. Sharon is the Head of Enterprise Agility for Tatts Group in Australia and she is also an IC Agile certified expert in testing. Sharon, welcome, thank you for taking the time to talk to us, first of all, I suppose, tell us about your experience at Agile 2015.

Thanks, Shane, it’s great to talk to you, it’s great to be a part of this amazing experience. I found Agile 2015 to be very interesting, I am profoundly impressed at the level of maturity of the conversations that I am hearing and the information that’s being thrown out in the talks is absolutely brilliant. One of the things that’s surprising me though is the basic nature of some of the questions that are being asked. And I was thinking about this throughout the whole conference, worrying that the message isn’t getting through, that people aren’t really understanding agility. And then I realized that we are probably on to the second or third generation of people who are new to agility and that actually made me feel much better, it allayed my fears that we are not actually going backwards in knowledge in the community and I was worried that the dogmatic approach of some of the schools versus the pragmatic approach of others was diluting the message, but what I think I am seeing now is more and more organizations who normally wouldn’t be involved in even attending a conference like this coming and then having the courage to ask these questions which I think it’s just brilliant.

   

2. Then if we think of the technology adoption curve, perhaps we are moving towards at least early majority and perhaps even some late majority?

Well, I can only say I hope so considering it’s been 15 years.

Shane: Agile is no longer a new concept.

And then you meet some of the people who have been here and they are not shy about saying “Well, before it was Agile, we were doing this and we were doing that”, well, when you look at it, this stuff has been around for a good twenty to thirty years and I think it’s great that we are getting more and more adoption, but yes, that’s a very low bell curve that we are following.

Shane: Speaking of bell curves and following: the Head of Enterprise Agility, what does enterprise agility mean for Tatts Group, and perhaps you could fill us in a little bit about who Tatts Group are.

Sure. Tatts Group is by and large an entertainment company, we’re based in Australia, we are one of the largest organizations in Brisbane in terms of IT, we are a company that focuses on two aspects of entertainment, mainly wagering, so we look after on course betting, TAB, all that sort of stuff, online betting for any sorts of sports events, we also do lotteries, almost everywhere in Australia, almost, not quite, we do a lot of the instant scratchy cards, we are very much focused in the wagering and gambling, gaming industries. We are looking at how do we keep up with the competition, because competition is fierce and it’s a fast-paced fast-changing industry across the board, both from your lotteries, your gaming, your wagering, attributes. One of the things that we’ve learnt is that an organization that is in a such a fast-paced industry has to become fast-paced and how it manages and reacts to what’s happening in the industry. The demographics, the people who use our technology are changing very much as well, so we are using a lot of the new techniques that are coming out, things like personas, and demographic driven development to help really target our products where we want them to go. What we are finding though is that our rate of change needs to be faster, we need to be able to adapt and respond to market conditions very, very quickly; we want to grow, we are a company.

The other side of it is we really want to build the best workforce. I work for an amazing person, Mandy Ross is the CIO of Tatts Group, the technology side, and she has this great drive, it’s absolutely fabulous, she wants to turn our organization into the number one place to work in Brisbane. So we are really focused on building teams who love their jobs. So what do we do? We want to make people empowered, we want Dan Pink’s utopian society - mastery, autonomy, purpose, we want people to own their work, to really invest in it, to enjoy it, so things that we are doing we are basically changing the way we are working and my role as Head of Enterprise Agility is to work with the leadership team to actively and proactively modify, I don’t want to say restructure, but modify the shape of the teams that we are working in. We are moving towards a very core team, eight to twelve focused way of working, cross functional teams, we are breaking down silos, but we are not only breaking down silos between traditional software development elements of a team, we are also breaking down the silos between infrastructure and marketing and finance and the business across the board and ops and support.

So when we start to look at our products, we are looking at cradle to grave mentality, not just new feature, we are talking about how can we give this thing life for five to seven years and then replace it. So growing the maturity and the mindset of the way we work, how we work and who we work with is really a corner stone of what we are trying to do. It’s a big job.

   

3. You are also in what is a very heavily regulated industry. And that is often held up as an excuse that “we can’t do Agile, we’ve got all this regulation”. How does Tatts Group tackle that?

We are heavily regulated, yes, we are, we have all sorts of compliance, things that we have to do, not a problem, they are part of delivery, so we build them in. We are taking the regulators on the journey with us, we are taking audit and compliance on the journey with us, we are building the security PCI teams into our team structure, so these things aren’t bolted on, they are built in all the way through the work that we do. Part of our definition of done includes all the steps that we have to deliver for compliance, for regulation. We are making sure that we start with that end in mind, the end being we have to be regulated, we have to release regulated code, so what we are looking at is how can we make the regulators lives easier, too? Rather than an us-versus-them culture, what we are looking for is we better get the best product out the door as soon as we can, so how can we work together to do it? We work with many regulators, because it’s not just a regulator, it’s a multi-jurisdictional regulation so we have different degrees of compliance, depending on where we are trading. We have some of our products that have different degrees of compliance depending on where they are being used, so we have to know exactly where we are going when we start, this is not something that you can retrofit easily, so we want to start with that end in mind, work with the regulators and aim for effectiveness and efficiency.

Shane: You’ve totally dispelled that myth.

Absolutely. And one of the things I’ve learnt since I’ve been in at Tatts is that regulators are human too and they have the same issues that any team has, balance of the workflow, dealing with the peaks and troughs, predictability, estimation, whenever they are doing a regulatory activity there is a possibility they are going to find something that is not compliant, very rarely when it comes to us, of course, but what we are looking for is how do we actually smooth that cycle, so when we are looking for the frequent feedback loops, we are looking for fast turnaround times and if we deliver a huge amount of work to a regulatory team we can’t expect them to turn around in two hours. We have to have visibility of their workflow as well and simple concepts like Kanban, we are going to tell you what’s coming, and we are going to tell you what’s the most important thing, so can you work with us to regulate the things we need first, first? And they say things like yes, it’s staggering but working as partners rather than adversary makes a big difference.

   

4. You mentioned you are doing this across the organization and your role - enterprise agility, this is something that we heard a lot about at this conference, the agility term instead of Agile, and definitely talking about enterprise, we also hear “scaling”. What is scaling?

To me scaling means allowing everyone, so I would like to think of agility as an inclusive type activity rather than exclusive, so it’s not just for tech, and the reason why I really focus on the enterprise and the scale of it is that a team works not in isolation, teams rub against each other and you can have tech teams rub that against each other or you can have tech and marketing, tech and finance, tech and business, infrastructure, facilities, I need the guys to give me walls, so I’ve got to work with them. So, what I am trying to do is wherever we have those interfaces, bring the business on the journey with us, so include them in our decision making, include them in the showcases, include them in the defect detection, include them in the planning, include us in their strategic workshops, include technology in the big decisions that need to be made, work as a team aligned by business, not the business, our business to deliver the best solution that we can, rather than us being two separate divisions, because we are all part of the whole.

Shane: At a pragmatic level, what are some of the things that you’ve been doing to bring this along? This is quite a big shift for many organizations.

Huge. I’ve very much focused on Agility as opposed to Agile, so pragmatic really good practice, and I don’t care where it comes from. One of my most practical models that I roll out across the board, no matter who I am talking to, is I get people to imagine how a team in an emergency room works, doesn’t matter what rank you are, doesn’t matter what skills you have, object of the exercise, stop the person dying and if you were a doctor or a nurse, you could still put a bandage on, it doesn’t matter, or you are going to clean the blood and get the syringes, everyone works together. I like to get people to think about the whole emergency room dynamic, high-performing teams. And that’s what I am aiming for, we are transitioning not to Agile, we are transitioning to high-performing teams, small teams of self-empowered high-fidelity communicators who are not afraid to make decisions. So, there are three phases in our transition, step one is educate, so we actually start to get people speaking the same language, getting people saying the same things, getting in the right headspace.

Step two, then we actually start to expose you to the practices, so here is what it is, very much based on the why not the how, and then we are going through the enhance phase. Once we get everyone to a certain level, then we will start to say now we know the basics, we are going to come back and start again and make it ours. So we’ve got those three stages and what I am doing for each of the teams is I make them, and sometimes it’s quite a robust conversation, do visual planning, get it out, get it on the wall so we can see it. They hate it and that’s fair enough, I’ve even had people come up to me and say “You’ve turned our workplace into a crèche, it looks like children work here”, and I said I don’t care, now we know what work we are going, we are going to move towards a more digital visual planning tools, eventually, but we have to get the practices, we have to get these basic katas in place, without those everything falls apart. So, step one, visual planning, now visual planning allows us to raise any of the challenges that the teams have got, communication first and foremost. I had a great team and I am sure they won’t mind me telling this, they did their visual planning, very silo-ized team, developers, testers, they did their visual planning and they came up with a Kanban board and I called it the wall of doom because they were doing all this dev work and they had to put it in the ready-for-test column, but the column wasn’t big enough, so they made the column bigger and they just kept on adding to this column, but it was really ironic because the testers had to walk past the wall to get in and out of their seating area, so what happened was the testers walked by this column every day and the column was just getting bigger and bigger and bigger, it was like an avalanche coming at them, but because the team wasn’t a cross functional team, it still isn’t a cross functional team, it was “I was standing on these train tracks watching this train come at me” and then we started to talk about it because it was up and I was there one day and I said to the devs “What is happening here, this is going to kill people”, and a tester walked past and said “Yes, dudes, that’s me” and we started to have this conversation and the developers then said “Oh, we need to stop cutting code”, and then they said “What could we do if we are not cutting code”, and one of the testers, God bless his little cotton socks, he said “Automate tests for us”.

So they have spent the last two weeks automating tests, brilliant, absolutely brilliant. So just by having the work up and out we exposed the problem of too much work coming at the testers, who were already behind because they were testing something else, the developers now understand what this was going to do to the testers and they are focusing on building better practices organically.

Shane: So simple practical things that really make a difference. What are some of the big obstacles that you are coming up against, because I suspect it isn’t all that easy.

The challenge of working with smart people, very, very smart people that I work with and they’ve tried Agile before. So one of the first things I get is “Oh, we tried this before, it didn’t work” and I sympathize very much with them because they have and it didn’t. At team level you can’t make Agile work without support throughout the entire management structure and this is why I really enjoy what we are doing here because this time we got it from the top down, not from the bottom up, bottom up the teams just keep on running into hurdles and running into challenges and running into issues and you just get exhausted, you can’t fight those battles all of the time, so that’s a first thing, tried it before, doesn’t work, ok, so we’re going to try something different, that’s the first thing I do. Second is this pressure that people put on themselves, they expect themselves to know everything instantly, they want to flip a switch “We’re now Agile”, and one of the things that I am trying really hard to do is I roll out an agility transformation plan that’s the minimum of eighteen-months long. I’ve got forty key topics that a team needs to be familiarized with via in-the-room training, e-learning, coaching and then on-the-job training, so there are four dimensions of the transition of knowledge that we go through, over forty key topics that I have distilled into what I thing makes something agility-focused, not all of them from software development, but that’s going to take a minimum of eighteen months to go through. So, one of the things that I am trying to do is take the pressure off everyone. The other thing is, once again, smart people - perfectionists. We have a challenge of catastrophizing, what I am going to do is lay it all out and extrapolate until the end and the end is always doom, so I am not going to start.

What I am trying to do there is basically say give something a go, we know it’s going to end in doom, but what we are going to do is before we get to doom we’ll pivot away, we’ll change something, so we are not going to stay on this path all of the way, we are going to go on this path until we hit the point where we are can see doom and then we are going to go in a different direction. And that has really helped people realize that there is not just one way, there are lots and lots of ways. And one of the things I am trying very hard to do is build the knowledge in at the team level of practice, this is why I say I am not going to tell people how to do their job, I am going to tell them what we need them to do and I am going to tell them why we need them to do it, how – that is up to the teams, they are smart people, show me. How am I getting people to buy in? Oh, man, it’s so hard. They want to come to work, do their jobs and go home, which is fair enough, I have no problem with that, none what so ever, but what I want to do is build ownership of agility into everyone at a gut level, so we have done some amazing things. We are in the middle, right now, of a twelve-weeks of agility challenge, based on the twelve principles of Agile and every week teams are challenged to complete an activity in alignment with the twelve principles. We give everyone a passport that has to get stamped or signed off by a member of the action team when they complete a challenge.

The first one was big, identify and satisfy your customers, and that was basically we took the entirety technology team offline for a morning and we did a scavenger hunt throughout the entire building, eight floors of people running up and down, solving codes, dealing with those little mechanical metal games that people play, wooden blocks, Lego, tennis balls, we had all sorts of things that represented the different types of customers that are internal to our organization and external, so we had personas, we had to identify who was this persona based on what they were telling you, so we had people dressed up, we had facilities, we had HR, we had finance, as mystery bonus points, if you could guess who they were you got mystery bonus points for your scavenger hunt, that was the big one because it’s the most important one, and we are going to finish with reflect and adjust. So over the twelve weeks, we are helping people understand the principles behind the agility, not focus on the practices.

   

5. Any advice for others that want to follow in those paths?

Trust, that’s the big thing and its one thing I say more and more of these days, a lot of Agile transformations have come from the position that what the teams are currently doing is flawed. It’s not. I always come from the perspective that I arrive just in time, I’m hired just when we need to have the transition and I trust that the teams have worked to the best of their abilities to get to the point they are at, so I am not going to negate anything like that and teams should trust themselves, but they should also trust that change is going to happen, so resisting the change it just makes you tired. So for me the corner stone is trust, trust from both dimensions.

Shane: You also mentioned the fact that you had that support from the top down that has made a huge difference.

Absolutely. When we kicked off the twelve-weeks challenge, the CEO, Roby Cooke, came and spoke and they asked me to give him some talking points and I said just say things about agility and flexibility, he went and researched the twelve principles and he spoke to each of those twelve principles in his opening address. Mandy Ross, the CIO, she is very much in favor of agility and ownership and autonomy of teams and very much in the mindset of the teams know what to do, I am going to stand back and help them deliver, not tell them what to do. The CTO from the infrastructure space is basically all over agility saying how can I make it happen in infrastructure, how can we get infrastructure into the teams, how can we change the way we work to support software delivery, but also agility delivery. So from that management structure, nothing but support, which is brilliant.

Shane: Sharon, it sounds like an exciting environment.

It certainly is.

Shane: Well, thank you so much for talking the time to talk to us today and enjoy the rest of the conference.

Thanks, Shane.

Dec 31, 2015

BT