Easy Agile Podcast Ep.4 Em Campbell-Pretty, CEO & Managing Director at Pretty Agile

"I had an inspiring conversation with Renae around the benefits of leaping out of your comfort zone and aligning team behaviour " - Chloe Hall

Chloe Hall- Marketing Coordinator at Easy Agile is joined by Renae Craven - Agile Coach, Agile Trainer, Scrum Master Coach and QLD Chapter Local Leader at Women in Agile.

Join Renae Craven and Chloe Hall as they discuss:

• Renae’s journey to becoming an Agile Coach and Agile Trainer
• Taking a leap out of your comfort zone
• The importance of taking time to gather feedback and reflect
• Building a team environment where everyone feels safe to contribute
• Aligning team behaviour and how prioritising learning impacts team delivery
• Why sitting all day is bad for you and how to bring movement into your work routine
• + more

Transcript

Chloe Hall:

Hello and welcome back to the Easy Agile Podcast. I'm Chloe, Marketing coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dhuwal speaking country. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islanders and First Nations people joining us today. Today we have a very exciting episode for you. We will be speaking to Renae Craven. Renae is an Agile coach, Agile trainer, scrum master coach, BASI Pilates instructor, and runs her own Pilate Studio.

Renee is also a chapter local leader at Women in Agile Brisbane and is the host of the podcast The Leader's Playlist alongside David Clifford. Renae's passion in life is to help people to be a better version of themselves by raising your awareness of areas they wish or need to improve them and to support them in their learning and growth through these areas. According to Renae, coaching is not about telling people what to do. It is about questions to allow them to dig deeper, uncovering realizations and their desire for change. Welcome to the podcast, Renae. Thank you so much for coming today. Really appreciate it and very excited to unpack your story, your journey, and all the success you have achieved, which is amazing. How are you today anyways?

Renae Craven:

I'm all, I'm good. Thank you, Chloe. It's Friday, so I'm always a bit wrecked on a Friday. Looking forward to sleeping in on the weekends and things like that. So yeah, Friday I'm already, always a little bit dreary, but other than that I'm fine.

Chloe Hall:

Well, that's good. Friday afternoon definitely can always do that to you. I'm very pumped for a sleep in as well. I think let's just get straight into it. So some of that I wanted to start was I just want to unpack you as a person, Renae, and kind of your story, who is Renae and the journey you've taken to become so successful today. So if you wanted to provide a little bit of background about yourself.

Renae Craven:

How far back do I go? So I did IT at uni, Information Technology at uni. So I started my career out as a graduate developer, software developer, pretty crap one at that.

Chloe Hall:

Surely not, I don't agree with that. I can't see it.

Renae Craven:

I knew enough to get by, but it was definitely not going to be something that I was going to do for the rest of my life. But back then I was 20 and kind of just was doing things that you were supposed to do when you grow up. You're supposed to go to school and you're supposed to do well in grade 12 and go to uni and get a degree and then get a job.

Chloe Hall:

Definitely.

Renae Craven:

So yeah, I ticked all those boxes and found myself with a degree in a job in a good organization. And I was in that development job for a couple of years and then I kind of moved more into team leadership and I was a team leader for a while and then I became a scrum master back in 2010. So that was when I discovered Agile.

Chloe Hall:

Okay. Yup.

Renae Craven:

And I think the rest is kind of history. So when I discovered Agile, things started to make more sense to me. Talking to people, having teams, working together, collaborating together, solving problems together, getting multiple brains onto a problem. That kind of thing was one thing that I never made sense to me when I was a grad straight out of uni. And I'm like, "What do you mean?" Because even during my university, I was a little bit different and I was remote. I did university remotely years ago and with a group of four others, there were four others, it was a group of five. We did everything together, we did all our group assignments, we studied together, we ate lunch together, we just kind of did.

Chloe Hall:

So with the exact same group?

Renae Craven:

Yeah. All the way through uni. I went from that kind of group setting to working and more of an individual on my own like if I've sat in a cubicle with walls that were higher than me, I didn't have to speak to anyone else if I didn't want to. And that never really sat well with me. It was never kind of who I was. So when Agile was, Scrum specifically was here's all these people we're going to throw together in a team and here's all of the problems and you work out together how you're going to solve it.

Someone's not going to tell you what to do or how to solve it, you've got to figure it out as a team, it was a much more, cool this is what makes sense, this works better. Why wasn't it always like this? So yeah, that's kind of where my Agile journey started and it kind of progressed as I did scrum mastering for quite a few years in different organizations, different scenarios, different contexts. And then I guess I was able to comfortably call myself an Agile coach I would say maybe 5, 6 years ago. I mean, there's nothing really that you can do that you go tick, Oh, I'm an Agile coach now.

Chloe Hall:

There's no kind of straightforward degree or certification.

Renae Craven:

No, it's really just experience. And I had experience around and people were telling me, "You can call yourself a coach, an Agile coach now, you've got plenty of experience". I'm like, "Yeah, but I feel like there's so much more that I need to know or that I could learn". So I don't really feel comfortable. But I was working for a consultancy, so that was just how I was being marketed anyway. So that was kind of 5, 6, 7 years ago that that started to happen. And then I do other things as well, like Agile training. I love training people, I run training courses, do the coaching as well. And then I've got my Pilates as well.

Chloe Hall:

Just an all rounder, a lot going on, that's for sure. I think as well, I just want to unpack, you had that transition when you were a graduate developer and you found it quite isolating. And then you came into this concept of Agile when you are working in teams. Was it when you started doing that Agile, did that kind of spike like a passion, a purpose of yours and that's what led you down that Agile training, Agile coaching road?

Renae Craven:

I think, I mean purpose, I still don't know if I know what my purpose is in life. Passion. I think what it helped me understand about myself is where some of my strengths were. And my strengths aligned with what was needed to be a scrum master and a coach later on. So the ability to facilitate, that's a big part of being a scrum master, a big part of being one of the key things about being a coach. And that was just something that I was kind of naturally able to do, but I didn't know until I started doing it, if that kind of makes sense.

Chloe Hall:

Yeah. I feel like, isn't that always the way, It's like you don't know something or you don't really know your strengths until you just step into it. You've really got to get out of your comfort zone and just try new things, experience new things. Otherwise, you're never going to know.

Renae Craven:

Yeah, exactly. So yeah, can't trying to create that equal participation in a room or in a workshop from a facilitation and facilitating a group of people from different walks of life to an outcome and just letting it kind of flow and let the conversations flow. But still, you've got to get to this outcome by the end of the day or end of the workshop. That was something that I was naturally able to do. And I mean, my first workshop, how I facilitated that, I don't even remember what it was, but I'm sure how I facilitate now is very, very different. But it was still something that I loved doing, that I enjoyed doing. And the training part of it, it's funny because at school I used to hate public speaking. I used to hate.

Chloe Hall:

You sound like me.

Renae Craven:

Yeah. All of that, how I used to get up in English and do an oral exam and things like that. I hated all of that stuff. I was very happy to just hide in the background and never answer a question or never cause any trouble or be disruptive or whatever. Except in maths class I was a little bit disruptive in math class.

Chloe Hall:

I am resonating so much with you right now because I was literally the exact same. And I've always had a bit of a passion for math. So in maths I was super outgoing, would ask so many questions. But in English my biggest fear was public speaking. I just could not stand up for the life of me. It was the worst. I was always so nervous, everything about it. And I think that's really interesting to see how far you've come today from what you thought back then. Was there any type of practices, lots of work that you had to do on yourself to get to this point today?

Renae Craven:

I think similar to what you said before, you got to get out of your comfort zone. And I think, especially early on in my career, that being pushed out of my comfort zone. There's a few leaders that I was working for at the time that, well a handful of people that over the years have pushed me out of my comfort zone. And in the earlier days where I wouldn't have done that for myself. So doing that for me or I didn't really have a choice because I was a good girl and I followed orders back then. It was just something that I went, "Oh okay, well that's cool". I'm glad in hindsight, I'm glad he did that because I wouldn't be where I am right now if I wasn't thrown into the pilot team, the pilot agile team. So yeah, there's things like that where I've been pushed into my comfort zone and just had a go and found out that, oh, it wasn't so bad after all.

Maybe I could do that again. And then you start to build your own kind of resilience, you go, well I've did this before so that's not much harder. I reckon I could do that. Or it's kind of thinking about it like that, but it's also changing. It was shifting my mindset to be you've got to get out of your comfort zone, you've got to screw up to learn. The way that it was at school where you got rewarded for being correct, you got rewarded for doing the right thing. And that's not how I learn. That's not how a lot of people learn. You have to screw up to then go.

Chloe Hall:

Definitely.

Renae Craven:

Okay, well next time I do that I'll do this instead.

Chloe Hall:

Yeah, definitely.

Renae Craven:

Or getting that feedback of how you did this, well next time maybe you could do this or whatever it is. Just getting that feedback. Whereas, I never got any of that at school. It was always Renae's perfect angel child, whatever it was.

Chloe Hall:

Still, nice though, but yeah.

Renae Craven:

Nice for the parents. Can we have more of Renae's in our class, nice for mom and dad. But in hindsight, it didn't really do much for setting me up for how.

Chloe Hall:

For reality.

Renae Craven:

Yeah

Chloe Hall:

Really.

Renae Craven:

Exactly.

Chloe Hall:

Especially because I've recently gone through that transition from graduating uni into a full time job and working for Easy Agile, I'm always being pushed out of my comfort zone in a good way. Everyone's so supportive, they're always like, "Oh Chloe, try this, try that". And I'm just like, "okay, yep, I can do it". And if it doesn't go amazingly well that's okay. I've learned something and I can do it better next time.

Renae Craven:

Yeah.

Chloe Hall:

You can't just sit in your comfort zone forever, you don't get that feeling of when you do something outside of your comfort zone, you just feel so good after and you're like, oh, prove to myself I can do this.

Renae Craven:

Yep. And I think the big part of that is acknowledging the learning is sitting down. So one of the things we do, I do as a coach is one of the key times for a team or an individual to learn is to actually sit down and reflect back and then what was good, what was bad, and what am I going to do differently the next time. And I coach teams to do that, but I have to do that myself as well. So kind of realizing that as a practice, that's something that I have to do is sit down and when I do these things I would need to gather feedback and then I have to sit down and reflect on how it went. What I think I can do better or do differently the next time around I do something like this so that I am also myself improving in the things that I do. So it's really having that time and that practice to learn to sit down and what did I learn?

Chloe Hall:

