Episode 10. Developing Agile

Kirsty puts Erika in the hot seat to talk about how we came to be ‘Agile’ at H6. There is a difference between thinking you’re Agile, talking about it, and actually getting there. Erika explains the lingo, as well as the change management that has happened in our organisation – as well as for our clients – to become Agile and steer away from the misconceptions of disorganisation or lack of documentation.

Read the blog Erika mentioned on Agile management on our website: https://www.hutsix.com.au/keep-in-touch-with-site-visitors-and-boost-loyalty

Transcript

Kirsty: 0:18

Hi everyone, and welcome to episode 10 of HutSix's podcast, Invisible Skyscrapers. My name's Kirsty, I'm the Senior Business Analyst at HutSix, and I'm here talking to Erika Hamilton, who is the Chief Operations Officer.

Erika: 0:36

Not yet, I haven't signed anything.

Kirsty: 0:38

Okay. Do you want me to do that again?

Erika: 0:43

I've been the Jack of all Trades at HutSix for the last three years, and I'll finally get a title change next month.

Kirsty: 0:49

We call her the big boss anyway. So anyway, today we're talking about agile and it's been something that HutSix has transitioned into as our way of working, over the last three...

Erika: 1:06

no 18 months.

Kirsty: 1:08

only 18 months. Okay.

Erika: 1:09

Yes.

Kirsty: 1:10

We just want to talk, a bit about how we got there, what it is, how it's helped us, where we see it going, all those kinds of things. So Erika, do you wanna start off by introducing a bit of how we came to be agile?

Erika: 1:27

It aligns a lot with my development at HutSix ,Is there a nice kind of thing to kind of line up together. But probably before COVID we HutSix, we always called ourselves agile. But we didn't actually have any systems and HUD's... Agile is wonderful. Agile is basically the top level of what it is. It's being comfortable with making iterative improvements and it's not about a lack of process, it's just process with intention, just what I always say. People often think agile means no documentation, no systems, no budget capacities, you just build where the software you want and you just figure it out as you go along and someone will pay the bill eventually. But in actual fact, it's about having well-intentioned goals and benchmarks and collaborative team conversations, bringing in the client to being part of that process. Documenting where you go wrong, where you went and always improving, and you're always improving in really short increments. So for us on our projects, that's between one to four weeks, depending on what kind of system we're working on. And agile itself and scrum methodologies there's lots of buzzwords with this that I'm going to be throwing around, but was started it in the early two thousands by group of software developers in the States and there's many books and courses and qualifications and, and all the rest of it. But again, what our previous episode was about, it's all about mutual respect for the Engineer's expertise and valuing their opinion. Plus also the User requirements and the actual user voice, having a strong voice of the customer in your development process so that whatever you're delivering or shipping, very quickly, meets their needs. Because if software meets the user's needs, they're going to be more likely to use it, they'll be really good advocates within their organisation to keep it and we just continue to help it grow as their organisation grows, which we've seen with a number of our clients. That's the top level there, but with HutSix itself so I got a bit sidetracked, but we always could ourselves, but we didn't actually do anything agile at all, really and we had wonderful Zara joined our team in the middle of 2020 and she said, so what project management system do you use? We don't really have any, and she's what are you doing? So it took about six months of change management to move our team into JIRA Kanban and scrum boards to move from Zendesk into service desk management within JIRA and also to confluence, which is the documentation pillar, because documentation is super important and sharing ways of working is super important. As we've had an 18 month process and we've continued to evolve that internal system as we go along. We had, when we started, we had everything in one board, which is not what you have stopped best practice. We're now at this point where we've been able to split the teams up, we've got what we call pods, we've got groups of engineers and analysts and hopefully product owners once we do you have recruitment drive? Who kind of work on one particular system in one particular spot and they all work together, often the clients involved in that, that JIRA board too, so they can see what we're doing when we're doing it, no need to have back and forth emails, phone calls, and that's where we're at now. So we've gone completely turned it on its head when, before nothing was Brad had an idea of basically the quote's accepted and the invoice is sent, and that was our project management style, to now being able to pull up a graph of the team's performance and show it to a client and say, we're on track, we're on budget., We're on goal. Which is great, so customer satisfaction I'm sure has gone through the roof because there was no bar there before, but I've got a benchmark it's a bit more clear.

Kirsty: 4:57

Yeah great. It seems like the whole agile umbrella has a lot of fun, little buzzwords underneath it. It's made up of all these little code names like Kanban and scrum and pod

