No items found.

Easy Agile Podcast Ep.22 The Scaled Agile Framework

Listen on
Subscribe to our newsletter

"Rebecca is an absolute gold mine of knowledge when it comes to SAFe, can't wait to continue the conversation at SAFe Summit 2022!"" - Tenille Hoppo

In this episode, Rebecca and Jasmin are talking:

📌 The value of the Scaled Agile Framework, who it’s for & who would benefit

📌 The Importance of having a common language for organizations to scale effectively

📌 When to connect the Scaled Agile Framework with your agile transformation

📌 Is there ever really an end state?

+ more!

📲 Subscribe/Listen on your favourite podcasting app.

Thanks, Jasmin and Rebecca!

Transcript

Jasmin Iordandis:

Hello, and welcome to the Easy Agile podcast, where today we're chatting all things Scaled Agile with Rebecca Davis, SAFe Fellow, SPCT, principle consultant and member of the SAFe framework team. Rebecca is passionate about teamwork, integrity, communication, and dedication to quality. And she's coached organizations on building competitive market-changing products at scale while also bringing joy to the work, for what is work without joy. Today, we've chatted all things Scaled Agile implementations, challenges, opportunities, and also the idea around optimizing flow, which Rebecca is hosting a workshop at the SAFe Summit in Denver in August this year. Hope you enjoy the podcast.

Jasmin Iordandis:

Hello everyone, and welcome to the Easy Agile podcast. I'm your host Jasmin Lordandis, product marketing manager here at Easy Agile. And today, we are delighted to welcome Rebecca Davis from the Scaled Agile framework. Welcome, Rebecca, and thanks for joining us.

Rebecca Davis:

Thanks. I appreciate being here. I'm excited.

Jasmin Iordandis:

Me too, especially because we are counting down the days before we get to meet you face to face, in person, at the SAFe Summit over in Denver, Colorado. And before we kick off our conversation, I just want to acknowledge the traditional custodians of the land from which we broadcast our podcast today. The people of the Djadjawurrung 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. So before we kick off, Rebecca, can you tell us a little bit about yourself and your role within Scaled Agile?

Rebecca Davis:

Sure. I'm actually relatively new to working for Scaled Agile. So I've been there a little over 90 days now, and I'm a member of the framework team, which means I help actually create the Scaled Agile framework and future versions of it. Prior to that, I led LACE at a company called CVS Health, and I've worked at a bunch of different kind of healthcare organizations across my years implementing or organizing agile transformation and digital transformation. And I think one of the reasons that Scaled Agile was interested in me joining the team is just a lot of different experiences across business agility as a whole outside of technology, in addition to within technology. So marketing transformations and HR transformations, legal transformations. But I love being at Scaled Agile and being part of the framework team. It's really exciting to help more organizations, and just the one I'm at, really understand how to bring joy to their workplace and bring value out to the world.

Jasmin Iordandis:

Yeah, cool. And you've given a little bit of information there around why Scaled Agile was interested in you. What attracted you to Scaled Agile, and did you use the Scaled Agile framework in these previous roles that you've just described?

Rebecca Davis:


Yeah. Those are great questions. I think I'm going to try to answer both of them together. But the reason I have always been drawn to the Scaled Agile framework is I ran a few different organizations, both as owning my own company and then also working in startups and working with larger organizations, where I knew that agility was important. But I was struggling as a change leader to find a way to really bring connectedness across large amounts of people. And to me, that's what Scaled Agile does for us, is after a certain size, it's a lot easier to create this common language and this common way to move forward and produce value with the framework. I also really enjoy it because there's a lot of thought that's already kind of done for you.

Rebecca Davis:

So if you're in an organization and you're trying to create change or change leadership, I'd much rather be leading the conversations and my context and making sure that I have a pulse on my particular cultural environment and pull from all these pieces, from the framework, where the thought's already been done about what are the right words and what do we do next, and what's the next step. So I've just found it an invaluable toolkit as a change leader.

Rebecca Davis:

I joined the framework team for a few reasons. One, I'd led so much change in so many different areas that, it's not that I wasn't challenged anymore, but I was really looking for something larger and different, and I've always had a belief that I really want to be the change that I want to see in the world. And I think being part of the framework team gives me access to things like this and all over the world to really help connect the humanness of people alongside with all the great techniques that we've learned, and hopefully expand it and just create a better place to be in.

Jasmin Iordandis:

Yeah. Cool. And you kind of touched on that in your response, but if we had to say, who is the Scaled Agile framework for and who would it most benefit, what would you say to that?

Rebecca Davis:

Yeah. I guess my opinion on that is I believe the Scaled Agile framework is for people who believe that their organizations have it in them to be better, both internally inside of themselves, as well as have this gigantic potential to go help the customers they serve and may be struggling right now, to really realize that potential. So I don't really see the framework as it's for a specific role necessarily. I think it's for people who believe in betterness. And those people, I found, live across an organization and across multiple different roles, and the framework just really helps you align that.

Jasmin Iordandis:

Yeah. And I think one thing that's evident from SAFe, once you learn how all the different practices and ceremonies work together, is exactly as you've said around connectiveness. And you also touched on having a common language. How important is that, when we're talking really large organizations with multiple different functions who, let's be honest, it's quite common for different functions to fall into different silos and things to break down. So how important is that connectivity and that common language, so that an organization as a whole can scale together?


Rebecca Davis:

Yeah. I don't even know how to state the amount of importance that is. I guess, specifically the organization I just came from, had over 400,000 people that worked there. And the last thing I want to is to debate what the word feature means, because that doesn't actually end up within a conversation where we have an understanding of why we want to feature or why we want this particular outcome, or how this outcome relates to this other outcome, if we're spending so much time just choosing word choice and having a conversation instead about what does the word even mean.

Rebecca Davis:

So I like it mostly because it gives us all this common framework to debate, and we need to be able to do that in really transparent and open ways across all of our different layers. So I don't even know how to quantify how much value it brings just to have this ability to bring stability, and the same language across the board, same word choice, same meaning behind those word choice, so that we can have all those debates that we need to have about what's the best possible thing we could be doing, since everything that we can do is valuable, but some things we have to decide are more valuable than others.

Jasmin Iordandis:

Yeah. And I think that really talks to what you were saying about helping an organization to reach its potential. It sounds like getting bogged down in what you call things or how you discuss things. And to be able to align on a common meaning in the end, you kind of need that common structure or that common language. And you're only going to get in your own way if you don't have it. So it makes total sense that the framework could really enable organizations on that journey. And in your experience, because it's implied in the name, it's about scaling agile. And I guess when we think of the Scaled Agile framework, we think of all those organizations of such a large size as the one you just mentioned, 400,000 employees. In your experience, what's a good time to introduce the Scaled Agile framework? Does it need to be right from the beginning? Does it need to be those organizations that are 400,000 people strong? Where is the right time to intersect the framework with an agile transformation?

Rebecca Davis:

Yeah. I think that's a really fascinating question, and my answer has changed over the years. I originally started researching Scaled Agile, because it was my first big transformation alongside of a large organization, and I knew there had to be some solutions out there to the problems I was seeing, and I discovered SAFe. But thinking back, I started my own startup company right out of high school actually. And I really wish that I would've had something to pull from, that gave me information about lean business cases, and speaking with my customer and getting tests and getting feedback. So I feel like the principles and the practices and the values are something that could be used at any size.

Rebecca Davis:

I think the part about scaling, the part about deciding like, "Hey, I'm going to do PI planning," I don't personally feel like you need to do PI planning if you have four people at your organization, because the point is to get teams across different groups to talk. You should definitely plan things 100%. So I think part of the idea is like, "When do I implement a train," or, "When do I have a solution train," or, "When do I officially call something LPM," versus just having discussions because my company is so small that we can all have discussions about things. I think those are a different part of implementing the Scaled Agile framework than just living and believing in the principles and the values and the mindset from whatever size or get-go you're at. Does that make sense at all?

Jasmin Iordandis:

That does make sense. And I guess then the question becomes, where do you begin and what would the first step be in implementing SAFe? And taking from your own experience, where do you start with this framework?

Rebecca Davis:

Yeah. I love that you asked that, as I've honestly seen this happen to me as well as some other change agents, where Scaled Agile gives us this thing called the implementation roadmap, and it has all the steps that you can start with. And it's proven, and companies use it and it works. And what I've found in my own change leadership is when I skip a step or I don't follow that because I get pressure to launch a train, instead of starting with getting my leaders at the right tipping point or having that executive buy in, it causes me so much pain downstream.

Rebecca Davis:

So if I were to give advice to somebody, it's, "Look, pull that map down the implementation roadmap from the SAFe site and follow it. And keep following it. And if you find that you..." I think that, back when I look back and do my own retrospective, the moments where I've decided to launch a train without training my people or launch or start doing more product management practices without actually training my people, it causes me a world to hurt later on with coaching and with communication, with feedback. So it's there for that reason. Just follow it. It's proven.

Jasmin Iordandis:

Yeah. And that's really good advice. And I think when people look at the roadmap for SAFe, there's a lot on there. But when we are talking agile transformations, necessarily there is going to be a lot that could get you there. So it kind of makes sense when all the thinking is been done for you and all those steps have been done. Just trust the process, I guess, is the message there, and following through on all of that. And I think it's really interesting, because the first step with SAFe is, as you say, getting your leaders on board. And often, we might be attracted to doing the work better. So let's start with those ceremonies. Let's start with all those things that make the day to day work better. How important it starting with the leaders of an organization?

Rebecca Davis:

Yeah. I've run the grassroots SAFe implementations where you start with the bottom and then you kind of move up. And personally, and this is a personal opinion, I'd much rather take the time and the efforts to get the communication right with the leaders and get the full leadership buy-in than be in that place again, where I'm trying to grassroot to move up and I hit the ceiling. The one thing I used to kind of tell the coaches that reported to me, and something I believe in deeply, is what we're trying to do with transformation is a journey. It's not a destination. So because we want to start that journey healthy and with a full pack of food and all those things, we need to take the time to really go and be bold and have conversations with our leaders, get their buy-in to go to Leading SAFe.


Rebecca Davis:

If they're not bought in to coming to a two-day course, then why would we believe that they're going to come to PI plannings and speak the way that we hope they will and create the change that they need to really lead? So I think that's one of the most important things, if not the most important thing from the very beginning, is be bold as that first change leader in your organization, go make those connections.

Rebecca Davis:

It may take a while. I've been in implementations or transformations where it started with just me discovering issues that senior leaders or executives were having, and going and solving some of those, so that there was trust built that I was a problem solver. So I could ask for the one hour executive workshop, which really should be a four to six-hour executive workshop, to get to the point where I could do the four to six-hour executive workshop, to get to the point where I could do PI Leading SAFe. And if that's what it takes to gain you that street cred to go do it, then, man, go do it, because that's where you get full business agility, I think, is getting that really senior buy-in and getting that excitement.

Jasmin Iordandis:

Yeah. That's really interesting. And I think building that level of understanding and building that foundation, we can't go past that. And I guess on that as well, from your experience, you've kind of hinted at one there, but what have been some of the challenges that you've experienced in implementing SAFe or even just in agile transformations more broadly, and as well as some of those opportunities that the framework has helped to unlock? So let's start with the challenges. What's some of the hard things you've experienced about an agile transformation and even implementing the framework?

Rebecca Davis:

Yeah, I'll give some real examples, and this first thing is going to sound a little wishy washy, but I also believe it, is the biggest challenge to transformation is you. So what I've discovered over the years, is I needed to step up. I needed to change. I think it's really easy to be in an organization and say, "My leaders don't get it," or, "Some won't understand," or, "It's been this way and I can't change it." And I think that the first thing you have to decide is that that's not actually acceptable to you as a person. And so you as a person are going to go fight. Not you're going to go try to convince somebody else to fight, but you are going to go fight. So I think that personal accountability is probably the biggest challenge to wake up every single day and say, "I'm going to get back in there."

Rebecca Davis:

I think from an example point of view, I've definitely seen huge challenges when the executive team shifts. So when we've got a set of leaders that we did the tipping point, we've gone through Leading SAFe, we've launched our trains. And then the organization, because every organization is going through a lot of change right now, and people are finding new roles and retiring and all that, there's a whole new set of executive leaders. And I think one of the things to discover there is there are going to be moments where it sucks, but you have to go and restart that implementation roadmap again, and reach that tipping point again, because there are new leaders. And that's hard. It really is, and it drains you a little bit, but you've just got to do it.

Rebecca Davis:


I think other challenges I've run into is there's a point after you've launched the trains and after you have been running for a while, where if you don't pay attention, people will stop learning, because you're not actively saying like, "Here's the next thing to learn. Here's the next new thing to try." So I do think it's the responsibility of a change leader, no matter if you're a LACE leader or not, to pay attention to maintaining excitement, pay attention to the continuous learning culture and really motivate people to get excited about learning and trialing and trying.

Jasmin Iordandis:

Yeah. That's an interesting point. How have you done that?

Rebecca Davis:

Hmm. So I think a few things. One, I had big lessons learned that there's a point inside of a transformation where, as an SPBC or as a change leader, that transformation is not yours anymore. So I had kind of a painful realization at one point that I had in my head the best next thing for the organization, and I was losing pulse of the people who are actually doing the work. So I think what I've discovered after that is, to me, there's a point where your LACE members and your change leaders and your SPCs need to start coming from a lot more areas. And honestly start to be made up of people who are not, at the moment, excited about the SAFe implementation, so you can hear from the pulse of the people.

Rebecca Davis:

And then I think if you can get those people and invite in and say like, "I'm inviting you to share it with me what's frustrating, what's good, what's bad, what's great, as well as I'm inviting you to tell me all the things that you're discovering out there in webcasts or videos that seem you'd like to try them, but we're not trying yet, and start giving back the ability to try new things and try things that you feel are probably going to be anti-patterns, but they need to try them anyway." So kind of a scrum master would do with a team of like, "Yeah, go try and then we'll retrospect." I think you have to do that at scale and let people get excited about owning their own transformation.

Jasmin Iordandis:

And what's the balance there between implementing the framework and taking all the good stuff that the framework says is good to do, and then letting people experiment and try those things, as you say, that may be anti-patents? Where's that sweet spot to allow that autonomy and that flexibility and that experimentation with still maintaining the integrity of the framework?

Rebecca Davis:

So I think the interesting thing is they are not actually different. So in the framework, we say hypothesis first, test first. So what I found is a layered kind of brain path where there're the steps in the framework and make sure we have teams and balance trains and all the principles and the values, and if you can live those principles and values all the time, while you're testing new things. So you test first like, "Hey, I want to try having my train off cadence from the other trains. I think it would be helpful for us." "Cool. Test that." And what we have to test it against is are we still living our principles? Are we still applying our values? Are we still applying the core fundamentals of agility and lean throughout that test and also as proof points?


Rebecca Davis:

So do we have an outcome where," Hey, I just made my train into a silo," or do we have an outcome where, "Well, now we have two different PI plannings within the overall PI cadence that one of them we merge with all the other trains and the other one is shorter because our market cadence is faster." Well, that's a beautiful win. So I think the key is it's not different, but one of the test points is make sure to check in on those principles and values.

Jasmin Iordandis:

Yeah. Have you ever seen that work well? The example that you just provided with the PI cadence, that makes complete sense, and it doesn't seem like it's going against the grain with anything that SAFe is there to help you achieve.

Rebecca Davis:

Yeah, I think that. This was kind of a little bit of what my summit talk was on last year, is during COVID, there were some trains. We had, I don't know, 30 trains. Two of them were having daily new requirements emerging from all the different states across the United States and emerging from the government and emerging from everything. Those trains were making sure everybody could get vaccinated across the United States. That's really darn important. And they needed to re-plan sometimes daily. It just didn't make sense to say, "Now we're just going to stop and go into PI planning for three days," when there wasn't any way that they could even think about what the next day's requirements could be. Since then, they still have a faster market rhythm. Then there are other trains that are working on, have a set unknown. There are trains that know that these holidays are when we need to release something or end of year is when we need to make sure that we've got something ready.

Rebecca Davis:

COVID is still in a reactive state. So what they've emerged into this year is those trains are still doing PI planning from my knowledge, I'm not there anymore, but from my knowledge. But they do eight a year instead of four a year. And four a year are on the same cadence and the other four are not, and it meets both needs. So I do think that key is test, and don't test just for the sake of it just because something feels dry or you get a new leader, and they haven't gone through Leading SAFe, but test because something actually doesn't feel right about, "We're not meeting our principles or values right now. We think that we could meet them better in this way. We think we could accelerate the flow of value in this way. Let's try it."

Jasmin Iordandis:

Yeah, cool. And on that, what are some of the red flags that you've seen in practice where those values aren't being met to be able to say, "Hang on a sec. This isn't working. We need to switch course"?

Rebecca Davis:

Yeah. Some of the things I've seen are the whole fun around when people are prioritizing their hierarchy or their piece of the organization over the enterprise value. So I've definitely seen people come to me and say, "Hey, I'd like to do his test." And when I ask the reasons why, a lot of the reasons are like a thinly veiled, "Because I would like more control."


Rebecca Davis:

So I think back to the values piece is that, "Okay, what's your why? Let's start with why. Why would you like to try something? What does that trial outcome achieve?" And, A, if it's really hard to articulate, probably there might be a bad thing going on, or if it is articulated and it actually goes against agility or lean practice and or diminishes flow or creates a silo, that's an initial gut. I think throughout testing, it's important to, the same way that we would do with iterations, have check-ins and demos, not just of what's the product being produced, but what is the change producing? So figuring out what those leading indicators would be and treat it the same way as we would treat a feature hypothesis or an epic hypothesis. We have some outcome we believe we could achieve. We're 100% open to being proven wrong. These are the things that we want to see as leading indicators as success and be really open with each other.

Jasmin Iordandis:

Yeah, cool. And it sounds like what's key to that though is having some concept of what that intended outcome is as a result of that experiment. It's not just going in for, as you say, the sake of doing an experiment. You want to have an idea of where you want to end up, so you can see if we're actually getting there or not.

Rebecca Davis:

Yeah.

Jasmin Iordandis:

That's really fascinating. And I think experimentation and iterative improvement, it kind of goes together. It's not just blindly following something because that's what you are supposed to do. It's preserving the values. That's a really interesting concept. And I think in that, would also come enormous opportunity. So in your experience as well, going back to the times where you've brought SAFe to an organization, or you've been going through an agile transformation, what are some of those opportunities that you've seen the framework unlock for enterprises or organizations that you've been leading those transformations within?

Rebecca Davis:

Yeah. I always was drawn to this idea of true value flow and business agility. So for me, what Scaled Agile helped unlock in a few of my organizations is, I always targeted that, like I'm not trying to make my thing better, I'm trying to make everything better. And with that mindset, really pushing for anybody should be able to take a class. Anybody should be able to take any of the classes. And these days, the enterprise subscription helps with that a lot. When I first started, we didn't have that. So it was also like anybody can take a class, and there should be creative ways of getting it paid for it.