Yeah, I do. And I agree with that. You need to take the time to understand, reflect, realize what you have learnt. Otherwise, life is so busy and you just keep going and going and going and you can just completely forget and it's good to take that moment. I really like how that's something that you do in your Agile coaching as well. What else do you do when you're coaching teams? What other elements are there?

Renae Craven:

Some of the stuff I've already spoken about, having that equal, trying to get that equal participation, equal voice. Trying to, the buzzword is psychological safety, but trying to make, trying to build an environment for a team where everyone feels safe to ask a question or to voice their opinion or whatever it is. And when we've come from, as a coach, what we're doing is usually coaching teams, people, organizations, through a shift from a certain way of working to an Agile way of working. And that means that the whole telling people what to do and when to do it and how to do it is gone. That's gone. And now you want to build that capability within the team itself. So creating that safe space so that the

team can ask questions and understand what they have to do so that they can collectively deliver something as opposed to someone just telling them what to do.

So it's using your brain, using the collective group brain as well, instead of just having, not using your brain really, just waiting to be told what to do and then you'll know what to do, you just do it. But collectively solving a problem together as a team and then figuring out as a team how we're going to solve that or how are we going to deliver that is something that is quite, that's the bit I love as a coach, working with teams, building that kind of environment where they do feel safe to ask the dumb questions and things like that.

Chloe Hall:

And not have to be like, I think this is a silly question, but you definitely want to remove that.

Renae Craven:

And I think the other part is the learning still, it's exactly the same. It's taking the focus, trying to get the focus off, we must deliver and then we'll do some learning stuff if we get time trying to flip that around so that your, "No, no, no, you need to learn in order to get better at delivery". So take that focus, because a lot of teams will just say, we've got all these deadlines, all of this delivery pressure, we have to get this stuff done. We don't have time to sit down and think about what we've learned or how we can get better as a team. They're never going to get better as a team if they just keep in this endless delivery cycle. Making the same kind of time wasting things over and over and over again. So it's kind of flipping the mindsets of the teams as well to go, "No, hang on, we need to do this otherwise we're not going to get better as a team".

Chloe Hall:

Yeah, definitely. And I think that's where the Agile retrospective fits in perfectly. And I know I actually just came out of my retrospective with my team and we do that weekly and it's so good to come out of that with action items too. And it's like, okay, next week this is how we're going to get better. This is how we're going to advance, this is our focus and there's also no hidden problems because it comes up every Friday, we talk about it. So you're not going into Monday the next week with a grudge or you're annoyed about something with the workflow of the team. You've addressed it, you've left it in the last week, you've brought the action with you obviously, and hopefully it's going to get better from there.

Renae Craven:

Yeah, absolutely. And that's the key. It's the whatever we've decided in our retrospective of what we're going to do differently, we're doing that differently the next day or Monday in your case. It's not something we talk about and then we just kind of ignore it and we just talk about it again in two weeks time or whatever it is. It's the putting into practice the decisions you make as a team and those retrospectives all of the time. They're not massive actions either. They're just little tweaks here and there.

Chloe Hall:

Yeah, there's small things.

Renae Craven:

They just kind of build up over time.

Chloe Hall:

And that's the thing, it's like if you do it on a regular occurrence, they are small things, but if you are not doing it regularly, then that's when they build up and they become big things, big problems and massive blockers within the team as well.

Renae Craven:

Yeah, absolutely.

Chloe Hall:

Yeah. So I'm wondering too, Renae, when you do your Agile coaching and your Agile training, so you do that on an individual basis as well as teams. Do you think there's an aspect of the mindset, the agile mindset there, and does each individual need to come to work with that agile mindset for the team to be able to flow better?

Renae Craven:

Mindsets. If everyone had the same mindset then it would be robots or.

Chloe Hall:

True.

Renae Craven:

The world would be very boring.

Chloe Hall:

Very good point.

Renae Craven:

I think that's a bit, for me when I think about a team, an agile team, as long as there's some alignment on how the team behaves, why they exist, what their purpose is and how they treat each other and how they solve problems together, then the mindsets of the individuals within that team, they can be different. And that's fine as long as there's that agreement amongst everyone of this is how we are going to behave. I come up against people all the time who have been forced to work in this agile way. So their mindset's definitely not in the mindset that you need for an agile team, but if they're in an agile team and there's people in that team that have got the mindset or the behaviors that you need to have in order to deliver in an agile way, over time it kind of balances out.

And over time those the mindsets will start to shift as well as they see how other people in their team are behaving, how their leaders are behaving, things like that. So I kind of always think of it as more of a behavioral thing than a mindset thing. How do we make decisions, like I said, how do we treat each other, how do we approach problems, who are our customers, all of that sort of stuff. It's more that behavior that I like to, instead of me thinking, oh, they don't have the mindset, they don't have the mindset, I just kind of look at how they behave. Because at the end of the day, you can't force that

mindset. But as a team, when they start humming to working together as a team, they're going to be delivering what they need to deliver. And they all just, that's the whole cross-functional part of it. You're bringing together different minds, different backgrounds, different experiences, different skills, all of that stuff.

Chloe Hall:

Definitely.

Renae Craven:

You're putting them in a team together so that they can use their skills. They're all those different pieces to solve these problems.

Chloe Hall:

Yeah, no, definitely. I think the way people behave, it has a lot to do with it as well. And I think on that too, you can be in the right type of mindset, you can behave in the right way. And that has a lot to do with the way you're showing up at work as well. It's the way you come to work. If you're had a bad morning, then that's going to impact how you are that day. Or if you've waking up that morning and you have kind of a set morning routine that gets you into that good routine for the day, that good mindset and behavior, then it can help a lot. And I think as well, this is something I'd love to chat to you about too, because you've got the background of Pilates, you're in your own studio and you've been a instructor for how many years now?

Renae Craven:

It'll be a year and a half since I qualified.

Chloe Hall:

Yeah. Nice. Yeah, so I'm also an instructor. I've been teaching I think for about six months now. But I'm just wondering too, so you've got your two passions, Pilates studio owner and then also an Agile coach. Is there that element of setting yourself up for the day in the morning, do you think if someone, they meditate have the type of morning routine they exercise, can they behave better at work essentially? What are your thoughts on that?

Renae Craven:

Yeah, I think definitely the better you feel in yourself or the way feel within yourself, definitely has a direct correlation to how you come across how you behave at work. So yeah, if you've had a rushed morning or a traffic was crap on the way to work or whatever it is, then definitely you're going to be quite wound up by the time you get to work.

Chloe Hall:

Yeah, definitely.

Renae Craven:

It's going to impact the way that you respond to questions or respond to people or respond to your team or whatever it is. Yeah, absolutely. But myself, I don't really have a set routine in the morning. I go to gym but I don't go to gym every day. But the mornings that I do go to gym, I never feel like going because no, I just want to sleep.

Chloe Hall:

It's early. Yeah.

Renae Craven:

Yeah. But I have to go in the morning or I won't go to gym. Gym's something that, it's a bit of a love hate relationship. I know I have to do it, but I don't like doing it.

Chloe Hall:

Not even after? That feeling after?

Renae Craven:

Afterwards is good. It was like, but from, oh thank God that's done.

Chloe Hall:

Yeah.

Renae Craven:

Tick I'm done for the day.

Chloe Hall:

Out of the way.

Renae Craven:

If it was in the afternoon, if I went to gym in the afternoon I wouldn't go. It would just be, "Nah, it's too hard or I can't be bothered, I'm too tired". So getting up first thing in the morning, I set my alarm 15 minutes before my gym class starts.

Chloe Hall:

Wow. That is effort.

Renae Craven:

I know.

Chloe Hall:

That is good.

Renae Craven:

I race to get there but I have all my clothes set out the night before so I don't even have to think. I just get out of bed, I put my clothes on and I get in the car and I drive to the gym and.

Chloe Hall:

I do the same thing.

Renae Craven:

I do my class, I haven't had time to talk myself out of it just yet. But afterwards it's like, oh yes, excellent. That's done for the day. And yeah, it is nice to know that you have done that for the day as you start your work day as well. So on my gym days, that's probably my routine to get myself ready for work. But other days they're a little bit more relaxed I guess. I think if anything having a coffee is my, I cannot deal with the world without coffee. So whether I'm at home or I'm in the office, the first thing I'll do is if I get to the office I'll get a coffee on the way in. So I'm drinking coffee as I walk into the office. So yeah, I guess that you could call that my routine.

Chloe Hall:

No, I think a lot of people, a lot of listeners as well will be able to resonate with that. And I used to be like that and then it just, coffee wasn't sitting well with me. I found it was just really triggering my nerves for the day and everything. So it was so hard. I went from drinking two to three coffees a day to getting off it and now I'll drink like a matcha instead. But that was such a big part of my morning routine as well and getting off it was one of the hardest things I've had to do.

Renae Craven:

Yeah, I did that once. I detoxed for one of those health retreat things years and years ago and I had to detox off coffee and everything actually.

Chloe Hall:

Oh really?

Renae Craven:

Before two weeks leading up to it and yeah, coffee was hard.

Chloe Hall:

Yes.

Renae Craven:

Very, very hard. Because I love the taste of my coffee. I just have it straight, I don't have any milk so I love the taste of my coffee.

Chloe Hall:

Yeah, wow. Okay.

Renae Craven:

But maybe it's also the other benefits of not wanting to kill people that coffee does to me as well. I can deal with the world now. I've had my coffee.

Chloe Hall:

You're like okay, all right. Who needs coaching now? Who needs training? And I'm ready to rock and roll.

Renae Craven:

Yeah, I'm good now.

Chloe Hall:

Yeah. Nice. Yeah. Well the reason as well why I wanted to talk about the whole exercise correlation with work was because I did read your article on LinkedIn about what sitting all day is doing to your body and you're saying how Pilates can help with that. The section that I think resonated really well with me was when you said, when COVID-19 shut down the world and confined everyone working from home, those people who were working in the office environments, you found yourself sitting bent over a PC at home all day and it's back to back virtual meetings, you don't really have that chance to get up, have a break, go for a walk around and everything. And I think, I'm sure a lot of our listeners will be in that reality and even after COVID it is still the case. So I think just for the sake of everyone listening, is there any tips or anything to get you up, get you moving so you're not experiencing that on the daily.

Renae Craven:

I think the other difference is before COVID, sure you were sitting at your desk all day at work but you are also walking to the office and walking to meetings and walking to the kitchen and walking to go and buy your lunch and things like that. And you weren't kind of back to back meetings either. So you had that chance and if you were walking from room to room so you were getting up. Whereas at home it's just back to back meetings and I don't know about you but I run to go to the bathroom in between meetings.