Erika: 5:11

and epic and issue.

Kirsty: 5:13

Yeah. Do you think you can break that down a little bit for us and explain to people who might not have heard of agile methodology before, kind of what the levels are and what it involves in how you specifically manage a project.

Erika: 5:29

How it actually works yeah. So agile again is about making iterative improvements on a regular basis. Now of course, Making iterative improvements you've got to track that, so you actually know what you're improving when, who, what, where. And so we run all of that through JIRA through what's called a board. There's two ways to manage things Kanban, or Scrum Boards they're two different, two different words. So scrum is, I always think of scrum as it's the here and now, it's what's happening right here, right now, usually within that iteration period and the short word for iteration period is sprint because you're sprinting towards a goal. It's like a hundred meters sprint in the Olympics, you're going, we're adding in this feature, we've got two weeks to do it, let's go, and then off you go and then once you've done the sprint, you have a chat as a group, which is called your sprint retrospective and you reflect on how the last fortnight went, what went wrong, what went what needs to be updated documentation wise. We all, we talk about budgets, of course, as well as the overall timeframe. And then we look at planning in the next sprint. We go, okay, we've learned all this stuff. How are we going to put it into action for the next sprint? Is that sprint even still appropriate? Is that idea still relevant? And we have these discussions, it's usually between an hour to two hours, we'll often we'll have them as a group. So the pod, which is just the team pretty much who work on the project and then depending on the client, we will bring the client into that meeting too and they are there the whole meeting, we don't have a pre secret meeting, it's, it's all the dirty laundry is out in front of the client and that freaks a few people out. It freaks some clients out, but I really like it because you can go to these meetings and I can say the requests that you've put through a really great, but you don't really have the budget to fulfill them. But we can't sacrifice these three features because if you don't have them, that's the minimum viable product, so what do we do? And I come to those meetings and say, I don't really know how I'm going to solve this problem. This is your horse in the race, this is ours, how can we work on it together? And it's a lot of shuttle diplomacy, which I really appreciate because you can have those honest conversations with clients instead of feeling, I always felt awkward kind of calling a client out of the blue, after we've been working on something for maybe three months, which is waterfall development. You call the client, you'd usually be halfway or closer to the end at this point and go, Hey actually it's not going to work and we're going to need double the budget and I don't know what to do and they get really annoyed. And, fair enough, whereas with agile, we can see the tsunami before it even hits. We can have that conversation and then maybe that's going to prevent. Happening in the best place. Cause all those anxieties and fees, it's a safe place to share all of that.

Kirsty: 8:07

Yeah. How have you noticed The relationships with clients and projects and all the things involved with that change since we've adopted an agile methodology? What have the benefits been? And do you feel like there's been any sacrifice involved in the change?

Erika: 8:54

I think the benefits have been like being clear with the client has had some upsides and some downsides, some of our clients really love it and they're really drawn to it and they're drawn to the transparency and the accountability of meeting every fortnight and say hey you said you'd do this last week, is it done yet? And they go, oh my God, it's not done and we can realistically go, are you ever actually going to do that? Or should we close it out or do you want us to do it? Or what do you want us to do? Which some people like, and some people that's not nice to hear from someone you're paying to tell you, you need to pull your own weight. But what is honestly found? We've gotten, we get a lot more work done this last year. We've gotten the most work we've ever done ever and the team's a bit bigger, but not, ginormously bigger. I think the accountability has been a double-edged sword. Some people have left us whether they were staff members or clients and it makes people who don't want to form into this, line of of mutual respect and accountability and ,things, I would consider the bare minimum at work to care about each other and actually if you make some mistake, you own up to it. Has made people reconsider if we're the right fit for them and it's made us see those clients and staff who don't fit in, stick out like a sore thumb. And it's really easy for us to see that and we've been on the phone a bit over the last 12 months and say, I actually don't think we were that compatible anymore under this new paradigm. Do you want to work with us because we're not changing away from this, or should we help you find someone else to help you? And some of the people we found them someone else and they've moved on and they're really happy. And some people have gone, you know what I'll will I can compromise and I can do this, okay, great. It's a learning muddy experience, but I don't think there's really been many downsides, there are downsides to JIRA service desk, if you want to be specific. But yeah, overall I would never ever go back to what we were doing before, because it was very stressful. What was happening then. Yeah

Kirsty: 10:47