Rebecca Davis:

But through that kind of invite model of really anybody, I had a nurse come take one of my SAFer teams classes, just because she was curious and she saw something about it on my blog, which ended up with her being more excited and getting to do agile team coaching for a set of nurses who were highly frustrated because their work on an individual basis was ebbing and flowing so much, and they felt like they weren't giving good patient care to coaching them on Kanban and having them all get really excited because they got to nurse as a team and whoever was available took the next patient case, and the patients were happier, and just being able to invite in and then say yes to coaching all of these roles that are so meaningful and they're so excited and they're something different.

Rebecca Davis:

And that same model ended up going from nothing to having a marketing person randomly take one of my Leading SAFe classes, which then turned into them talking to the VPs of marketing, which then turned into an 800-person marketing implementation. So I think the key is be open and spend time with the curious. And it doesn't matter if they're in your org. It's not like that's what I was paid to do, it's just really fun. So why not? If somebody wants to talk to you about agile, talk to them about agile. It's really cool.

Jasmin Iordandis:

Yeah, cool. And I think what I love about that is often agile may be associated just as software development teams. But as someone who's in marketing myself, I love the benefit and the way of thinking that it can provide to very traditional challenges, but the way that it can unlock those challenges in ways that not have not been approached before. And I think that there's something to be said in that too, around what you were saying earlier around maintaining excitement. And I feel like this question's already been answered, because often it's discussed, "Okay, we are scaling agile, we're going through a transformation." And it implies that there's this end state where it's done. It's transformed or we've scaled agile, but it doesn't sound like that's the case at all.

Rebecca Davis:

No, I don't think at all. I think mostly the opposite of... If you look at even yourself as a human, your whole life, you're transforming in different ways. Everything's impacting you. The environment's impacting you, whatever happens in your life is just this whole backpack that you carry around and you're transforming all the time. And the exact same thing, I think, for an organization and company. Today's age is nuts. There're updates all the time, there's new technology all the time. You and I are doing a talk from completely different countries, and there's change literally everywhere.

Rebecca Davis:

So yeah, I think part of transformation is helping your organization feel comfortable or as comfortable as possible with the rate of change happening and all the people within it, and not see change as a bad word, but as a positive thing where we can make betterness out there. And it's forever. It's a journey. It's not done. I really like Simon Sinek when he talks about that infinite game. I just feel really close to that of, we're not in it to win this moment or this year, we're in it to make a better future for ourselves and our children, and that's going to take forever. The people are in it right now and they've got to be excited about that.

Jasmin Iordandis:

Yeah. And I think that's that balance of delayed gratification, but constant improvement. So you'll feel and experience the improvement along the way. It's not like it'll be way out in the future where you won't feel the benefit of what you're doing, but it's something that's going to be built up and happen over time.


Rebecca Davis:

Yeah. And I think you reminded me just from saying that. I did that marketing transformation, and I just deeply remember a call with one of the marketing VPs who, after four or five iterations, I did a check in with her. And she's like, "My team is so happy. Is this because of agile? Is this what agile is, is happy with [inaudible 00:32:17]?" "Yes."

Jasmin Iordandis:

Yeah, joy at work, right?

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Isn't that what it's all about? That is so cool. And yet the goal initially is never to go out and make people happy. It's just one of those bonus kind of side effects, a happy side effect.

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Awesome. And I think I really want to talk about this idea, because you've mentioned it a couple times, you've even just mentioned then marketing, nursing. But then when you're in these larger organizations, you've got all these different functions. And I think it raises this idea around organizing around value. So I want to make sure we talk a bit about that, because value doesn't just happen from one function, or it's not delivered from just one function or one team. It's something that many people across an organization may have a hand in delivering. But I really want to get your take around this concept of organizing around value. What does that mean and what does that look like?

Rebecca Davis:

Yeah. I think there's a base concept that is also in that implementation roadmap around what happens first. So how do we first organize around value, because organizations tend to be organized around hierarchy. I am a VP of marketing and I have marketing all the way down. And so there's that first step of identifying what the value is that you produce as an organization. So being able to articulate it to begin with, which is not always an easy conversation. Sometimes it takes a bit of time, and then organizing all the different types of roles around what that value is. So I think that's your first thing in what most organizations implementing scaled agile start with, is just identifying it, forming around it, which ends up being what your trains end up being.

Rebecca Davis:

My experience is, because of that same rapid market change, the world changing so far, it's really important to re-evaluate how you've organized around value over time. So in my experience, one of the really healthy things that we used to do is, at the end of each year, give a chance to look at the different train structures and look at how we've organized and say, "Is this still right? And what's our strategy for next year? Where are we trying to head for our consumers and our users? And is there a different way to organize, that helps us with that?" And I say give a chance because in some years, we'd be like, "No. 80% of our portfolio is actually good to go. Things are flowing. We're doing okay." 20% of it has an entirely new strategic shift that's going to hit them, or, "Last year felt not good. We had too many dependencies. We didn't have the right people on the right trains," all those things.

Rebecca Davis:

And so at least take a pause and look at it, and see if our value still mean the same thing as it did a year ago or two years ago. Do we need to reorganize? What does that mean? What does the change leadership around it if we do need to, so that we're always focused on value, and it's not a definition that we gave ourselves five years ago and just stopped realizing that the world has changed.

Jasmin Iordandis:

Yeah. A living definition because it changes depending on what's going on in the world, but also what's going on within the organization and coming back to that idea of experimenting as well, like if you've tried out a new way of working, and that's gotten in the way. But even something that you said there really stood out is, "Okay, it didn't feel good. We might have had too many dependencies." And that brings up the idea of, "Well, how does that flow of value happen?" Oh, that sounds like there's a stifle to the delivery of value. So how do you optimize that flow particularly when there may be multiple people delivering that value?

Rebecca Davis:

Yeah. And I think Scaled Agile gives us some tools for that. So I think one of them is that first session I talked about, value stream and down vacation, so that you can really do a process for talking and discussing with the right blend of people. What is the value and how can we organize around that? I think past that point, there's another tool that I see used far less than I would think it would be, which is value stream mapping. So after we've identified it, now can we actually map what's happening? From concept to cash, which teams are doing pass offs? How long does it take to get an answer on an email? How long is it taking from testing to all the way to release?

Rebecca Davis:

So doing a lot of intentional measurement. Not measurement because we're judging people, but intentional measurement of, we organize this way, this is where all the pieces are connecting, and how long things are taking, as well as how people feel inside of their steps, like does it feel silo? Does it have an outcome? Did we put all of the designers and HR people and engineers on a train, but we made them separate teams, and so it still doesn't feel connected? That's what mapping's for. And those maps and also the program boards that actually visualize like, "Here's the dependencies," versus, "At the end of the PI, this is what those dependencies actually ended up being."

Rebecca Davis:

It's not that dependencies are bad, but they should be adding value, not restricting flow. So I think those connected stories as well as things like employee survey scores and just employee happiness are really good inputs, to, are we delivering flow. And it is a blended view. Some of it's qualitative and some of it's quantitative. But are our own internal things showing us good, bad and different, as well as how are our customers. So do they feel like they're receiving value or that they're receiving bits and pieces and they're unsure about the connected value? I think all of those are indicators.


Jasmin Iordandis:

Yeah. And would you say you'd need to have an idea of what those indicators are beforehand, so you can keep an eye on them as the PI progresses? So for example, you've done your value stream mapping, you've built your art. At that point, do you identify what those measurements of flow ought to be and keep an eye on them, or is it more retrospectively where you see these kind of things getting a little bit stuck?

Rebecca Davis:

I think there's both. So definitely those metrics that we indicate inside of the framework are healthy, good for teams and trains and solution trains and portfolio. So I think there is a set of metrics that you should and can utilize. Retrospectives are key, because retrospectives create action. So while we measure, then what's the conversation we have about them? Because what we don't want is vanity metrics. And my personal way of defining vanity metrics is any metric that you do nothing with.

Rebecca Davis:

So I think a key is use them to hold conversations and create outcomes, and create actions and make sure that you're prioritizing those actions. I think there's another piece of just understanding that this is not just about team and train. So teams and trains definitely do need to improve and measure themselves, but so does the portfolio, so does the enterprise, so do the pieces that connect to each other across different trains. So I do think if you over focus on, "Let's just make our teams go faster," you may be missing the whole point of how do we make our organization flow better, which may or may not equate to moving faster right away.

Jasmin Iordandis:

Yeah. Yeah. And team and train don't exist in a vacuuming within that organization like whole bunch of-

Rebecca Davis:

No, [inaudible 00:40:43].

Jasmin Iordandis:

Yeah. Well, I think we've touched on some really, really interesting concepts, and just I can't wait to hit the SAFe Summit, which is a really good segue to the fact that the next time we meet, Rebecca, it will be in person. And you're hosting a workshop at SAFe. Can you give us any sneak peek of what we can expect to be excited about at the summit?

Rebecca Davis:

Yeah. First of all, when we meet each other in person, I'm very short. So I think I'm maybe five foot. So that'll be exciting. So Harry, on the framework team and I, are running a workshop about flow. So we'll be doing a flow workshop. I can't talk about all of it yet, because some of it we're going to announce inside the summit, but I'm really excited. So I think if you do sign up for our workshop, you're going to get active advice, and be able to work also alongside other organizations and other people, really understanding flow, and how to apply improvements to flow and how to identify blockers to flow and what to do about it. So we're really focusing on why do certain things matter and what can you specifically do about it, whether you're at the team level or the train level or solution level or the portfolio level.