Chloe Hall:

Yeah. I do. I actually do. Yesterday actually bit triggered by that.

Renae Craven:

I did that too yesterday actually. And even at the height of COVID, the back to back meetings were so bad. I didn't even have a lunch break. I was working, I was making my lunch in meetings and daylight saving as well. It always throws things because Queensland stays where they are and it throws everything out so. So in my article actually, it was more of a paper that I had to submit as part of my instructor course.

Chloe Hall:

Oh cool. Yeah.

Renae Craven:

And as well as my 600 hours of practice and.

Chloe Hall:

Yeah. I can relate, I didn't have to do the article though.

Renae Craven:

So I kind of just pulled bits out of that and because I thought this is still relevant and maybe it will resonate with people and especially the people that I'm linked, LinkedIn is the audience, right? So that just things that happen from sitting, sitting down's bad for you, full stop. Where you're working or sitting on a couch all day, whatever it is, sitting down's bad for you. And the longer you sit, the more kind of slouched you get. The more your spine is always kind of in the rounded state, the less you are using your back muscles, your back extensors, the more you're sitting down your pelvis, your hip flexes are shortening because you're always sitting down and that kind of tightens your lower back. And then you've got your, even just using your mouse, you've got that shoulder that's doing extra stuff or backwards and forward stuff constantly. And then your neck as well and your traps, everything gets kind of tight.

So things that you can do. I wrote a, my article's got an example class plan to undo the effects of sitting down all day in an office job. But that class plan uses all of the apparatus. So there's things you can do on the mat or the reformer or the Cadillac or under chair. But I run a few online classes after work and they started during COVID and they're still going. And I designed those specifically to undo, I know those people have been sitting down all day. So my classes are very much unraveling everything that they've done the all day.

Chloe Hall:

The body.

Renae Craven:

I mean my classes, my math classes anyway, they're usually focused around, I mean tips for people not actually coming to a class but undoing, you're doing the opposite of what you've been doing all day. So if you sit all day, stand up, walk around, at least listen to your smart watch when it tells you take a break. Stand up and take a break. And walk out to the letter box and get some sunshine at the same time, if you're lucky there's not much suns around these days.

Chloe Hall:

If it's out, make a run for it.

Renae Craven:

Doing kind of shoulder rolls and neck stretches and hip flexors stretches so that you, like I said, just undoing, doing the opposite of what you do when you're sitting. So think about the muscles or the tendons or whatever they're, even if you're not familiar with what they are, you know there's some at the front of your hip. And when you're sitting you can imagine that they're not being used, they're just being stuck there. So straighten them. Stretch them. If you're rounded all the time in your spine, then press roll your shoulders back, press your chest for and use your back muscles. And I don't even know if people are that familiar with back extensors. I don't know if people understand that. Because you've got your spine and then you've got these muscles that they're twisted that run either side of your spine. I can't remember the scientific name for them right now.

Chloe Hall:

No. Me neither.

Renae Craven:

We just call them back extensors. And when you straighten in your spine, they're working and you're switching them on. It's just working your bicep, strengthening that muscle when you straighten your spine and you can even go past straight and go kind of backwards. You are using those back muscles and you're strengthening those back muscles and it'll stop you being like a rounded.

Chloe Hall:

Yeah, just bent over in the computer all day.

Renae Craven:

Hunched over.

Chloe Hall:

Yeah. That's it. You don't want that.

Renae Craven:

So it's really just doing the opposite or yeah. Joining online classes. I can put you through some exercises.

Chloe Hall:

Yeah, well we'll definitely share that article as well with this podcast so people can see that program or might be something that helps. For me at work we're very fortunate that we have a standing desk and I think that that is just so amazing. Because if I work from home, I don't have a standing desk and I can feel the difference. My body just feels, you just don't feel right and I feel more fatigued and yeah, I just need to get up and move more often.

Renae Craven:

Yeah. If you stand all day, it's the same thing. You've got to sit as well. You've still got to do the opposite. Standing is like, because you can get slouch when you stand as well, so you can still over time get tired and kind of slouch over or you're still kind of tense in your shoulders and things like that. So you can kind of need to still be aware of your posture when you're standing and just self-correct or still go for walks, still give everything a chance to move the way it's supposed to move not stand still all day.

Chloe Hall:

Yeah, definitely. On that, Renae. Yeah. Thank you so much for coming on the podcast today. Really enjoyed this chat with you. I think there's a lot that our listers will get out of it and I definitely want to continue more of this Pilates conversation too.

Renae Craven:

Thank you Chloe. Thanks for having me.

Chloe Hall:

No worries, thank you.

"Thoroughly enjoyed my conversation with Jon, he shared some great perspectives on the impact of the Agile manifesto" - Amaar Iftikhar

Amaar Iftikhar, Product Manager at Easy Agile is joined by Jon Kern, Co-author of the Agile Manifesto for Software Development and a senior transformation consultant at Adaptavist.

Amaar and Jon took some time to speak about the Agile Manifesto. Covering everything from the early days, ideation, process, and first reactions, right through to what it means for the world of agile working today.

They touch on the ideal state of an agile team, and what the manifesto means for distributed, hybrid and co-located teams.

We hope you enjoy the episode!

Transcript

Amaar Iftikhar:

Hi everyone. Welcome to the Easy Agile Podcast. My name is Amaar Iftikhar. I'm a product manager here at Easy Agile. And before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging. And extend that same respect to all Aboriginal, Torres Strait Islander, and First Nations peoples joining us today.

Today, we have on the podcast Jon Kern, who is the co-author of the Agile Manifesto for Software Development and an Agile consultant. If you're wondering, you're correct. I did mention the Agile Manifesto for Software Development. The Agile Manifesto. So Jon, welcome for being here and thank you for joining us.

Jon Kern:

Oh, my pleasure, Amaar. Thank you.

Amaar Iftikhar:

Yeah, very excited to have you on. Let's just get started with the absolute basic. Tell the audience about, what is the Agile manifesto?

Jon Kern:

Well, it's something that if you weren't around, and I know you're young, so you weren't around 21 years ago, I guess now, to maybe understand the landscape of what software development process and tooling and what most of us were facing back then, it might seem like a really obvious set of really simple values. Who could think that there's anything wrong with what we put into the manifesto? But back in the day, there were, what I practiced under as a... I'm an aerospace engineer, so I was in defense department work doing things like fighter simulation, F-14 flat spins and working with a centrifuge and cool stuff like that. And subject to a mill standard specification, which makes sense for probably weapons systems, and aircraft manufacturing, and all sorts of other things. But they had one, lo and behold, for software development. And so there was a very large, what I would call heavy handedness around software development process. We call it heavyweight process. Waterfall was the common term back then, and probably still used today.

And there were plenty of, I would say the marketing juggernaut of the day, IBM and Rational unified process, these large, very much like Safe. Where it's a really large body of work, awesome amount of information in it, but very heavy process even though everything would, say you tailor it, it could be whatever you wanted. I mapped my own lightweight process into REP for example. Sure. But the reality was we were facing kind of the marketplace leader being heavyweight process that was just soul crushing, and from my perspective, wasting taxpayers' money. That was kind of my angle was, well, I'm a taxpayer, I'm not going to just do this stupid process for process sake. That has to have some value, has to be pragmatic. So lo and behold, there were a handful of us, 17 that ended up there, but there are a handful of us that practiced more lightweight methods. So the manifesto was really an opportunity for coming together and discovering some of the, what you might think of as the commonality between many different lightweight practices. There was the XP contingent. I first learned about Scrum there, for example. Arie van Bennekum, a good friend, he taught us about DSDM. I don't even remember what it stands for anymore. It was a European thing.

Alistair and Jim Highsmith, they had, I forget, like crystal methodologies. So there was a fair amount of other processes that did not have the marketing arm that erupted, or didn't have the mill standard. So it was really all about what could we find amongst ourselves that was some sort of common theme about all these lightweight processes. So it was all about discovering that, really.

Amaar Iftikhar:

You all get together, the principles kind of come to fruition, and let's fast forward a little bit. What was the initial reaction to the original manifesto?

Jon Kern:

Yeah, it was even kind of funny that the four values, the four bullets is as simple as it was. The principles came a bit later. I want to say we collaborated over awards wiki, but the original... If you go to Agile uprising, you can see I uploaded some artifacts, because apparently I'm a pack rat. And I had the original documents that Alistair probably printed out, because he was the one... He and Jim lived there near Salt Lake City. So it was like, "Hey, let's come here." And we like to go skiing, so let's do it here. So he arranged the room and everything. And so there's some funny artifacts that you can find. And the way that it actually came about was an initial introduction of each of us about our methods. And really I think a key, we left our egos at the door. I mean I was a younger one. Uncle Bob, some of these, he was at Luminar, I know I have magazines still in the barn that he was either the editor of, or authors of for people who don't remember what magazines are. Small little booklets that came out. So Uncle Bob was like, Ooh, wow, this is pretty cool.

And I wasn't shy because I had a lot of experience with heavyweight methods. So I really wanted to weigh in on... Because I had published my own lightweight method a few years earlier. So I had a lot of opinions on how to avoid the challenges of big heavyweight process. So the culmination as we were going out the door and after we had come up with the four values was I think Ward said, "Sir, want me to put this on the web?" And again, this is 2001 so dot com and the web's still kind of new so to speak. And we're all like, yeah, sure, why not? What the hell, can't hurt. We got something, might as well publish it. I don't think to a person, anybody said, "Oh yeah, this is going to set the world on fire because we're so awesome." And we were going to anoint the world with all of this wonderful wisdom. So I don't think anybody was thinking that that much would happen.

Amaar Iftikhar:

Yeah. So what were you thinking at that time? So how would the principles that you had come up with together, was that maybe just for the team to take away? Everyone who was there? What was the plan at that time?

Jon Kern:

I think it was a common practice. Like I said, there were other groups that would often meet and have little consortiums or little gatherings and then publish something. So I think it was just, oh yeah, that's a normal thing to do is you spent some time together and you wrote things down, you might as well publish it. So I think it wasn't any deeper than that other than Bob, I think Bob might say that he wanted to come up with some kind of a manifesto of sorts or some kind of a document because that's I think what those sort of... I was never at one of those gatherings, but you know, you could see that they did publish things. I have a feeling it was just something as innocent as, well we talked, wrote some things down, might as well share it.