and how do you compare what we were doing before to what we're doing now, in terms of that, why do you think we've been able to do so much more work and achieve so much more in the same amount of time? In an agile system, as opposed to what we had previously.

Erika: 11:05

I think the big part of it has been the collaborative nature of the team, so having all of everyone's projects and work and having confluence of having people's documentation public has just made it much easier for knowledge sharing to happen. When we have our meetings about our workload, if one member of the team says oh I can't do that, it's going to take me three or four weeks, then someone else can speak up and go actually have you done it like X, Y, and Z? I've written up on how to do that and they'd go, oh, no, I haven't yeah, it'll shave a week off of that. Or, think about this interdependency or that or that or that and we've also brought in like you'd have actions in our testing and QC has just gone through the roof too, which has really helped that. We're able to move much faster and there's less of this whole, If I don't do my bit, I'm a failure. It's I can't do my bit. I need help. And it's a safe space to ask for help. Yeah, and we usually get that before gets too late, which is really good.

Kirsty: 11:56

Yeah, I think from my perspective as well, Since we've moved to agile, it's really made it clear where the gaps are. We've really been able to improve everything since adopting this kind of iterative approach to projects and collaboration and transparency. And it's really made it obvious, where we need to step up our processes and where we need to bring in different planning techniques and approaches and that's where we brought in our whole scoping side of things as well. Particularly from my perspective, because that's where I'm working in and seeing that actually, if we can plan all of this out in an agile way from the start and follow it through, with our clients, with these regular intervals of checking in on the project and seeing that everything's still relevant, everything's still working in interacting with each other the way it should. It's made a huge difference to our end product and

Erika: 13:01

totally.

Kirsty: 13:02

Our budgets and our client relationships and maybe even now team relationships and being able to be across what everyone's dealing with and help each other with roadblocks.

Erika: 13:13

And yeah, and I think, Because I've been going down to Adelaide a bit with Brad and yourself and I'm chatting with people who are also in the tech space and hearing them say, I just cannot find engineers. I can't find any staff. I can't do it. And, it's true there is, I'm not going to rattle off statistics in case they get them wrong, but there are thousands of jobs in the engineering space in Australia that are vacant. our team, our engineering team has tripled in the last year, when so many other engineering teams have gone the opposite direction and people talk to me about that and I'm just like, we haven't had any problem. We've actually had the opposite, we've just ballooned and we're actually at a point where almost our entire team is new, cause we've had people be promoted or move to different arms. As we found these gaps, some people have left, but that's just a natural turnover and go well, I think it's actually our internal processes and systems and people come into our team and, on the seek ads in the interview, we do things like this do you want to do things like that? And they go, yes, please and they can jump on board. Which I think just attracts that really good talent. That's been a really wonderful thing that's come out of it. Plus hopefully staff retention And feeling like you're not being micromanaged at work is always a really good feeling.

Kirsty: 14:22

Yeah. We could go into that, but workplace cultures' probably a whole other podcast episode that I'm sure we'll Get to.

Erika: 14:29

Yeah.

Kirsty: 14:30

There's a lot of things we could say about agile and how much we love it, coming from the dark days

Erika: 14:35

and I think on this, it's some things I've, might've said people might be like, that's not how you do it, or that's not this or what, but, that's how we do it and it works for us and what we do right now, like as of this week, was completely different to what we were doing three months ago.

Kirsty: 14:53

Yep.

Erika: 14:53

Our internal systems and every three months or so I have a new idea or I speak to someone new or I read something else, or someone from the team speaks up and goes, I think we should look at this functionality in jira, I think we should do this or whatever, and then we make a change. I might listen to this in two years time and cringe because one: at my

own voice and two: 15:09

at what we used to do, but right now, It really works for us and there's no right or wrong way to manage an internal team. I think as long as people feel safe and respected to listen to, and software wise, we ship excellent software with no security holes. Our clients are happy. Our budgets are great.

Kirsty: 15:28

Yeah,

Erika: 15:28

we're on the right track and I did write a blog article about this as well, which I'll get, Leisa

Kirsty: 15:32

if you want to read,

Erika: 15:33

if you want to read it, I send to our clients when they go, why do I have to use JIRA, I'm like this is why.

Kirsty: 15:37