Jasmin Iordandis:

Cool. That sounds exciting.

Rebecca Davis:

And we [inaudible 00:42:08] a lot of other workshops, but definitely come to ours.

Jasmin Iordandis:

Well, we've just spoken about the importance of flow, so it makes sense. Right?

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Awesome. Well, I personally am really looking forward to coming to SAFe and coming to Colorado and to get to chat with you a little bit more. But thank you so much for your time and joining us and sharing your expertise and experience on agile transformations, scaling agile and the SAFe framework itself. Thank you so much for your time, Rebecca.

Rebecca Davis:

Yeah, I appreciate it. And I look forward to maybe one day being able to do this in person with you in your own country. So that'll be really awesome.

Jasmin Iordandis:

Yeah. Cool. That would definitely be awesome. Thanks a lot.

Rebecca Davis:

Yeah. Thanks.

Related Episodes

  • Text Link

    Easy Agile Podcast Ep.28 Team23! + the world of work

    Dave Elkan, Co-Founder and Co-CEO of Easy Agile is joined by Jean-Philippe Comeau Principal Customer Success Advocate at Adaptavist.

    "Hearing from JP is a sure-fire way to get excited about Atlassian Team '23. We spoke about where we are hoping to see conversations focus + more."

    JP is passionate about teamwork, meeting new people, presentations of all kinds - loves a microphone and a captive audience, new technologies and most of all problem-solving.

    In this episode, JP and Dave are talking about one of the most anticipated events in the tech calendar - Atlassian’s Team23! They’re talking about what to expect, tips for first timers and what they’re hoping to take away from the event.

    They also dive into the future of work and the significance of coming together as a team.

    We hope you enjoy the episode!

    Transcript:

    Dave Elkan:

    Hi, all, and welcome to the Easy Agile Podcast. My name is Dave Elkan and I'm co-founder and co-CEO here at Easy Agile. 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 State Islander and First Nations people joining us today. Today I am joined by Jean-Philippe Comeau or JP. JP is the principal customer success advocate at Adaptavist and is passionate about teamwork, meeting new people, presentations of all kinds, loves a microphone and a captive audience, this podcast definitely fits that mold, new technologies, and most of all, problem-solving. JP, thanks so much for being with us today.

    Jean-Philippe Comeau:

    Thanks for inviting me.

    Dave Elkan:

    Hey, no worries. It's great to have you on. We want to take some time today just to talk through Atlassian Team '23. The ecosystem is gearing up for one of the biggest events of the calendar and the ultimate event for modern teamwork. You've been to a few Atlassian Team events before and last year being the first one back in a while. Quebec to Las Vegas is quiet a gear change. What are your tips for people attending Team for the first time?

    Jean-Philippe Comeau:

    Ooh, yeah, that's a good question. I mean, yeah, Teams to me is a massive event. It's a beautiful moment to actually take in everything that has happened in last year for Atlassian. What I mean by that is actually more and more what's happening with Atlassian is actually what's happening in the world of work. So I think it's just a great time to reassess where you're at. So for me, it's about planning out the main things you want to hit and don't overcrowd your schedule. That's a mistake I made the first time was just I wanted to see the most of everything and I was like, "Yeah, I can absolutely do back to back to back. It's going to be fine. I'll be walking from one thing to another." Truth is after talk, you'll have some questions. Some things will popped-up. "Oh, that's interesting. I could maybe explore that."

    You're going to want to do maybe some floor hunting, which is like, hey, looking through the partners. Maybe you've heard about something like an app that you really want to go look at or something like that. So, that's always going to happen and then you're going to miss that next talk. So make sure that what you highlight is really things you want to see and plan according to that. That to me is the number one thing. Don't try to do it all. Do what you feel is really, really important than the rest. Try to make it work because it's going to be a lot of walking, a lot of listening, a lot of talking. The second thing which I remind everybody is to hydrate, get a bottle of water. There's going to be plenty over there, but everybody's going to have their own branded bottle of water, so don't worry about having one or not, but get one and just hydrate. I mean, we all get very busy during the day and we all know how the nights can go, so keep drinking some water. Yeah, those are my two tips.

    Dave Elkan:

    That's great advice. I think hydration is certainly something to consider. I remember particularly a wall of donuts at one point distracting me from good habits like that. So yeah, it's really important to make sure you've got the basics in line. What are you most looking forward to from the lineup at Team '23?

    Jean-Philippe Comeau:

    Yeah. I mean, every year the keynotes are what's going to hit the most. Obviously, getting a chance to hear James Cameron talk is going to be very, very interesting. I think especially in the year of Avatar 2 is just great timing, obviously probably planned. He's probably on a tour, but it's going to be really great to hear some stories of how that movie came about. It's been a long time in the making, probably the closest thing we got to really long development on a film. It feels like a long software development cycle thing. That's a very long time. And then hearing Van talk about some of the things that he's seeing in today's world. Van Joseph, I believe, is the name of the second talker, and remember seeing him a lot on the CNN broadcast and stuff during the elections and the impact that he brought to the whole broadcast was quite something. It'd be very interesting to hear them talk.

    And then as far as maybe not the big ticket items, really interested to... I think this is the year where the practices on the different tracks that Atlassian usually promotes, I think this is the year what they really start to hit. What I mean by that is I think before this year, so when you look at last year's Team and then before that, tracks were kind of like wishy-washy. Now, they actually have the products to back them. I think JSM's in a very, very good spot. I think their agile tooling is in a very good spot. I think their DevOps, which is what I expect, is going to be pushed the most, or DevOps tooling with the Jira product discovery and all their Point A stuff is got to be where it's at. So I think you're going to get really good talks on those practices. I think that's going to be the year where the tracks actually make a ton of sense and are very valuable to people.

    Dave Elkan:

    Absolutely. Thanks for sharing. It's really interesting. Yourself, you're a Canadian and James Cameron is a Canadian and he's talking about creating the impossible, and I think that's a theme that's coming through and what Atlassian is promoting and bringing that through. It's really interesting to see or hear you talk about the both building movies and media and CNN, the reference there, and how that can apply with a strongly software development-based audience. It's really interesting to see that building a movie is a very much a waterfall process in that you have this huge deliverable at the end, but I know that there are Pixar, for example, use this concept of Demo Trusts, we call them, or the Pixar Demo Trust. Yeah. So essentially you can test along the way as you go before you deliver this huge thing. It's really intriguing to think what we're going to hear from James in regards to how he builds these amazing projects.

    Jean-Philippe Comeau:

    Yeah, I think you're spot on. So I'm actually a huge Marvel fan. I don't have my book with me, but the Creativity, Inc. is a book that I love by Ed Catmull and how they built Pixar as a business, as a delivery team, not just about the movie side of it, the creative side of it, but how do you bring creativity into a more structured world that is the corporate world kind of thing, which they're now a part of? So, very interesting that you bring that up because I'm very fascinated by their process as well. I think they were the pioneers in the movie-making business or industry into bringing the agile methodologies or thinking to movie-making.

    Now, what would happen historically in movies? Okay. So you don't know this, but my background is actually enacting. So when I started, when I studied, when I was a young lad, young adult, let's put it that way, I wanted to be an actor and then things changed. Obviously, I am not a prolific actor. So I'm very, very passionate about the movie-making industry. Movies historically has always been about you shoot, you shoot, you shoot, to develop, develop, develop, and then at the end, you cut it. So you make mistakes. So like we said, very, very waterfally. I think now that technology is almost like 50 to 60% of a movie now more days... If you look at Marvel movies and all that, you could argue it's 50 to 60% is going to be computer-generated, which can be a bad or good thing. Now, that I'm not going to get into that debate.

    The nature of previz and all the animation work that goes behind it makes the process more agile, meaning that what they're going to do is they're going to build for a week and then they're going to review the film that's been made and then they're going to correct and do it again, right? So already you got your feedback loop going. You got your process. You got your sprints going. I can map all that out to some agile processes and I wouldn't be surprised that you're looking at something that are looking to scale up. You could even argue what are you guys going to do for your scaling methodologies? There's a lot of things that are very interesting.

    I think going back to our first point, sorry, I really went on a tangent here, but going back to Avatar, when you have such a long cycle and you have a movie that's built, that one is heavily computer-generated. I mean, every actor has stuff on their face and they're acting in a blank studio. Now you're talking about agile processes because if you're building hours and hours and hours of work and you're just building and building and building and never review, I can't... Maybe James will say that's how they did it, and I'll be like, "Well, you guys were... It's very difficult. You made your life very, very difficult." But it'd be very interesting to hear because I cannot imagine them not going into some type of an agile way of building this movie.

    Dave Elkan:

    Oh, of course. I think that if you imagine the cutting room floor, it's an old adage and literally they used to cut the film and they'd leave it on the floor as that's something we're not doing anymore. And so, I dare say that there's a vast amount of film which is thrown away and redone. I feel that if we could see past that to this beautiful thing that they're doing behind the scenes, which is testing and iterating on their shots, it's actually quite a simple concept to apply these agile processes to filmmaking. It's just at the end you have got this big bang, same in game production. When you produce a game, you cut back. People do early access, which is fantastic. You can't early access a movie.

    Jean-Philippe Comeau:

    No, exactly. Yeah.

    Dave Elkan:

    Yeah. Going back to Pixar, that reference, I actually made the mistake. It's not actually the Demo Trust. So this is the Playbook by Atlassian. There's a play called Demo Trust, but it's the Brains Trust and it's bringing together the team to talk through does this fulfill the vision of Pixar? Does this make Pixar Pixar? And helping the team understand, so directors get that ingrained Pixarness through that process. So yeah, there's a whole team behind the scenes here. There's not one person who's just driving this at the director level. There's actually a whole team of people collaborating on this movie. So I'm really intrigued to hear that from James to hear how the teamwork comes out.

    Jean-Philippe Comeau:

    Yeah. I think when you look at a movie like Avatar, again, another thing that we don't think about is the connecting remote teams, which is a big, big part of what we do in 2023 is connecting remote teams so that they feel they're working on one project. When you have a movie like Avatar, your VFX is going to be somewhere. Your actors are going to be another place. And then you're going to have music and sound's going to be somewhere else. Your editors are probably going to be somewhere else. And so, there's a lot of remote work that you do. How do you bring all that together?

    I remember watching the old documentaries around the Lord of the Rings movies, and they were literally flying people in and out with the actual roll of films because they were so afraid that people would steal them and so that they wouldn't put it on the internet and they would actually carry them around. So they had to fly from London to New Zealand to... It's kind of nuts when you think about it in 2023. Really, you had to take a 10-hour flight just to get your film across? It's probably easier also with the data, just the bandwidth and everything. So I think that's also going to be an interesting part is how did you connect teams?

    You brought up a great point around the Pixar way or that's how they call it, the Pixar way. When you think about that, there's some really, really cool ideas behind bringing a team together and rallying them around one project. I think as teams get more remote and distanced from products and things that they're working on, and I do it myself at work. Things become generic. At some point, you're just doing the same thing over and over again. You lose touch a little bit with the work that you do. I think it's a beautiful thing to be able to rally a team around a project and say like, "Do you believe in this project? I believe in this project. Do you believe in this project?" And making sure the team does and if they don't, why don't you? What's preventing you from that? I think there's a lot of good conversations, sorry, that can come from that. Yeah.

    Dave Elkan:

    Absolutely. So yeah, you talk about going more remote. Is that a trend you're seeing, that we're continuing to see more and more teams go remote, or are we seeing a reversal of that to some extent?

    Jean-Philippe Comeau:

    It depends on what sphere you're working with, or in my position, I get to touch everything. I tend to gravitate towards the more creative teams of gaming and software development and stuff. I do work with banks. I do work with, well, corporate America, the classic suit and tie kind of places, everything. I see everything. There is absolutely out right now a battle of old versus new, old ways of working, new ways of working. There's a huge clash happening. I to this day do not know who's going to win, because even the big Silicon Valleys, I mean, we are all seeing what's happening with Apple and them putting mandatory office dates and stuff like that. You see that from an executive that is leading maybe one of the more bleeding edge companies in the world, but he's still an old school vibe of creativity.

    I hate bringing it back to Pixar. I'm going to bring it back to Pixar. They have such a great office. So like I said, I'm very fascinated about what they do. They call it unplanned creativity. They truly believe that unplanned creativity happens in the office, and when you have unplanned meetings, unplanned interactions. So one of the things that they did, it's now very common, but when I was 14 years old and I was reading about them, I was like, "Oh my God, these are such cool things to do," they were doing those ping-pong places and activities and games to get people to play together and start talking about what they were doing.

    And then all of a sudden you got an engineer talking to a VFX artist that's talking to a 3D or conceptual artist, that's like they would never meet in a meeting or anything like that. But because they're playing ping-pong and throwing ideas around and all of a sudden they're like, "Hey, maybe we could build this thing. That'd be amazing." Because the artist saying, "Well, now I could do clouds this way. Yeah. Nuts, I could create clouds that look like this." Then the engineer goes, "Well, you can just tweak a little bit of things."

    Anyways, so I think there's this old school mentality at this. It's a question I've asked myself in our Slacks and where we talk about work. I don't know what the future is for unplanned creativity. I don't know how you recreate that in a virtual world. I think it's a big problem that some software companies have tackled with some tools. I don't know how you force someone to sit behind a computer and do something that's unplanned. How do I stumble across some... I don't know. But yeah, I think there's a bit of that in the old school mentality. I need people in an office so that they can meet and they can interact together. I still struggle to find where they're wrong, let's put it that way. I don't know where they're wrong about that theory of when you're with someone, when you're with people things happen in a different way.

    Dave Elkan:

    I can't agree more. I think that if I have any perspective on this, it's that there is not... Often, it's not a black and white or a zero sum kind of game. It's a combination of things that will occur and that will move forward for better or for worse. You can look back in history to Bell Labs and the creation of the semiconductor and the way that the building was designed essentially to allow people to walk past and have cross-collaboration and cross-functional conversations. Have you ever considered that the unplanned creativity that Pixar was talking about was actually planned-unplanned creativity, so they made these spaces on purpose? How can we make things on purpose to have things unknown to us happen?

    Jean-Philippe Comeau:

    Yeah. Yeah. Actually, you're absolutely right. I mean, yeah, they built the Pixar offices this way because of that. To me, that is the secret. If someone finds it, it's like the caramel milk or whatever, just bottle it up and sell it to people, I guess. I don't know. I have no idea what the answer is. I've looked and it's... There's an app out there. I can't remember the name of the app, but you're like a 2D sprite and it looks like an NES game and you're moving around from places to places. You can decorate your office. It's got this vibe of Animal Crossing, which is a game by Nintendo where you can just create stuff and people can visit your island and all that.

    You can do that with your office space and then you can create a common area where people walking. When you look at it in a video, it's brilliant. Great, I can actually be in the office without being in the office. It has this whole technology of proximity. So if you're having a conversation with someone in an open area, people could walk by and hear what you're saying and join in. Beautiful technology, doesn't work with the humans when you really think about it. Why would I go online to walk around an office to go talk? I'll ping you on Slack, it'll be easier. All right. I don't need to walk through your office. So it's like I don't know what the secret is.

    Yeah, you're right, it is planned in a way. I think we do that. I don't know for you guys at Easy Agile, how you do it. In Adaptavist, we do like to travel with teams. So whenever we do things, even if it's customer work or if we're going for an event or something, we try to make it a point to make it about also us and what we do. So we rarely traveled alone. If I'm going to a customer, we're trying to get two consultants in there, or what I'm trying to say is bring more people. It's a point, I think, Adaptavist is trying to make and I think that's what Simon, our CEO, is trying to make is use these opportunities to be with people. I think it's a beautiful thing, but it's one of the myriad of solutions. I don't know. I really don't know. What do you think? What are your thoughts on this?

    Dave Elkan:

    Oh, I can share how we work at Easy Agile. So here I am today in the office. This is a great place for me to do this recording. We have a room for about 50 people here in the office in Wollongong, south of Sydney. We have about 10 to 15 who usually arrive on a daily basis, and that's great. We don't mind. We love people working from home and working away, which is more convenient and relaxing for them. At the same time, we do have quarterly plan, like planning sessions that we go to. We have Advanced Easy Agile every quarter. We come together in person. We've strategically ensured that we hire in a way so that's possible, so people aren't flying across vast sways of ocean to get to this conversation. In a way, it's planned-unplanned. So we do our planning ahead of time.

    When we come for Advanced Easy Agile, we'll have something that we want to either upskill the team with or whatever, and then we'll have some team bonding where people can choose from a range of different activities they want to do together. And so, for us, it's more about getting together in person because we know that's really valuable to both build an understanding of each other as a team and to build that rapport. It can't be done over Zoom to an extent. So, absolutely, our business runs entirely in a remote-friendly way and we don't rely on people to be in person, in sync in person to move forward. However, we do see there's a great value there. So we try to live in both worlds and we get the benefit from both of them. Yeah. And so, that's one thing that can work. It's not for everybody. If you have a truly distributed global business, it's not exactly easy or affordable to bring everybody together on a quarterly basis.

    Jean-Philippe Comeau:

    Yeah. I think it's beautiful though. So I've been in Adaptavist for close to six... I'm on my sixth year now and we used to be able to do... We didn't do quarterly. We did a yearly thing at the end of the year where everybody would get together. We called it Winter Con for the last two years, which I actually loved the idea, which was very much we could pitch ideas of what we wanted to talk about. It could be about work, could be about customers, could be about last year, whatever you wanted to talk about, could be about yourself, could be about a cool thing you did this year, whatever. We had a voting system, but really pretty much anyone that said any, you could get in.

    You could just walk around and it was literally a conference center. We'd set up some rooms and you could walk in, look at a presentation, literally like Teams or whatever. It was the best experience every time that we did that. I love these because there's value. There's an ROI in having everybody learning and upskilling and breaking down these silos of, "Hey, I never worked with marketing, but here's an hour talk around something we did in marketing. I really want to join," and all these things. That's great. There was also the unplanned ROI, where you were coming out of there with multiple ideas of like, "Oh, I could explore this. We could explore that. I got this meeting set in Jan now that whenever I come back in January, we're going to be talking about this thing that we talked about for cloud migrations." All that was happening at Winter Con.

    Now, we grew exponentially post-COVID, well, during and post. So while COVID was happening and all of a sudden everybody wanted work. And then as companies that were remote, I think a lot of the companies that were remote grew during COVID versus because companies that were local or anything, they slowly diluted down a little bit, let's put it that way. As we grew, we can't support that anymore as a one-time thing where you'd have... We're close to a thousand now. There's a lot of people to move and a lot of conferences, a lot of conference rooms and presentations and stuff that we just can't accommodate. So, I miss it a lot. We've been doing it remotely, but like you said, it's not the same to go on a Zoom call.

    I remember sitting down in these presentations and you're sitting down next to people that someone from Arkansas, someone from Cambridge, and you start talking. Yeah, you're listening to conference, but we all know what happens when you're listening to a presentation. You start talking like, "Yeah, that's an interesting idea. What did you do last weekend?" You start talking. Those are things you can't do on Zoom. You can't really reproduce that on Zoom. It's not going to happen really and I miss that dearly. I don't know what the solution is when you have these kind of global distribution. I mean, I guess you do in a smaller way, maybe all of North America meet up or things like that, but it's just not the same, not the same at all. I think it's beautiful that you guys can still do these because everybody's close by. I think it's really nice.

    Dave Elkan:

    Oh, thanks. Yeah, it's something we're hoping to hold onto as long as we can. We understand that these things don't scale. At one point, we'll have to break it into different events so that people can have, I think, a higher level of involvement in that. If you have too many people at the same time, it can be just a bit read only, the way I see it. It's as if to seek participant.

    Jean-Philippe Comeau:

    That's nice. Yeah. Yeah, I like that. Yeah. Yeah, you're right.

    Dave Elkan:

    So I'd love to just quickly touch back on Atlassian Team '23.

    Jean-Philippe Comeau:

    I'm sorry.

    Dave Elkan:

    You did mention at the beginning... That's all right. We'll get there. There's these new apps, especially in the DevOps tooling space that Atlassian's working on, so Discovery. Can you just talk to me a little bit more about what you see there and why that's coming to fruition now?

    Jean-Philippe Comeau:

    Yeah, I think it's all about cloud. I'll be the first to say that big fan of data center, big fan of on-prem. That's how I learned the Atlassian tool set. So, a little skeptical when cloud came about. As it grew and it got better, it got better, that was great. I think it's now at a mature spot where the Point A program, which is where all of these tools are coming out of, so the product Discovery, Atlas and all that, those are the fruits of cloud. That's because now that we have cloud, they can churn out products and try things and see if they stick or not. I think that's why I think this year is the year where I think the program is mature enough. Migration's ready. I mean, we're one year out of server end-of-life. I think we're finally in a place where we can actually talk about all these opportunities. Most of the people at the conference will be able to get value from it.

    I remember last year where talks were heavily around JSM and all the cool things it would do, but you still had a lot of people on server, still had a lot of people on data center. So it fell a little bit on deaf ears. A lot of people in the crowd were just like, "Yeah, it's not for me." Both keynotes were about that. So anyways, I think this year it's going to be better because of that, because everybody's bought in. I think it's right now because yeah, it's cloud. You can ship easier, faster. You can ship better. You can iterate better. You can get a product ready much, much quicker than if you're on-prem, and I think that's why you're seeing this blow up. I also think they're great ideas. Big fan of Atlas specifically. Big, big fan of Atlas.

    Dave Elkan:

    Yeah. Fantastic. So, how are your customers seeing the migration to cloud? On the larger end, is that something that they're open to? Is that something that they support?

    Jean-Philippe Comeau:

    Everybody is intrigued, I'll start there. Everybody's intrigued. Now, the level of interest depends on the industry and the size. When you have a massive... I'll use banks because to me, banks are kind of like countries. So if you look at a massive bank where you have 30, 40,000 users, usually they have solid infrastructures. They have solid administrators. They have teams that are kind of living off this. It's built its own economy, basically. It runs itself. When you go in there and you try to teach them about cloud and all the great things it'll do, they start asking questions that are very technical and they're very good. There's not really an answer in cloud for yet, and so it gets skittish. Whereas if I go to a 500,000 people organization and they start asking questions about cloud, and usually we have more answers for that. It's just easy, an easier conversation. They don't have the same worries or the same thing troubles on their mind than the admin of 40,000 people. It's just not the same reality that they're seeing.

    So I think for now, and I know Atlassian's making a big push into that enterprise space, I think for now you're going to see that growth. But as long as we don't have full autonomy of where our data is and how accessible that data is, it's going to be a problem, as long as FedRAMP isn't available to all, as long as all these different SOCs and compliances aren't available to all. These are very difficult because you've built an ecosystem around a lot of integrations and Easy Agile being to me, one of those integrations because their third-party app, however you want to look at it. Adaptavist has their own third-party app. So you have script runner and all that. We all have third-party apps. So Atlassian can't be like, "Oh, yeah, I'll make a blanket statement. We can do all these things." It's not really true. I'm like, "Hold up, you got to take into account all these different app partners out there that are doing their things and you can't put us all into one roof."I think they're victims of their success. What still making Atlassian great is the partner ecosystem, apps, solutions, sorry, everything, but it's also what's causing the adoption and the speed to which adoption of cloud is happening. It's making it slower than they would want to. I think that was maybe the misstep a little bit when everything got announced was like, "Oh, you guys do rely on these apps a lot." Yeah. A lot of our customers actually would say that the apps are even more important to them than the core. It's just a thing that you're seeing. So to go back to your question, depends on the complexity of the instance. The bigger the instance, usually the more complex it is. So if I go to over 10,000 users, it's going to be a very long conversation. Very, very long conversation.

    Dave Elkan:

    Yes, it is. It's funny that Atlassian did ship this and say, "Hey." Well, actually, there was a presumption that the apps were covered by SOC 2 or the like as well, and that was a missing... But it was this misunderstanding. But I say as a business owner going through SOC 2, it's a very rewarding and good process to go through. It's hard. We are doing it far earlier than Atlassian did in their own journey, but the sooner you do it, the easier it is. Ideally that as a smaller company, you have less things to worry about and the processes you put in place will be easier to maintain and monitor. So we're excited to really go down the SOC 2 path and to provide that peace of mind to our enterprise customers. So yeah, very good process to go through.

    Jean-Philippe Comeau:

    Yeah, you guys are going through it right now. Have you acquired it yet? Did you get your compliance yet or you're on your way to getting that?

    Dave Elkan:

    No, we're on the way to SOC 2 type 1 at the moment.

    Jean-Philippe Comeau:

    Wow. Nice.

    Dave Elkan:

    Yeah.

    Jean-Philippe Comeau:

    Yeah. Yeah. We got security group now in and they're handling all that. I'm not good with the compliances. I'll say it right now, right off the bat, I don't know them very well. I know they're like letters I would like to see next to every apps. That's what I know. I don't know how in depth the processes, but I know it's very involved to the point where you need to have a team dedicated to making that happen. So what have you guys seen so far? It's coming along great. What are some of the challenges that you've seen maybe? I'm just intrigued.

    Dave Elkan:

    Yeah. Oh, look, so our cloud apps are all architected in the same way, so they all use the same code base to an extent, like the deployment methodology. We haven't done any acquisitions which have bolted on to make that more complicated, so we're making the most of that situation. We've done a fair bit of work over the last quarter or so to put in all the checks and the controls around that deployment. The next thing is to really put in place the processes to ensure that our team understands how to deal with different situations and the like. So, that's something we're going to tackle in the next quarter. I'm excited to go through that and do a bit of a sprint with Nick, my co-founder and co-CEO, to really see how much we can get done in a period of time and really focus on that. I think that the benefit will be that we have a much more understood and clear way of running our business, which is obvious to our customers as well, which is a very good thing. I'm all in favor of it. Yeah.

    Jean-Philippe Comeau:

    Yeah, that's awesome. Yeah, I think we're seeing some of the similar things, but we did acquire a bunch of stuff and so that is making everything a bit more difficult, for sure.

    Dave Elkan:

    I can understand. That would be very tricky to try and bridge those gaps and to homogenize enough to be able to have a really clear statement going forward. Yeah. Okay. So we touched quickly on the Atlassian apps that they're bringing. Are there any apps in the marketplace that you have got an eye on that you'd love to go and talk to, of course, Easy Agile aside?

    Jean-Philippe Comeau:

    I mean, of course. Yeah. A big need that I'm noticing now in the market... I don't know if it's a secret or something, I should wait because I know Team '23, they're going to be doing some stuff and I'm really excited for them. So one of the things that we're noticing is... So backups, so enterprise support, basically. Right now, when you're on the cloud, most companies, again, in the 40,000 and plus have strong backup needs and they actually have requirements, laws, things that they need to abide by as far as how long they maintain data, how long they have backups of data and all that. Right now, the way that it's done in cloud isn't nice at all. You actually have to go into the UI. You get a backup. If your backup is large, it's going to take multiple days to process and you got to remember to... It's all manual. There's nothing that really automated.

    So, there is a growing market for these kinds of apps. I've been talking all that to these people at Revyz, R-E-V-Y-Z. What they do is they basically automate that process for you and they host your data. Right now, they only do it for a year, but it's still much better than what we're seeing out there. There's a lot of need for services like that, where they... Because I mean, part of the appeal of cloud is obviously hands off, don't have to worry about things anymore and Atlassian only guarantees backups for 21 days. So if you're an enterprise and you're looking for six months at least of data recovery, at least you're not going to get that. So by having a partner like Revyz or all these, there are other apps out there, I'm talking about Revyz specifically because I talk to them a bunch, but a lot of interesting things are happening.

    Also, what's amazing about these apps, what these developers have found, and once they've have that process, they now get access to the structure of the data and they've started building tools around that structure. So for instance, that app can actually restore projects and issues and custom fields and configurations. So you don't need to do a full restore. You can actually pick what you want to restore, which is brilliant. It's something that even in data center wasn't easy to do. You couldn't just say like, "Hey, give me that issue." You'd have to restore the snapshot, go into the system, find your stuff. Now being able to go into my UI and Jira, go into my backup app, go and look the issued I deleted by mistake, find it, restore it the same day, it has comments saying, "This was restored by revisits, so make sure blah, blah, blah, yada, yada, yada." It's just brilliant and I'm really excited to see that grow this year.

    Dave Elkan:

    That's amazing. Yeah, it's a really intriguing part of this piece that I've never really thought through that that's actually a really important part of running an enterprise, that you have those continuous backups. Yeah. Cool. Yeah, that's a great insight.

    Jean-Philippe Comeau:

    Yeah, it's going to be an interesting market to dive into because we've been asked, even as a service partner, "Can you deliver on this?" The truth is without an app, you can't. There's no real way for me to get a backup. I'd have to go into your instance every day. I don't think you want a consultant going into every day your instance, downloading a backup and throwing it. I'd rather spend my money elsewhere. So these apps are going to be very... I think they're going to be big and I'm really interested to see what happens with all these different ventures.

    Dave Elkan:

    Well, certainly, a booth I'll be popping by to see if we can include the Easy Agile data in that backup as well.

    Jean-Philippe Comeau:

    Yes, exactly. So they are looking at other app partners and seeing what they can do. So I think, yeah, absolutely, if you want to have a chat, they're great people.

    Dave Elkan:

    Beautiful. Thank you so much for your time today, JP. That's a wrap. Hey, is there anything else you wanted to touch on before we wrap up? Is there anything you are hoping to get away from the event, to take away from the event? Anything on the sidelines you're going to see when you're there?

    Jean-Philippe Comeau:

    I mean, obviously, App Day is going to be a big thing. Really excited to meet y'all in person, see everybody. So App Day is the time where I get really technical, get my hands dirty. I don't do that a lot these days. I miss it sometimes just sitting down and doing some good old admin work. So anyway, the App Days are usually when I really get back to the nitty-gritty of let's talk about script runner, where we're at now, and let's meet with Easy Agile, with Temple, with all these different app vendors and talk about what's coming up and what they're seeing. So really looking forward to that. But other than that, no, just looking to have a good time. I'll hopefully get some good social time as well at the evening. Like I said, we won't get ourselves half the fun is also after the events every day, so really looking forward to that, for sure, and meeting all my fellow ecosystem partners and talking to everybody and seeing what they've seen in the past year.

    Dave Elkan:

    Likewise. I'm at least 1,000% more excited now having talked to you about it. So thank you so much for taking the time today, JP, to talk through that and I can't wait to see you there.

    Jean-Philippe Comeau:

    Yeah, I can't wait to see you. Thanks for having me.

    Dave Elkan:

    No probs. Thanks, mate.

  • Text Link

    Easy Agile Podcast Ep.31 The Release Train Engineer + SAFe Summit 23

    "Lieschen's wealth of experience is absolutely incredible! Not only did she provide invaluable advice, but I thoroughly enjoyed our conversation."

    In this episode Caitlin Mackie is joined by Lieschen Gargano Sr, Release Train Engineer at Scaled Agile. They delve into the role of the Release Train Engineer, sharing tips and tricks, FLOW activities, lessons learned and how to get started in the role. With SAFe Summit 2023 just around the corner, Lieschen also takes some time to talk about what she’s most excited about for the event and shared some advice for first time attendees.

    If Lieschen's expertise and passion have piqued your interest, be sure to explore the Scaled Agile RTE course. It provides comprehensive training, equipping you with the necessary skills and knowledge to excel as an RTE.

    Scaled Agile RTE course

    We hope you enjoy the episode!

    Transcript:

    Caitlin Mackie:

    Hi there. Welcome to the Easy Agile Podcast. I'm Caitlin, your host for today's episode. At Easy Agile we specialize in developing apps for Atlassian Jira that help your team move from simply doing agile to truly being agile. Our apps have gained recognition and trust from over 160,000 users across top companies worldwide. With our products, teams can transform their flat Jira backlogs into something visually meaningful and easy to understand. Whether it's sprint planning, retrospectives, or PI planning, our apps are designed to foster seamless team alignment.

    Before we begin the episode, we would like to say an acknowledgement of country. This is part of our ongoing commitment towards reconciliation. Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people joining us today. Let's jump into today's episode. So today I'm joined by Lieschen Gargano, a senior release train engineer at Scaled Agile. Lieschen is a highly experienced professional when it comes to change management, system design and stakeholder engagement, and has a passion for developing teams and connecting strategy to execution. Lieschen welcome to the Easy Agile Podcast.

    Lieschen Gargano:

    Thank you. I'm happy to be here.

    Caitlin Mackie:

    So Lieschen, you are a release train engineer. For our listeners, can you explain a little bit about the role? For anyone that's not familiar, how would you describe a Release Train Engineer?

    Lieschen Gargano:

    Yeah. I think one of the easiest ways for people to think of a Release Train Engineer is kind of like a coach or scrum master for the art, for the Agile release train. A servant leader facilitating all of those art events, facilitating the processes and process improvements. And really measured in value delivery, and using flow metrics to measure those improvements and support of the arts.

    Caitlin Mackie:

    So you mentioned flow metrics there. I've heard a lot about this recently and optimizing flow. What are some of those flow activities that a RT is responsible for?

    Lieschen Gargano:

    I like to look at feature flow and cycle time. So really looking like are we bringing all of our features in progress at once or are we managing our WIP, not just at the team level but at the art level. Are we taking the whole PI to get a feature through the system, or are we able to finish something before we start the next thing? So I look at that a lot and also just are we making and meeting commitments. Those PI objectives that we set, are we in that 80-100% range? A lot of people want full credit, extra credit and to be in the 120, but for us, predictability really means you tried really hard and you stretched, but you also still made and met commitments. So I look at that really closely too.

    Caitlin Mackie:

    I love that. You mentioned just then quite a lot of different responsibilities that a RTE has. Do you think that there is one in particular that you really need to get right from the start?

    Lieschen Gargano:

    Oh, as an RTE, I think the biggest thing is building the relationships and intention. As a servant leader, we really are there to help make the art better, to make being on the art enjoyable and productive and flow. So building that trust and those relationships as a servant leader is the first thing. If you get that wrong, no one will help you do the rest.

    Caitlin Mackie:

    Yeah-

    Lieschen Gargano:

    And you need a lot of help. You're not doing anything alone as an RTE.

    Caitlin Mackie:

    Yes. Yeah, for sure. I can definitely imagine that. Let's go a little bit deeper on that servant leadership that you just mentioned. Can you share your approach and what servant leadership means to you?

    Lieschen Gargano:

    Servant leadership to me is helping people understand the direction, communicating early and often so that they know where you're going. And then not just saying, "how can I help you get there? What can I do?" But saying, "how can we go together?" A lot of coaching and understanding the problem to solve and connecting it to how it benefits the people. Just like we ask them to connect their work to how it benefits the customer. As the RT, they're my customer. How does what I'm asking you to change benefit you? Not changing is always easier than changing even if we don't like our current state. So why is it worth it?

    Caitlin Mackie:

    I love that. Yeah, always asking the why and being really clear on it. Yeah, I think that's great. I've done some LinkedIn digging of your profile, as you do, had a little bit of a stalk and noticed that you hosted a webinar recently on tips and tricks and lessons learned as an RTE. Can we start with maybe some tips and tricks? What can you share?

    Lieschen Gargano:

    The first thing I will say is lean on the Scrum master team, and if you're lucky enough to have an Agile coach or another RTE, lean on that team. Your lean Agile Center of Excellence, those people have the expertise. They're also building the relationships. They're there to help you. Don't try to just prove yourself or go it alone, it's not possible. That team is your team for success. So 100% go to them. They're a wealth of knowledge, a wealth of relationships, and the best support.

    Caitlin Mackie:

    Yeah, I know it's so important to have that support network around you. You just mentioned the Agile Center of Excellence. Maybe for some of our listeners aren't familiar, could you explain what that is?

    Lieschen Gargano:

    Yeah, so the Lean Agile Center of Excellence can look a few different ways depending on your organization. At our organization, it is the coach, release managers, RTEs and Scrum masters or team coaches. And some larger organizations than ours might have that hub and spoke model of a centralized change leader. And then RTEs and Scrum masters that are in different arts and around the org. And some even have separate laces in different parts of the organization if it's really big. But really they are that community of practice that holds your lean Agile practices and the standards of those practices and talks to each other and debates and evolves them to make sure that it's consistent throughout the org. That the org is getting consistent coaching, consistent guidance, and they're not being told five different things about how to transform. Because again, change and being lean is so hard. If you add too many voices into that coaching, it gets really overwhelming for folks.

    Caitlin Mackie:

    Yes, 100%. And an Agile transformation is already overwhelming as it is, so you can imagine that laid on top. I suppose speaking, if we explore a little bit around those on an agile transformation journey, at what point would you say it's important that that lean Agile Center of Excellence is formed?

    Lieschen Gargano:

    Oh, I think it should be in place pretty quick. I mean, we talk about training your leaders, training your experts and then doing safer teams and launching trains. You need that Center of Excellence there from the start so that they can go out to the rest of the org that they can do all that training and they can be there to support people through title changes, role changes. Launching an art can feel very scary to folks. If you don't have that in place beforehand, you're going to have a lot to reel in after the fact.

    Caitlin Mackie:

    Yeah, I really like that. It's almost having this really solid foundation and unified voice to sort of go forward and support the rest of the org.

    Lieschen Gargano:

    And it's so great to have consultants support, to have partners come in and help you and to have the right tools, but they need the help of people inside. They need that lean Agile Center of Excellence of employees inside the company to help you be successful. As an RTE, you need your team. Anybody, any tool, any people trying to do a change, a transformation are going to need that Center of Excellence because all those parts, that's what makes the whole.

    Caitlin Mackie:

    Yeah, yeah, definitely. So you mentioned as an RTE, a big tip or trick is to rely on that lean Agile Center of Excellence. What do you think has been your biggest lesson learned as an RT?

    Lieschen Gargano:

    There are a few things that have been particularly difficult for me. One of them is that I don't like to say no and not in that I take on too much or whatever, but more in that if someone has passion for something, I want them to be able to take it on. I want them to be able to move forward with it. And there are times where we really have to say it's too much change. It's too much for this group to manage. In particular, the Scrum Masters and RTEs people come to us for a lot of things and they need that consistency from us, and they need predictability in a change to feel like we know where they're going and if we introduce too many things or if we try to hold too many things at once, it's easy for us to forget about it later or drop something else. So learning when and how to say no, again not necessarily in that capacity way, but just in the width of change, if that makes sense.

    Caitlin Mackie:

    Yeah, definitely. I think that what you just said there, learning how and when to say no. I think that's not even exclusive to the RTE role as well. I think that's an amazing piece of advice for anyone listening and to share across our audiences, because I know it's definitely something I struggle with as well. So that's my takeaway from this is to, okay, I'm going to constantly imagine like 'no Lieschen told me to when and how to say no', and just focus on that. So yeah, I think that's a great piece of advice. What was your journey like to an RTE? I know we caught up last week and I got a little sneak preview into this, and I know it wasn't straightforward, so if you can share a little bit about that, that would be great.

    Lieschen Gargano:

    Yeah. I actually started in conflict resolution. I worked in public private reconciliation doing a lot of natural resources facilitation, so hundreds of people, governments, companies, private landowners, residents, trying to bring all those people together to get to consensus or at least to build relationships that allow them to move forward. So really strong foundation and facilitation in particular, and just day-to-day conflict. When we say conflict, we get so worried, 'oh, I don't do conflict', well conflict's everything all the time. It's all the disagreements we need to succeed in life. So that gave me a great foundation when I became a scrum master, and I did that for a few years working with development teams. One of my favorite teams was our infrastructure team, 10 foot pole because no one wanted to touch their work or the 10 foot pole, and I learned so much there and eventually became a coach and started doing more strategic planning and coaching parts of the organization that weren't used to being on arts. Marketing and other groups, which helped me transition to Scaled Agile, where I started working with our CMO and as he grew the marketing team, helping coach that marketing group into an agile way of working, a safe way of working, before actually becoming a product owner, because I loved organizing around value, and I loved those different topics that we were working on internally.

    And one of the people I work with at Scale Agile said, "well, help us develop the product then for everybody else". So I did that for a little while, which gave me so much power in that learning how to say no and prioritize and coaching people to decisions is one thing, but as the product owner, I had to practice being where the buck stopped. There are five right decisions, just make one so that people are unblocked, and that prepared me really well for transitioning into RT.

    Caitlin Mackie:

    Yeah. You have such a wealth of experience there across so many different roles, and you can really see that each of those key roles have taught you something valuable that you can take into this RTE role. So I think that's amazing. It's so cool to see that even though it's not this straightforward linear journey, there's all these parts that there's traits within each that ladder up to helping you succeed as an RT. So I think that's really cool.

    Lieschen Gargano:

    And I know people are afraid to make some of those lateral moves sometimes, but the skills that you can build might just be that thing that gets you other open doors that you didn't even think about.

    Caitlin Mackie:

    Yeah. Yeah. I absolutely love that. Yeah, just embrace every opportunity for what it may be, what it may not be. You don't know until you give it a shot. So I think, yeah, I love that. I think that's really great advice. So everything we've spoken about in regards to being a Release Train Engineer may have really hit the spot for some of our listeners. How does someone get there? Were there certifications, courses? What's the process that way?

    Lieschen Gargano:

    Another thing I probably did backwards. I started with a scrum master cert and then actually ended up getting a SPC certification through Scaled Agile when I was a coach. Because I was a coach before I was an RTE, and I learned about so many other parts of the business that way. But then to become an actual RTE, taking the safe RTE course, but then actually there's a community of RTEs... Which we didn't really talk about this, but being an RTE is a lonely thing. I said earlier, if you're lucky to have another RTE, this is a lonely role. You're really kind of on your own. So not just getting that cert, but being part of that community and being able to send people messages and ask them crazy questions was part of my certification process, but also just community building to where I could feel like I had the connections and competence. So yeah, I found all of them similar to holding each of the roles, also getting that certification, just another tool in the tool belt.

    Caitlin Mackie:

    Yeah, for sure. I don't want to touch on something you said there about an RTE being sometimes quite a lonely role. What do you think makes it lonely?

    Lieschen Gargano:

    It's a role that a lot of people have strong opinions about what they need and what success looks like based on where they are in the organization. And there are usually few of you, and even if you're in a large organization with many, you're with your art, you're very focused on your section, and so having all of those pulls and expectations and not having anyone who understands what that feels like just makes it kind of lonely. Now that we have two RTEs and a coach at Scaled Agile, it makes a big difference for me because they are right there in it with me and it's very helpful.

    Caitlin Mackie:

    Yeah. You can see in that scenario why that community of RTEs is like you said, so important to lean on them as well. Yeah.

    Lieschen Gargano:

    I find even just connecting to RT's outside our organization too. I grabbed beers with one a couple weeks ago. Those little things, even if you can find that person, meet them at a summit, meet them out in the wild, find them on LinkedIn and just say, "Hey, we live in the same area. We have the same role". It can go a long way because it may seem weird to reach out like that, but they probably are looking for that connection too.

    Caitlin Mackie:

    Thank you so much for sharing. And for any of our listeners, I might pop some links to any certifications and some scout Agile courses. I'll pop that in our episode notes, so feel free to check those out. You mentioned about connecting with other RTs and meeting at summits, which is a really nice segue to the next part of our conversation. Just around the corner is the 2023 Safe Summit and we're heading to Nashville Music City. What can we expect from Safe Summit? What are you looking forward to?

    Lieschen Gargano:

    Well, what I'm most looking forward to is that I am putting together an RTE breakfast. So all RTEs are welcome, or even if you're a solution train engineer or you do the role of an RTE with a different title. I'm really excited to meet with those folks over breakfast and just chat it out. And my goal with that really is to have people to connect with so that as we go through the rest of the summit, listening to the talks that we have people enroll, that we can check back in with over drinks and stuff on the later days and say, 'oh, what do you think? How might that work?' So that's what I'm most looking forward to.

    Caitlin Mackie:

    Amazing.

    Lieschen Gargano:

    But obviously there are going to be some great talks and the product labs are always really fun. We get to play with the product together.

    Caitlin Mackie:

    Yeah, cool. Tell me a little bit about the product labs, what's involved in that?

    Lieschen Gargano:

    The product team puts it together and they have computers set up and you can bring your own and they talk through some of the new releases or things they're working on and help you log into it and use it in your context, but also try to get some feedback on how it works or how you might use it in your organization. So it's a nice two-way street. It's sort of, 'I need this, how might I do it?' And then them saying, 'well, why don't you try and let me see how it works and how we should change it based on how you interact with it'. So it's just really fun. It feels really practical because it's so hands on.

    Caitlin Mackie:

    Yeah, amazing. I love that. I'm definitely going to have to try and come along and suss that out. It sounds really great. Where do you hope or where do you think we'll see a lot of conversations focused at this year's Safe Summit?

    Lieschen Gargano:

    At Safe Summit I think the conversations will be really focused on just the day-to-day of Safe. We have new topics that come up. We obviously have new ideas that are going to be presented. But every time I go to one of these, it really is the connecting one-on-one to say, here's where I'm stuck, here's what I'm trying to learn. So we'll hear a lot about Flow, we'll hear about Team Topologies, but we'll also hear those 'I'm just getting started and we're stuck, we have change fatigue. We don't know if our arts are set up correctly'. A lot of those classic conversations that are just really impactful and why people come together.

    Caitlin Mackie:

    Yeah, definitely. Yeah, I love that. Creating these spaces for people to bond over shared experiences and problems they're facing or wins they're seeing and sharing them. I think that's where these events are amazing for creating that kind of environment. Lieschen, this is my very first Safe Summit. I haven't been to one before and I'm really excited. What advice would you have for first time attendees, returning attendees, what's the way to get the most out of Safe Summit?

    Lieschen Gargano:

    If you're attending with other people from your organization, the best thing is to split up so you can cover more ground and then come back together and share. The second advice is find people with a similar role as you, because again, you can do that same thing with those folks and split up and then meet up again and try to talk about it in your context. It's great to do that at the parties too, because we throw great parties, but that's the best because no matter what room you end up in, what talk you end up at, you're going to get a great nugget. But where it really sinks in for me is talking with someone else about what I heard and then thinking about, 'okay what does that mean?', when I go home.

    Caitlin Mackie:

    Amazing, great advice Lieschen. If anyone listening happens to also be attending Safe Summit and they see Lieschen on the floor or myself, make sure you say hello, and if you've got any questions for Lieschen about the podcast episode, I'm sure she'll be more than happy to answer and engage in a great conversation. And anyone looking to get advice around the RTE role, make sure you find her and have a chat. Lieschen I'm really excited to meet in person. We've done this podcast with yourself in the States, myself in Australia, so I'm excited to connect over in your world. And yeah, really thank you so much for your time. I hope you enjoyed the episode. I know, I sure did.

    Lieschen Gargano:

    I did. Thank you.

    Caitlin Mackie:

    Thanks, Lieschen.

  • Text Link

    Easy Agile Podcast Ep.23: How to navigate your cloud migration journey

    "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.