And then the principles, there were a lot of different practices in the room. So some of what I would say the beauty of even the values page is the humility at the top is it's still active voice. We are uncovering not, hey all peasants, we figured it all out. No, we're still uncovering it. And the other thing is by doing it, because I'm still an active coder. And plus we value this more on the left, more than on the right. Some people might say it's a little ambiguous or a little fuzzy, but that's also a sign of humility and that it's not A or B. And it really is fuzzy, and you need to understand your context enough to apply these things. So from a defense department contracting point of view, certainly three of the four bullets were really important to me because I learned... Sure, we did defense department contracting. But it's way more important to develop a rapport with the customer than it is... Because by the time you get to the contract you've already lost, which goes along with developing a rapport with the customer, the individual.

And one of Peter Codes, when we worked with customers and whatnot, one of our mantras was frequent tangible working results, AKA working software. You can draw a lot and you can do use cases for nine months, but if you don't have anything running, it's pretty, I would guess risky that you don't have anything, no working software yet. So it really was I think an opportunity to share the fact that some people thought two weeks and other people thought a month. Even some of the print principles had a pretty good wide ranging flexibility so to speak. That I think is really important to note.

Amaar Iftikhar:

Yeah, no, absolutely. And it makes sense. Did you or anyone else in the room at that time ever imagine what the impact downstream would be of the work that was being done there?

Jon Kern:

Not that I'm aware of. I certainly did not. I remember a couple times in my career walking in and seeing some diagrams when I worked with the company Together Soft, and we'd build some cool stuff and I'd see people having some of the... Oh yeah, there's a diagram I remember making on their wall. That's kind of cool. But nothing near how humbling and sort of satisfying it is. Especially I would say when I'm in India or Columbia or Greece, it almost seems maybe they're more willing to be emotional about it. But people are, it's almost like they were freed by this document. And in some sense this is a really, really tiny saying it with the most humility possible. A little bit like the Declaration of Independence, and the fact that a handful of people... And the constitution of the United States. A handful of people met in a moment of time, never to be repeated again and created something that was dropped on the world so to speak, that unleashed, unleashed a tremendous amount of individual freedom and confidence to do things. And I think in a very small, similar fashion, that's what the manifesto did.

Amaar Iftikhar:

As you mentioned, there was a point in time when the manifesto was developed and that was almost over 20 years ago. So now the way of working, and the world of working has drastically changed. So what are your thoughts on that? Do you see another version coming? Do you think there are certain updates that need to be made? Do you think it's kind of a timeless document? I'd love to hear your thoughts on that.

Jon Kern:

Yeah, that's a good question. I personally think it's timeless and I welcome other people to create different documents. And they have. Alistair has The Heart of Agile, Josh Kerievsky's got Modern Agile.

There's a few variations of a theme and different things to reflect upon, which I think is great. Because I do believe, unlike the US Constitution, which built in a mechanism to amend itself, we didn't need that. And I believe it captured the essence of how humans work together to produce something of value. Mostly software, because that's what we came to practice from, is the software experience. But it doesn't take a lot of imagination to replace the word software with product or something like that and still apply much of the values that are there with very, very minor maybe adjustments because frequent tangible working results.

There might have to be models, because you're not going to build a skyscraper and tear it down and say, "Oh, that wasn't quite right," and build it again. But nonetheless, there are variations of how you can show some frequent results. So I think by and large it's timeless. And I would challenge anybody. What's wrong with it? Point out something that's somehow not true 20 years later. And I think that's the genius behind it was we stumbled on... And probably because most of us were object modelers, that's one of the things we're really good at, is distilling the essence of a system into the most critical pieces. That's kind of what modeling is all about. And so I think somehow innately, we got down to the core bits that make up what it is to produce software with people, process and tools. And we wrote it down. That's why I think it's timeless.

Amaar Iftikhar:

Yeah, no absolutely. I think that was a really good explanation about why it's timeless. I think one of the principles that comes to mind in a kind of modern hybrid or flexible working arrangement is one of the principles talks about the importance of face to face conversations. And in a world now where a lot of conversations aren't happening physically face to face, they might be happening on Zoom. Do you think that still applies?

Jon Kern:

Yeah, I think what we're finding out with... Remote was literally remote, so to speak, back 20 years ago. I was working with a team of developers in Russia and we had established enough trust and physical... I would travel there every month. So kind of established enough of a team, and enough trust in the communication that we could do ultimately some asynchronous work because different time zones. And me being in the east coast. 7:00 AM in the US was maybe 3:00 PM in Russia if I recall. St. Petersburg. So we were able to overcome the distance, but it's hard to beat real life. And I would often sometimes even spar a little bit with Ron Jeffries that on the one hand you could say the best that you can do is in person. But on the other hand, I could argue a little bit of some of the remoteness makes things... You have to be a little more verbose, possibly a little more precise, but also a little more verbose. A little more relaxed with... You might take a couple of passes to get something just because, I mean there are two time zones passing in the night. But that was based off of some often initial face to face meetings, and then you could go remote and still be successful and highly effective.

So I think it's important that teams don't just say that they can still do everything. And zoom is way better than 20 years ago, admittedly. Zoom gets, at least you can see a face. But nothing replaces the human contact. And I think also for wellbeing, I think human contact is important. So I would still say that the interaction aspect in the manifesto is still best served with a healthy dose of in-person. And that's kind of the key about most things in Agile. It's to me it's about pragmatism, and not just being dogmatic but rather, what might work better for us? And even experimenting with try something a little bit and see how that works. So even how you treat the manifesto, you should treat it in an Agile manner so to speak.

Amaar Iftikhar:

Yeah, no absolutely. That's a great point. On that note, as an Agile consultant or the Agile guy, what have you seen are the best practices or what works, what doesn't work for distributed teams?

Jon Kern:

Well I think the things that are most challenging that I've run across big companies and even smaller ones is that... I don't know if it's natural, God forbid if it's natural, but tendencies that I've seen in some companies to set up silos where you're the quality control, you're the UX, you're the front end, you're the back end, makes my headwater explode. Because that's building in a lag and building in communication roadblocks and building in cooperation which is handed offs from silo to silo, versus collaboration. So I've seen more of that. And I get it, you might want to have a specialty, but customer doesn't care. Customer wants something out the door. If I showed up and I'm going to pull a feature off the stack, what do you mean I can only do part of it? I don't get that. And yeah, I know I'm not an expert in everything but we probably have an expert that we can figure out what the pattern is. So I find that sort of trend, I don't know if it's a trend, but I find that's a step backwards in my opinion. And it's better to try to be more cross-functional, collaborative, everybody trying to work to get the feature out the door, not just trying to do your little part.

Amaar Iftikhar:

Yeah, a hundred percent. I think knocking on silos is a big part of being agile, or even being digital for that matter. And often the remedies for it too are there at hand, but it's a lot harder to actually be practical with it, to actually implement it in an organization, a living, breathing business where there's real people and there's dynamics to deal with, and there's policies and processes to follow. So I guess as generic as you can be, what is your thought as an Agile consultant to a business that's kind of facing that issue?

Jon Kern:

One of the things that... Adaptive is what my colleague John Turley has really opened my eyes to. I tend to call it the secret sauce, or the missing piece to my practice. And it has to do with individual's mindset and what we call vertical development. So it might sound like weird wishy-washy fluffy stuff, but it's actually super critical. And I've always said people, process, and tools for, I want to say since late nineties probably, I mean a long time. And the first I've been able to realize why sometimes I would have just spectacular super high performing teams and other times it'd be just really, really well performing but not always that spark and sometimes kind of like, eh, that was a little meh. And a lot of it comes down to where people lie on in terms of how they make their meaning and what their motivational orientation is, command and control versus autonomy.

So what we do is we've learned that we can help people first off recognize this exists, and help people with what we call developmental practices. Something that, even the phrase, you probably heard it, like safe experiments. Failure, or trying something and failing. Well if you chop someone's head off for it, guess what? They're just going to probably stay pretty still and only do what they're told, not try to... I have a super high dose of autonomy in me, so I've long lived by the, better to beg forgiveness than ask permission, and always felt as long as I'm trying to do the right thing to succeed and do the best for the company, they probably won't fire me if I make a mistake. But not everybody has that amount of freedom in the way they work. So you have to help establish that as management, and that's a big thing that we work with, with teams.

And then we also start with the class. If you've ever watched office space, and if you haven't you should, but the, what is it that you do here? So there's a great, the consultants Bob and Bob coming in, the efficiency consultants, "So Amaar, what is it that you do here?" But literally that's something, whether we're helping teams build a new product, is okay, what's the purpose? What's the business purpose of this product? What is it that you do here? What do you want to do with this product? What value does it provide? Same thing with anything you're working with as a team. And that's why whether it's software, producing some feature that has an outcome that provides value to the customer, or some product. But the point is if you don't understand that, now it's making, the team is going to have a real hard time being able to make decisions which are helping us move forward.

So if you help everybody understand what it is we're here to do, and then try to get the folks that might reflect all the different silos if you're siloed, but all the different elements. How do we go from an idea to cash, so to speak, or idea to value in the customer's hand? And have a good look at that. Because there are so many things that just sort of... Technical data often creeps into software code bases. And the same thing, we sort of say the organizational debt, the same thing can happen. Your process debt. You can just end up with, all right, we want the development team to go faster, John and company, can you come in and help coach us? We want to go agile. Sure, okay yeah. All right. We roll up our sleeves, we look around and after an initial kind of value stream look, like, wait I'm sorry but there's a little tiny wedge, it's about 15%, that's the development. And then you spent the 85% thinking about it.

Let's pretend we could double the speed of development. Which was initially the... Yeah, we need the developers to code faster or something. That's a classic. And no you don't, you need to stop doing all this bullshit up front that's just crazy ass big waterfall project-y stuff with multiple sign-offs. And matter of fact, one of the sign-offs, oh my gosh it only meets once a week, and then if you have a typo in it, you get rejected. You don't come back for another... Are you insane? You spent eight months deciding to do eight weeks worth of work. Sorry, it's not the eight weeks. So things like that, what I recommend anybody self inspect is try to... If you're worried about your team, how you can do better is just start trying to write down what does your process step look like and what is a typical time frame?