Okay, hopefully this isn't too big a question to wrap us up with, but using agile methodology, there's obviously a lot of tools and software that we use. We use confluence for documentation. We use JIRA for our logistical project management and a lot of things in between, but if someone were wanting to adopt a bit more of an agile project management style, what would you say is a simple way someone could integrate that, maybe even without thinking about all the software and tools

Erika: 16:09

yeah,

Kirsty: 16:09

the agile principles, how could someone adopt that and help their own workflow? I

Erika: 16:14

look back on our own experiences and a lot of this is, it's change management, because if you're bringing in agile it's basically, it's just a way to manage your team, and a way to manage your projects. There's really nothing fancy about it when you put it like that, and the change management bit is the hardest bit. It's actually quite easy to pick a software and to load all your stuff in and set up integrations, whatever. That's the easy part of it, actually getting your team to use it, make sure that it meets their needs, and that sort of thing, is quite hard. Especially if you've got a team, who are usually have a top down management structure, they don't do anything until they're told by a project manager. Moving to agile people than had independence and autonomy and their own responsibility and that itself is like a really big weight to carry if you've never had to do that before.

Kirsty: 16:57

Quite confronting.

Erika: 16:58

Yeah, and if your staff weren't hired, knowing that they'd have to behave like that I think that's the real linchpin. I think if I was doing it right now, today, and we're moving from waterfall to agile, I would, present my idea to the whole team. I'd pull them into one room and say, this is what I'm thinking and then say, this is how it is and then I'd have a meeting with each one of them- individually- the day afterwards, so everyone can think about it and digest and sleep on it, and hear their concerns, their ideas, their everything. But if you don't already have a collaborative culture, people don't feel like they can talk to their manager anyway, about concerns, they might have about a new change management process. That in itself is like a bigger obstacle to navigate before you even think about, I want to change how we run the actual work.

Kirsty: 17:39

yeah.

Erika: 17:39

If your team don't feel safe, then there's no point in changing anything because it actually won't work, they won't adopt it. Because, I heard this once from someone in government and they said, we want guaranteed innovation and that's such an, you were with me when, it's such an oxymoron because innovation means you don't know what's going to happen.

Kirsty: 18:00

Yeah.

Erika: 18:01

And bringing in a new project management style and to doing change management. Yeah. There's bits that you're hoping will work, you've got a bit of a hypothesis. There's things that you've adapting and bringing in to try and get it to work, but you have no guarantee of how it's going to stick.

Kirsty: 18:16

Yeah, and I think that's one of the beauties of agile as well as that there is that flexibility and allowance for change.

Erika: 18:23

Yeah,

Kirsty: 18:24

because you're coming back together so frequently.

Erika: 18:27

Yeah.

Kirsty: 18:28

That you are making space for change and for people's voices and for people to have power, in their own work and have their voices heard in that space as well.

Erika: 18:40

When we brought in agile to the team I put my hand up without realirealisinging and ran with implementing that change management within because I just saw it as a really obvious thing and I just kinda went with it and I think that helped in HutSix because I was Brad's assistant. I still technically am now, but I was seen as someone who not an authority figure, which I think helped the team listen to me.

Kirsty: 19:02

Yeah,

Erika: 19:03

we did still have problems anyway, but I think coming from someone who hasn't tried to throw anyone under the bus before not that Brad has, but he's seen as less of an opposing threat.

Kirsty: 19:13

Yeah,

Erika: 19:14

because change is scary and

Kirsty: 19:15

yet

Erika: 19:16

people react to that differently.

Kirsty: 19:18

Yeah,

Erika: 19:18

I think that would be like a tool I would have, is to have round table discussions about what, what you don't know, what you're prepared to lose or gain or what might be a surprise. Again, surprise oxymoron. You don't know what it's going to be. And then having a really good change agent who can go, this is what we're going to do, I'm going to listen to everyone and we're going to adapt and that's their kind of their sole focus and

Kirsty: 19:38

yeah.

Erika: 19:38

Yeah.

Kirsty: 19:39

Ready to take risks and explore.

Erika: 19:41

Yeah.

Kirsty: 19:41

The better way to be,

Erika: 19:42

and then support from management on that as well to go, this might not work, but I'm going to try and I don't know where I'm going, but follow me.

Kirsty: 19:50

yeah. Yeah. There you have it, folks. Thanks so much, Erika

Erika: 19:58

thank you Kirsty.

Kirsty: 19:58

Talking about agile today. It's something we're very excited about. And thanks everyone for listening to this, our 10th podcast on Invisible Skyscrapers.