How much time are you putting value into the... Because a lot of times people batch things up in sprints. That's a batch, why are you putting things in a batch? Or they have giant issues. Well that's the big batch. So there's lots of often low hanging fruit. But to your point, it's often encrusted in, this is the way we work and nobody feels the ability to change or even to stop and look to see how are we working. So I think that's where we usually start is let's see how you actually work today. And then while we're doing that you can spill your guts, you can tell us all the things that hurt and that are painful and then we'll try to design a better way that we can move towards, in terms of working more effectively. Because our goal is to help teams be able to develop ways to do more meaningful and joyous work, really. Because it's a lot of fun when it's clicking and when you're on a good team and you're putting smiles on the customers' faces, it's hard to almost stay away from work because it's so much fun. But if it's not that, if it's drudgery and you're just a cog in the machine and stuff takes months to get out the door, it's a job. It's not that much fun.

Amaar Iftikhar:

Yeah. A lot of the points that you mentioned there strongly resonated with me, and the common pain points. It sounds like you've kind of seen it all. And by the way if you haven't seen office space, definitely need to watch it. It's a really good one. You've mentioned now a lot about of the element of the challenges that a distributed team faces. Now I want to flip it over and ask you what does the perfect distributed team look like today that lives and breathes agile values?

Jon Kern:

Yeah. I don't know if you can ever have such a thing, a perfect of any kind of team. So I would say harking back to the types of distributed teams that I've worked with, and this goes back to the late nineties. So I've been doing this for a long, long time. Only really done remote, whether it was with developers in Russia or down in North Carolina, or places like that. And I think that the secret was having a combination of in-person... If you want to go somewhere as a group, there are things you can do to break the ice, to establish some, what you might call team building type activities.

And not just, hey let's go do a high ropes course and be scared out of our wits together. But rather also things that are regarding why are we here, what are we trying to achieve? And let's talk about whether it's the product we're trying to build, and take that as an opportunity to coalesce around something and get enough meat on the bone, enough skeletons of what it might look like. Because there's good ways to start up and have a good foundation. And that's part of what I've been practicing for decades. If you get things set up properly with understanding that just enough requirements, understanding... And I do a lot of domain modeling with UML and things like that, just understanding what the problem domain is that we're trying to solve to achieve the goals we're looking for, have a sense of the architecture that we want. So all those things are collaborative efforts.

And so if you have enough of a starting point where you've worked together, you come in and, let's say you even had to go rent someplace, because nobody lived near office, so you all flew somewhere. I mean that's money well spent in my opinion. Because that starts the foundation. If you've broken bread so to speak, or drank some beers, or coded together and did stuff, and then you go back to your remote offices to take the next steps and then realize when you might need to meet again. So that's really important to understand that the value of establishing those relationships early on so that you can talk bluntly. And I have some good folks that I run a production app for firefighters since like 2006.

Amaar Iftikhar:

Yeah, very cool.

Jon Kern:

And that friend that I've worked with, we are so tight that we can... It makes our conversations, we don't have to beat around the bush, we don't have to worry about offending any, we just, boom, cut to the chase. Because we know we're not calling each other's kids ugly. We're just trying to get something done fast.

And building that kind of rapport takes time and effort and working together. And that's what I think a good successful distributed team, you need to come together every so often and build those relationships and know when you might need to come together again if something is a problem. But that I think is a key to success is it shortens the time. Because you may have heard of things like the group forms, if this is performance on the Y axis they form and they're at some performance level, then they need to storm before they get back to normal, and before they start high performing. So it's this form, storm. You get worse when you're storming. And storming means really understanding where we're at. When we argue about, I don't think that should be inheritance, Amaar. And then you're like, "Oh bull crap, it really..."

And again, we're not personal, but we're learning each other's sort of perspectives and we're learning how to have respectful debates and have some arguments, so to speak, to get to the better place. And I've worked in some companies that are afraid to storm, and it feels like you're never high performing.

Everyone's too polite. It's like, come on. And I love when I worked with my Russian colleagues. They didn't give a crap if I was one of the founders. And I'm glad, because I don't want any privilege, I don't want anything like that. No let's duke it out. May the best ideas win. That's where you want to get to. And if you can't get there because you don't have enough of a relationship, and you tend not to say the things that needed to be said because you're being polite, well it's going to take you really long to succeed. And that's a lot of money, and that's a lot of success, and people might leave.

So I think the important thing is if you're remote, that's okay, but sheer remote is a real challenge. And you have to somehow figure out, if you can't get together to learn how to form and storm, and build those bonds face to face, then you need to figure out how to do it over Zoom. Because you need to do it, because if you don't, if you never have words, then trust me, you're still not high performing.

Amaar Iftikhar:

Yeah, I kind of feel like being fully remote now is being offered as almost a competitive advantage to candidates in the marketplace now, because it's a fight for talent. But if I'm understanding correctly, what you are saying is that in-person element is so important to truly be high performing and those ideas kind of contradict each other, I feel.

Jon Kern:

Yeah. And again, having been remote since the late nineties, I've been doing this a long time. And commuting to Russia is the longest commute I ever did, for three years. I mean that's a hell of a long flight to commute there over seven times, or whatever the hell it was. Anyway, I used to say that that being remote is not for everyone, because it really isn't. I mean you have to know how to work without anybody around, and work. I mean it has its own challenges. And yeah, it might be a perk, but I think what you need to do is look at potentially what the perks are and figure out too, can I fold them into... It doesn't have to be all or nothing. And I think that can be a easy mistake to make maybe is to, all right cool, we don't have to have office space. That's a lot of savings for the company. Yeah, but maybe that means you need to have some remote workspaces for occasional gatherings, or figure it out.

But yeah, I think even... And certain businesses might work differently. In the beginning of building a product, I want to have heavy collaboration and I want to get to a point where it's almost, I feel like the product goes like this where once you get things rolling and you kind of get up, get some momentum going, now the hardest thing to do is be in front of an agile team, whether they're in-person or remote. Once things are rolling and rocking and kicking and it's like everything's clicking, you can just bang out features left, like boom, boom, boom. Yeah, okay then we probably need to be...

Unless we've got ways that we're pairing or things like that. I will say when we're together, mobbing is easier. I'm sure there's ways to do it remote, but being in a room, I don't know, it's a lot easier than coordinating over Zoom. You just, hey there's this problem, let's all hang out here after standup because we're just going to mob on this. So it doesn't take a whole lot versus anything remote, there's a little extra, okay, we've got to coordinate, and even different times zones, gets even worse. So yeah, don't get carried away with remote being the end all be all. Because I have a feeling there's going to be a... I would wager there will be a backlash.

Amaar Iftikhar:

And I'll take that back coming from the Agile, the person who does this day to day who helps teams become agile, I'll definitely kind of take your word for it. Plus with my experience too, I've seen nothing really beats a good white-boarding session. That is really hard to replicate online. I mean we have these amazing tools, but nothing quite mimics the real life experience of just having a plain whiteboard and a marker in your hand. That communication is so powerful.

Jon Kern:

Great point. You're so, right, because I had just with the one company that I was with for five years, we were doing high level engineered to order pump manufacturing sales type tool for... So it was my favorite world because it blended my fluid dynamics as an aerospace engineer, plus my love for building SaaS products, and building new software and things like that. And even having a young, we would interview at Lehigh University and we'd have some young graduates that would be working with us, and being able to bring them into the fold, and there was a room behind where my treadmill was and we'd go in there, we'd have jam sessions on modeling and building out new features. And man, you're right. Just that visceral three dimensional experience. Yeah, Miro's great. Or any other kind of tool, but yeah, it's not the same. You're absolutely right. That's a great point. You're almost making me pine for the good old days. [inaudible 00:42:04]

Amaar Iftikhar:

I think the good old days very much still exist. I think even now, it's kind of been a refreshing time for me to be with Easy Agile. I've only been here for just under two months now. And there's a strong in-person dynamic. And again, it's optional, where if people are remote or they're hybrid or they need to commute once in a while, it's a very understanding environment. But once you're in the office or you're in person, you kind of feel the effect you were describing, you're motivated to deliver for the end customer. You just want to come back. It's an addictive feeling of, I want to be back in person and I want to collaborate in real time in person.

Jon Kern:

That's beautifully said, because that's... One of the companies that we're beginning to engage with in South Africa, they're at this very crossroad of struggling with, everybody's been remote, but boy, the couple times we were together, got so much done. And you're describing the flame of, the warmth of delivering and let the moths come to the flame. I mean nurture it and then fan the flames of the good and let people opt in and enjoy it. And still sometimes, yeah, I got to say home, I got the kids or the dog, that's okay too. But giving the option I think is where we're going to head. And I believe the companies that are able to build that hybrid culture of accepting both, and neither mandating one nor the other, but building such a high performing team that basically encourages people to opt into the things that make the most sense at that time. And I think that those companies will rule the day, so to speak.

Amaar Iftikhar:

Yeah, absolutely. It's been so nice to chat with you John, and I've really enjoyed this. I want to leave the audience off with one piece of advice for distributed agile teams from you. We've talked a lot about the importance of in-person collaboration. We've talked about the principles of the agile manifesto. Now, what would the one piece of advice be when you're thinking of both? When you want the agile manifestos to be something that's living and breathing in distributed agile teams, what one piece of advice can you give businesses today right now who are going through the common struggles? What can you tell them as that last piece of advice?

Jon Kern:

Well, I think kind of a one phrase that I like to use to capture the manifesto is, "Mind the gap." In my sort of play on words, what I mean is the gap in time between taking an action and getting a response. Whether it's what do we do about the office, what do we do about remote, what do we do about this feature, what do we do about this line of code? The gap in time is, it's sort of a metaphor about being humble enough to treat things as a hypothesis. So don't be so damn sure of yourself one way or the other about the office or remote or distributed. But instead, treat things as a hypothesis. Be curious and experiment safely with different ways and see what works. And don't be afraid of change. It's not a life sentence to, you got to run your business or your project or your team one way for the rest of your life. No. Don't tell the boss, but work is subsidized learning. I never understood people who just keep doing the same thing because they weren't given permission. Just try it. So that's what my departing phrase would be regarding making those decisions. Mind the gap and really be humble about making assumptions, and test your hypotheses, and shorten the gap in time between taking actions and seeing a reaction.

Amaar Iftikhar:

Oh, that's awesome. Thank you. I really wish we could let the tape roll and just keep talking about this for a couple more hours, but we'll end it right there on that really good piece of advice that you've left the audience off with. Jon, thank you again for being on the podcast. And we've really, really enjoyed hearing you and learning from your experiences.

Jon Kern:

Oh, my pleasure. Any time. Happy to talk another couple hours, but maybe after some beers.

Amaar Iftikhar:

Yeah.

Jon Kern:

Except it's your morning, my evening. I'm going to have to work on that.

Amaar Iftikhar:

Yeah.

Jon Kern:

My pleasure, Amaar.

"Having gone through a cloud migration at Splunk, Greg share's some insightful key learnings, challenges and opportunities" - Chloe Hall

Greg Warner has been involved with the Atlassian ecosystem since 2006 and is a frequent speaker at Atlassian events. Greg has worked as a senior consultant for a solution partner, supported Jira and Confluence at Amazon, and in his current role at Splunk, executed a cloud migration to Atlassian Enterprise Cloud for over 10,000 of his colleagues.

In this episode, Greg and Chloe discuss the cloud migration journey:

📌 The mental shift to cloud migration and how to think beyond the technical side

📌 How to navigate the journey without a roadmap to follow

📌 The four pillars to success for your cloud migration journey

📌 Finding the right time to migrate & thinking about future opportunities    beyond your migration

📌 The unexpected value that can come from a cloud migration

+ more!

📲 Subscribe/Listen on your favourite podcasting app.

Thanks, Greg and Chloe!

Transcript

Chloe Hall:

Hey everyone and welcome back to the Easy Agile Podcast. So I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. So before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodiwodi people of the Dharawal-speaking nation and pay our respects to elders past, present, and emerging. We extend that same respect to all Aboriginal and to Australia Islander peoples who are tuning in today.

Chloe Hall:

So we have a very exciting guest on the podcast today. This guest has been involved with the Atlassian ecosystem since 2006 and is a frequent speaker at Atlassian events. He has worked as a senior consultant for a solution partner, supported Jira and Confluence at Amazon and at his current role at Splunk, executed a cloud migration to Atlassian Enterprise Cloud for over 10,000 colleagues. So welcome to the Easy Agile podcast, Greg Warner.

Chloe Hall:

How are you?

Greg Warner:

Good, and thank you for having me.

Chloe Hall:

No worries. It's great to have you here today.

Greg Warner:

This is one of my favorite topics. We talk about cloud migration and yeah, I hope I can explain why.

Chloe Hall:

Yes, that's exactly what we want for you because I remember when we met at Team 22, you were just so passionate about cloud migration and had so many insights to share and I was very intrigued as well.

Greg Warner:

To give it a bit background about myself.

Chloe Hall:

Yeah.

Greg Warner:

I haven't always been a cloud person. So you mentioned before about being involved since 2006. I was involved early days with when Jira had the several different flavors of standard and professional, when you'd order an enterprise license for Atlassian and they'd send you a shirt. That was one of the difference between one of the licenses. So based a lot in the server versions, over many years. I looked at the cloud as being the poorer cousin, if you like.

Greg Warner:

I'd been to several Atlassian summits and later Team events where there was always things of what was happening in cloud but not necessarily server. I participated in writing exam questions for Atlassian certification program for both server and DC. For me, in the last 18 months, two years now, to make this fundamental shift from being certainly a proponent of what we do doing on server in DC to now absolutely cloud first and that is the definite direction that we as a company have chosen and certainly why I'm so passionate about speaking to other enterprise customers about their cloud migration journey.

Chloe Hall:

Wow. So what do you think it was that you were like, okay, let's migrate to the cloud, as you were so involved in the server DC part of it? What was it that grabbed your attention?

Greg Warner:

I joined Splunk in 2019 and it wasn't all roses in regards to how we maintained Jira and Confluence. It wasn't uncommon to have outages that would last hours. For two systems that were just so critical to our business operations to have that, I was kind of dumbfounded but I thought, hey, I've been here before. I have seen this. And so it was a slow methodical approach to root cause our problems, get us to a version that was in long-term support, and then take a breather.

Greg Warner:

Once we got to that point where we didn't have outages, we kind of think of what the future would be. And for me, that future was exactly what I'd done before, what I'd done at Amazon, which is where we would move all of our on-prem infrastructure, Jira, Confluence, and Crowd to public cloud, whether it would be a AWS or GCP, something of that flavor. I'd done that before. I knew how we were going to do that to the extent that I'd even held meetings in my team about how we were going to stand up the infrastructure, what the design was going to be.

Greg Warner:

But there was probably one pivotal conversation that was with our CIO and it was in one of those, just passing by, and he's like, "Greg, I've seen the plans and the funding requests." He's like, "But have you considered Atlassian Cloud?" Now, the immediate personal reaction to me was like, we are not going to do that because I'd seen the iterations. I'd seen it over time. I'd worked for a solution partner. I'd worked with customers in cloud, never really thought we could be enterprise-ready. So my immediate reaction was not going to do that. I said, "I'm not going to answer that question right now." I said, "I don't know enough to give you an answer."

Greg Warner:

And I'm absolutely glad I did that because I would've put a foot in mu mouth had I given the immediate response that was... So yeah, I took that question, went and did some analysis, spoke to our technical account manager at the time, and really looked at what had been going on and where was cloud today? Where was it in its maturity? And the actual monumental thing for me was that I think it's actually ready. People make excuses for why they can't do it, but there are a bunch of reasons why you should. And if we look at us as a company, with our own products that we are moving our own customers to cloud, and we are using cloud services, like Google Workspace and Zoom and a variety of SaaS applications. What was so different about what we did in engineering that couldn't go to cloud? And that was like, okay, I think the CIO was actually asking me a much bigger question here.

Greg Warner:

So the result of that was yes, we decided that it was the right time for Splunk to move. And that is a monumental shift. And I know there's a lot of Jira admins out there that are like, if you do this, you're putting your own jobs at risk. The answer is no, you're not. And even within my team, when we had we'd discussed this, there was emotional connection to maintaining on-premise infrastructure and were we giving our own jobs away if we do this? There's all those... No.

Greg Warner:

And there have actually been two people in my team that got actually promoted through the work of our cloud migration that otherwise wouldn't have because they could demonstrate the skills. But that's kind of like the backstory about how we decided to go to cloud. And I think as we are thinking about it, there is a mental shift first. Before you even go down the technical path about how you would do it, change your own mind so that it's open so that you're ready for it as well.

Chloe Hall:

Yeah, I love that. It's so good. And I think just the fact that you didn't respond to your CIO, did you say that?

Greg Warner:

Yep.

Chloe Hall:

That you didn't respond to your CIO straight away and you weren't like, "No, I don't want to do that." You actually stepped away, took that time to do your research, and think maybe cloud is the better option for Splunk, which is just so great and really created that mental shift in yourself. So when you say that your employees, like everyone kind of has that beef that, oh, we're going to lose our job if we move from on-prem to cloud and those employees ended up getting promoted. How did their roles change?

Greg Warner:

When we moved from on-prem to cloud, you no longer have to maintain the plumbing, right?

Chloe Hall:

Yeah.

Greg Warner:

You no longer have to maintain all the plumbing that's supporting Jira, Confluence, BitBucket, whatever is going to move. Now we thought that was the piece that's actually providing value to the organization. And it wasn't until we went to cloud, we actually realized it wasn't. Like what we can do now is different. And that's what my team has done. They've up-leveled.

Greg Warner:

So in the times since we moved from Jira, Confluence on-prem to cloud, we now get involved a lot more with the business analysis and understanding what our project teams want. So when someone from engineering is requesting something that has an integration or a workflow, we've got more time to spend on that than are we going to upgrade? Are we on the current feature release? Is there a bug we have to close? Log for J as a prime example where the extent of where we covered was logging a call with the Atlassian enterprise support and then telling us, "Yep, it's done."

Greg Warner:

Whereas other colleagues within the ecosystem that I spoke to spent a week dealing with that, right? Dealing with patching and upgrades. So the value for our team in the work we do has shifted up. We've also done Jira advanced roadmaps in that time. So we've been able to provide things we would've never got to because we're too busy to the plumbing, to the extent now that we have a very small footprint of on-prem that remains and that's primarily FedRAMP and IO5. It's not quite certified yet. It's going to get there. So we have a very small footprint and I'm the one who has to do the upgrades and now you look at it like, oh my god, that's going to be this couple-week tasks we going to do where I could do all this other better work that's waiting for us in cloud. You don't realize it until you have it removed how much you used to do.

Greg Warner:

And so we used to do two upgrades of Jira year and two upgrades of Confluence a year. We put that down to about a month's work of each. By the time you do all of your testing and you're staging and then do that. So you're really looking at four months of the year you were spending doing upgrades. We don't have that anymore. It's completely gone. And so now we make sure that we do things cloud first. We don't bring across behaviors that we were doing on-prem into cloud. So that's probably one thing we learned was that don't implement server DC in cloud.

Chloe Hall:

Yeah, that's so great. It seems like it's opened up a lot more opportunity for you as well. So I think something that I kind of want to look into and understand a bit more is that people focus a lot on the technical aspect of the cloud migration. What other aspects do you think need to be considered?

Greg Warner:

Certainly people. I mentioned at the very front here the mental mindset and that really started with my team, to get their mind around how we're going to do this cloud migration. There isn't necessarily yet a roadmap that says these are all the steps need to take to get ready for your cloud migration. So we had to invent some of those and one of those two was, what did we want to get out of the cloud migration?

Greg Warner:

I speak to other Atlassian customers. You talk about they're running a project, the project is the cloud migration, the start and the end is the cloud migration day. No, completely wrong. The cloud migration actually has a beginning, a middle, and an end. What you're talking about here, about this first changes is in the beginning, and that should be we're moving to cloud because it should be fundamentally better than what we have today.

Greg Warner:

If it's not better, there's no value in doing the activity. So we started with a vision and that vision was that all of the core things had to work from day one and they had to work better. So create issue, edit issue, up to issue, that just needs to work. There should be no argument whether it does or does not. That needs to work and work better. Create a page, edit a page, share a page. That stuff needs to work in Confluence without any problems. We also need to make sure that there are people in the organization who this could be a fundamental change of how they work, depending on how much they work with Jira and Confluence. So appreciating that there is some change management and some communications that needs to be ready as you do your cloud migration to ensure that your vision is going to work, but also acknowledging you will break some things. You're not going to be able to do a cloud migration and shift you from A to B without nothing.

Greg Warner:

It will go wrong. So we were aware of that and for that, what I would always tell people was that we're really fixed on the vision of making it sure it's better than it was today, but flexible on the details, how we get there. We will probably find different ways as we go along because things will change. Cloud changes itself. You'll discover things you didn't know before. There was a Jira admin that made a decision 10 years ago, you now found that. So yeah, very, very fixed on that vision that day one that we had to have this unboxing experience that when people got to use Jira and Conference Cloud for the first time, they could see why we'd spent so much effort to make sure it was polished and things just worked. And as you went a bit further out, there might be things to do with apps that might not be quite the same.

Greg Warner:

That's okay. And then further out, things you just ultimately can't control. And for that, we had 76 integrations of teams that had written automations from all over the company. We're never going to get to find out what they do, but we knew that some of those would probably break. And so just dealing with some change control and allowing those people to know this is coming, what the rest endpoints will be, how to set up their API keys. We did a lot of that, but we did have one integration that broke and that integration broke because the entire team was on PTO or leave that week. We can't avoid that one. But it was good to see other teams actually jumped in because they'd been involved in updating theirs to go help fix that. So that was okay. We had one integration that we really gave the white glove support to and that was for... We have a Salesforce to Jira integration that's a revenue-generating integration.

Greg Warner:

We gave that a lot of attention to make sure that just worked. But the 76 others, we provided a runbook. The runbook was essentially teams, you do things like this. So they knew how to change and update to the new system. But yeah, certainly the beginning, middle and end. The beginning is all those shifts that you're going to have to change and probably some history about design decisions. The middle is in fact your cloud migration and the end, middle to the end is everything you do with it afterwards. So that's where the real value comes from in your cloud migration. It's once you're in, what can we do with it?

Greg Warner:

And we are towards the end of that now. There have been things that I couldn't have planned for that people have done. So we did your advanced roadmaps, saving the forest there, but also we're encouraging our staff to extend the platform. That used to be really difficult and we've worked with Atlassian to understand what should that look like? And we've settled on using it Atlassian Forge. And so now we have our first app this week, in UAT, in Atlassian Cloud to solve business problems that we have. That's a custom Atlassian Forge app. And we're encouraging our engineers to build those and so they can extend and get that real value through the cloud migration.

Chloe Hall:

Yeah, wow. You've come so far and it's nice to hear that you're towards the end of it and all the opportunities are coming with it and you're seeing all the value. It's all paying off as well. I think I just want to go back to that moment where you talk about there isn't essentially a roadmap outlay. There isn't someone or something to follow where it says this is where you need to start. These are the steps to cloud migration. And I think a lot of people, that's what they fear. They're like, we're not sure exactly where to start. We're not sure what roadmap we'll follow. How do you navigate that in a way?

Greg Warner:

So I get back to that when I talked about the vision. We said we're fixing the vision flexible details. Early on when we signed for cloud migration, it was in the first week after we'd signed for it, that same CIO asked me, "Greg, what's our date? When are we moving? Because you've sold me that this is so much better. Where's the action? When are we get this?" And we took a good six weeks after we signed to actually understand the tooling that's available. So for Jira, there's really two options. There's the Jira site import and the Jira cloud migration assistant. And on Confluence side, there's one that's called the Confluence cloud migration assistant. Better kind of understand how those technologies work. And for a couple weeks there, my team actually considered if we did the migration ourself, we could probably save the company a bunch of money and we would own it.

Greg Warner:

We would know how this thing worked. We got about four weeks in and decided that was a terrible idea. Do not do that. Any enterprise customers I talk about that say we're going to do it ourselves, do not do that. Do not do that. And part of the reason is that there's really four pillars to success for your cloud migration. Jira migration, Confluence migration, apps, and users. And we did not know how to do apps and users and we probably could have gotten away with Confluence and Jira. But we said, look, this is something that we actually need to have a partner involved. And so we did ask for partners to provide their way of doing it, knowing what they knew about us. And we did provide as much detail as we can. We had two partners actually provided completely different methodologies how to get there.

Greg Warner:

So this is that flexible on the details, but we really had to make a decision on what worked for us. So when it really came down to Jira, would we do a big bang approach and just switch it over in the course of a weekend or did we want to do cohort by cohort over time? And we decided for us, because we are a 24/7 organization that's supporting our customers, doing the big bang switchover, that was the best way to do it. So that's one of the reasons we chose the partner we did. But that partner didn't necessarily have a roadmap of where they want to go. But we did then explain what we want to get out of this. That was the first thing, was about it needs to happen on a weekend. So that then filters down what your choices are. The ecosystem apps part is really important to make sure that one, there may have been apps installed in your system that have been there for 10 years and you're not sure why they're there anymore because it was four Jira admins ago.

Greg Warner:

Nobody knows what's there. But if they don't have a cloud migration pathway, you really should consider they're probably going to hit their end because there is no equivalent. So you can rule them out. Identify the ones that do have a business process with them. And for that, Salesforce for us, we had to find a cloud-first connect that would work. So that meant that we knew that was going forward. But really, I think the key thing that we invented that we didn't know about was that we created this thing called an App Burn Down. And that's where we looked at all the apps we had. We had about 40 apps. We said, okay, which ones are not going to go to cloud? Which ones don't have a migration pathway? Which ones are going to replace something else? And so we started to remove apps over the course of about three months.

Greg Warner:

So people would see that we're starting to get away from on-prem design decisions and old ways of doing things. But we also said, but once we get to cloud, this is the pathway out of it. So that we said, look, we're going to turn this app off but you're going to get this one instead, which is the cloud-first app. So people could see how we're going to make the jump over the river to get there. But it meant that we would, over time, identify apps that weren't used. If we turned them off and nothing happened, it's fine. But also we did come across some where they were critical to a business use. And so if we didn't have an answer for those yet, it gave us time to find one. And with your user base, typically it's your colleagues, that's going to be your most critical customers. They're going to ask, okay, you're turning it off. When do I get the functionality back?

Greg Warner:

And by doing that App Burn Down over time, that does buy you time to then have that answer. So it's a much easier conversation than I'm simply turning off functionality, I don't have an answer for you yet. There are things like that. It wasn't necessarily a roadmap, but working with a solution partner is absolutely the right way to go. Don't try and do it yourself. They also work with Atlassian and they have far better reach into getting some of these answers than you can possibly ever have. And I have on at least three different occasions where our solution partner did go and speak directly with an ecosystem partner to find out what's the path forward. How can we make this work? So it is good. The migration is really a three-way collaboration between yourself, your solution partner, and Atlassian. And you all have the same goals. You want to get to cloud and it does work really well.

Chloe Hall:

Wow. Yeah. So sounds like hope everyone got that advice. Definitely don't take this on your own. Reach out to solution partner. And I really like how you said you went to two different solution partners and you found out what their ideas were, which ways they wanted to take you, so you could kind of explore your options, work out what was the best route for Splunk. And it's worked very well for you as well. Having that support I think as well. Yeah. Sorry, you go.

Greg Warner:

The choice of the partner is really important and it's probably one of the earliest decisions that we made to get that one right. And I remember several times thinking about, have we got the right people on board? Did we speak to... And it was an interview process to the extent that when we had our final day after we'd been working with Atlassian and with our partner for six months, one month after our migration was completed and we're all done, we had one final Zoom call with all of us and took a photo and did that. But it kind of felt like a breakup, to be honest, because we'd been in each other's faces for six months and working. We're now all saying goodbye. We might not see each other. It was like the weirdest feeling. But it did work. And so yeah, it is a real fundamental choice.

Greg Warner:

Just take the time, make sure they understand what we want to do, make sure you understand how they're going to do it. But yeah, if we have done it ourselves, we would've got ourselves all caught up in knots, wouldn't have been a successful migration or so. I'm a technical guy. I want to solve it. I want to be like... But I think the actual right answer was no, you don't need to know how this works 100% because you're going to do this hopefully just once. And so focus on the real business value things about dealing with stakeholders and the change and making design decisions that are really important for you because you're going to own those probably the next decade rather than worrying about how do I get my data from A to Z?

Chloe Hall:

Yeah. It definitely would've felt like a breakup for you because you would've been working side by side for so long, dealing with so much. Are you still in contact with them or...

Greg Warner:

Yeah, we had this fundamental thing we always said is we're always, if there's a problem, we're always cautiously optimistic, we're going to solve it. We did engineering challenges that we went through, but I did say right early on is, the ecosystem is only big and we're all going to bump into each other at some point. So yeah, let's make sure that we're still friends at the end of this. And I didn't realize how important that was until later when I was in New York for Christmas and I arranged to meet the project manager that worked for us. She lives in New York, so how about I meet you so... So we met each other at the hotel and she's like, "I have never met a customer outside of work to do this." Yeah, I gave the story about it felt like a breakup, but she did say that at the beginning you said we'll be friends after.

Greg Warner:

Yeah it is because it can be really hard. I've been on the consultant side where you kind of have to have some hard conversations and sometimes... You want to make sure that everyone understands the problem. You're trying to make it better so that at the end of it, you can still be friends like that. That is the thing. There probably will be engagements later on that you might need them again. So you want to make sure that you have your choice of best in breed partner to choose from. You have those relationships. They understand what you want to choose. So yeah, it is really important to choose the right partner. Don't necessarily based on price but choose the partner that's going to work for you, understands what you're trying to get out of your cloud migration and they'll be there in the future when you need them for another cloud migration or a much more gnarly project. Try and be friends at the end of it.

Chloe Hall:

And definitely it's good that you have that friendship now because they have that understanding about your business and what you want and the value of it. So if you do need help again, it's a lot easier to bring them on board straight away. So now that you've performed a cloud migration and you're coming towards the end of it, do you look at the process any differently to when you were at the very beginning?

Greg Warner:

Yeah, I thought we were just executing a data migration just yeah, on-prem to cloud.

Chloe Hall:

Yeah.

Greg Warner:

Pretty straightforward, nothing big. I was pleasantly surprised as we're making some of these decisions as we went along, that it was more than that. There were business processes that we could improve. There was the beginning, the middle, and end. I didn't realize that until actually after the end. So when we did our cloud migration, it was actually the week before Thanksgiving in the US. It was November 19. And even that decision was made in just going for a walk at lunchtime. When should we really do this? And I kind of came down again, spoke to my project manager and said, "How about we do this in the cloud migration the week before Thanksgiving?" Because 50% of our workforce is located in the US and a large proportion of that will be on leave or PTO before.

Greg Warner:

So by doing it over a weekend before then we're ensuring that... Like when you open a new restaurant. You don't want to have all of your tables full on the first night. We knew that we were going to have everybody using Jira and Confluence day one after a migration because we're going to break some stuff. They actually turned out to be really exceptionally good idea. And I encouraged people to find... Look at your data and work out when is low time to do this? I've been involved in Jira and Confluence for a long time and just thought it's task tracker and it's a wiki. There's nothing there that I don't really know about. But one of the decisions we made was actually that when we completed the data migration and it was ready to go, I always said if we waited, do we get a better result? And the answer was no.

Greg Warner:

We should make this available to people now. And so we opened it up on a Sunday morning in the US, which was starting to be business hours in Australia. We started making teams aware that they can now go ahead and use Jira and Confluence. And it was the feedback that we immediately got from those teams that were starting to use Jira service management in cloud for the first time, about, "Wow, this is so much better than it was on-prem." And people said, "I can actually see the attention to detail you've made on fields and descriptions and the changes you've made." And it started to impact people's workday that this was better than it was. I didn't expect that to come back. And so I have a montage that we share with the team of all these Slack messages from people saying, "This is really good. This is much better than we had before."

Greg Warner:

What I didn't also realize is that when we moved from on-prem to cloud is the data that we had became more usable and accessible. Hadn't planned that. It seems obvious now, but when we put it in cloud and it has all the security controls around it and now no longer has the requirements of things like VPN to get access to it, people could build new things to use it to be able to interact with your issues, to interact with pages. And so we started with 76 integrations and over space of three months now we had this big jump in the first three months up to about a hundred something and now we're going to Forge And what it means is people who have had this need to be able to get to the data can now get to it. I didn't see that coming. I just thought we were just server cloud. But yeah, having a more accessible has led to improvements in the way that our teams are working but also how they use it in other applications that just simply wasn't available before.

Chloe Hall:

Yeah. Wow. That's great. And it's good that you were able to receive that feedback straight away from the teams that you had in Australia. I think that's really good and it sounds like it's created such a good opportunity for you at Splunk as well now that you're on cloud.

Greg Warner:

Yeah, it's certainly a business leader that can propel you forward and I eagerly come in now and look at what are other teams going to do with it. And so when we had the first team that said they want to build a Forge app, I'm like, Sure. We should not discourage that at all. Extend the platform. That's why we spent the money and time to do it. What can you do with it now? And we did certainly make Atlassian aware on the product side, like how we're using it and where we'd like to see improvements. If you look at the server DC comparison, I used to be that person that would look at the new features in cloud and ask that question about, when is that new feature coming to on-prem? To going to being that customer who's now, I have that feature today, right? And I'm using it because we don't wait for it.

Greg Warner:

So you mentioned about things you didn't plan from the roadmap. There are design decisions that I talk to enterprise customers that I need to make aware of about. One of them is to do with release tracks. In enterprise cloud, you can choose to bunch up the change to cloud and then they get released periodically every two weeks, every month. When I looked at that, came back to one of our principles about don't implement server in cloud, why would we do that? Atlassian has far more data points on whether this works for customers at scale than we do. So why would we hold back functionality? So as a result we don't do release tracks. We let all of the new functionality get delivered to us as Atlassian sees fit. And the result of that is our own engineering staff, our own support staff who use Jira, get the notifications about new products and features and this is fantastic.

Greg Warner:

Again, why would we implement server, which is where you would bunch up all your changes and then go forward? The other thing too about our cloud migration journey is don't be blinked that you're just doing a cloud migration today and then the project ends. There are things you need to be thinking about as you go along, but what's the impact in the future? So for us, we have multiple sites. Enterprise customer have multiple sites. So there are design decisions that we've made so that we can, in the future, do cloud to cloud migration. You will move sites. Your organization could be bought or could be buying companies. So you do mergers and acquisitions. And so as part of that, we have some runbooks now that talk about using the cloud-to-cloud tooling so we can move a Jira project from a site here to a site there, how we'd move users here and users there.

Greg Warner:

And that actually came about through the assistance with our TAM, not focusing just always on the cloud migration date but also what's that look like six months later? What's it look 12 months later? So that you don't perform your cloud migration and then lock yourself in a corner that later on now I have to unwind something. I had the opportunity to fix it. So yeah, I do encourage migration customers to also think six months, 12 months beyond their cloud migration. But what could also happen and then speak to your solution partner about design decisions today that could affect you in the future.

Chloe Hall:

Yeah. So you definitely need to be thinking future-focus when you're doing this cloud migration. I know you've addressed a lot of the opportunities that came out of the cloud migration. Was there anything else that was an unexpected value that came from it that you wanted to share?

Greg Warner:

The other value is make it more accessible. We have seen people use it in different places that we hadn't thought about. So some of the things that we were doing before, we had to have a company-owned asset to get on the VPN and just things like that. That actually restricted people in where they could do work. Whereas now we've, as long as you've got a computer or mobile device connected to the Internet, absolutely you can use a mobile device support, you can get access to it. Approvals that used to be done on a computer are now done on a mobile device. Those things. But I think the integrations has been probably been the one thing I'm most... We're not the catalyst. We kind of pushed it along but seeing people get real use out of it and using the data for other purposes. We have seen people build some microservices that use the data from Jira that we couldn't do before. Again, you're just unlocking that potential by making it more usable and accessible.

Chloe Hall:

After going through the whole migration journey and, like you said, you're coming towards the end of it, what were the things that stood out to you that you're like, okay, they didn't go so well? Maybe if I was to do this again, how would I do this better next time?

Greg Warner:

So I get back to that day one unboxing experience. You know you want to give it that best experience. And we delivered that for people in Australia and APAC as we opened it and they got to use Jira for the first time and it worked fine. And that is mainly the result of a lot of emphasis on the Jira piece because we said, we know this is going to be hard. It's got workflows, issue schemes, notifications schemes. This is going to be hard.

Greg Warner:

So we started that one really early and then probably about 60% down through our migration journey, we started on Confluence. We thought how hard can Confluence be. It's a bunch of spaces and pages. It can't be that hard. We actually hit some migration challenges with the engineering tooling with Confluence, which meant that the Confluence UAT was delayed. The Jira UAT was fantastic. Ran for a month. We found some problems, got fixed, got answers. We were really confident that was going to be fine.

Greg Warner:

And then we hit this Confluence piece. We're like, wow, this is going to be a challenge. And there was at least one time I could think of. It was a Saturday morning at breakfast where our solution partner sent me a Slack message about, I think we've got a problem here with some tooling. What are we going to do? Towards the middle of the day, I was kind of scratching my head. This could be a real blocker. We actually worked with Atlassian, came up with the engineering solution, cleared that out. That was good to see, like in the space of 12 to 24 hours, there was a solution. But what it meant was that it delayed the Confluence UAT and it made a week. And there was something we found to do with the new Confluence editor and third-party apps right at the end of that week. And we had to really negotiate with our stakeholders to make this go ahead.

Greg Warner:

Because again, if we'd waited, we'd get a better result. No, we really should go. We know that there's this problem. It's not system-wide but it affects a small group people. So we did it. But for about a hundred people they have this really bad Confluence experience because of this thing. And so for me, I couldn't deliver on that thing I promised, which was a day one experience that was going to be better than what it had before.

Greg Warner:

Now we did work with Atlassian and app vendors to get some mitigation so it wasn't as bad on day five. It wasn't day one but it wasn't perfect. But I would certainly encourage people to make sure that you do treat Jira and Confluence with as much importance as each other. They do go together. When I did our cloud migration, we did it on a weekend and I remember coming back after dropping my kids at school on Tuesday and sitting in the car park. I was like, wow, we actually pulled that off.

Greg Warner:

If we'd propose to the company to move your company email system and your finance system on a weekend, the answer would be no because it's too big a hat. But what we'd said is we're going to move all of our Atlassian stack in a weekend, which really is two big systems, Jira and Confluence. So if I had the time again, we would've started Confluence much, much earlier and then we wouldn't have the need to rush it at the end. And that really did result in a bad day one experience for those people. We have worked with Atlassian since then. We're getting that resolved. We know other Atlassian guys have the same problem. I would start early and don't underestimate the complexity that could happen. There will be some things outside of your control.

Greg Warner:

I talk about this Confluence problem and the migration tooling, which is actually do at scale. Not every customer will see it. We saw it, I conducted customer interviews when we were doing our solution partner decision and the customer actually told me this. Like I should have started Confluence because we had this problem, we wasted some time, and we did it. I even have my notes. But it wasn't until later, same problem, you even had the answer and they told you and you still waited. So I'm spending a few minutes on this podcast talking about it because it happened to me. It's probably going to happen to the next person. So if I could do one thing and that is just encourage you to start it earlier. You're going to end up with a much, much better migration and hopefully can deliver on that day one experience that I couldn't do.

Chloe Hall:

Yeah, no I'm so glad that you've shared that with the Easy Agile audience as well because now they know and hopefully the same mistake won't keep getting repeated. Well, Greg, my final question for you today, and I don't know if you want that to be your answer, but I think it's really good just for the audience, if there's one key takeaway that they can go away with them today from the podcast, what would be that one piece of advice for everyone listening to start their migration journey?

Greg Warner:

The first thing to do is to prioritize it. So if you're an Atlassian customer that's using on-prem Jira or Confluence and you don't have a timeline and you don't have a priority to your cloud migration, start there. Open up the task, which is start to investigate Atlassian Cloud and choose a date. Because yeah, there will come a situation down the track where you might be asked by your CIO and so it's better to have an answer prepared already. I would encourage people to start to look at it because it is the future. If you look across the industry, people are moving to SaaS. It's really a question. Do you want to maintain and be that customer wondering when that feature's coming to cloud or do you want to be that customer in cloud who has it today? We have seen a monumental shift to when we moved to cloud in functionality, availability, all the good things that cloud delivers. And it's one of the biggest promoter... The person that used to write exam questions for servers now saying go to cloud.

Greg Warner:

Absolutely. So when I've spoken to other enterprise customers, particularly at Team, I said like, when do you plan your cloud migration? I was like, wow, we're going to start it in three years. I'm like, three years? You need to go back to the office next week and start like 12 months because yeah you will... There is absolutely a competitive advantage to doing it. And it's not just me being now as biggest cloud opponents. We see it, we see it every day and for me, this is one of the most influential projects I've been involved in with Atlassian since 2006. This one here is going to have a long-lasting effect at Splunk for a long time and I'm happy to speak to yourself at Easy Agile and others about it and here at their cloud journey because I want to go to Team next year. I want to make sure we have these conversations in the whole way about, I got that one thing. It's either I started my Confluence migration earlier or I actually put in a timeline of when we should start our cloud migrations.

Chloe Hall:

Yeah, beautiful. That is some great advice to take away, Greg. And so honestly, thank you so much for coming on the podcast today. You have provided some brilliant insights, takeaways, and also because there is no roadmap, I feel like your guidance is so good for those who are looking to start their cloud migration. Yeah. We really appreciate you sharing your knowledge.

Greg Warner:

All right. Thanks for having me on. Thank you for listening.

Chloe Hall:

No worries.