See how your team compares with these benchmarks

Easy Agile Podcast Ep.14 Rocking the Docs

Listen on
Subscribe to our newsletter
  • website.easyagile.com/blog/rss.xml

"I loved having the space to talk about common interests - all things technical documentation & information architecture" - Henri Seymour

On this episode of The Easy Agile Podcast, tune in to hear Henri Seymour - Developer at Easy Agile speak with Matt Reiner - Customer Advocate at K15t.

Henri & Matt are talking all things technical documentation (we promise this episode is way more interesting than it sounds! 😉)


✏️ Considering technical documentation as a product
✏️ The value of well written documentation
✏️ Why you should be digitally decluttering often
✏️ Information architecture

So many golden nuggets in this episode!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Henri Seymour:

Hi, everyone. This is the Easy Agile Podcast. We've got an episode today with Matt Reiner. I'm your host for today, Henri Seymour, developer at Easy Agile. And just before we start the podcast, I'd like to acknowledge the traditional Australians of the land on which I'm recording today, the Watiwati people of the Dharawal nation. Pay respect to elders past, present, and emerging, and extend that respect to any Aboriginal or Torres Strait Islander people listening to this episode.

Matt is an experienced content strategist with a history of working in the computer software industry, skilled in agile scrum framework, related tools, communication, technical writing, video production, customer interaction, strategic planning. And he's here today to talk with us about writing and specifically technical writing and documentation. Hi, Matt.

Matt Reiner:

Hi. It's great to be here. Yeah, I'm Matt. I'm into all sorts of content things. And one of those is technical writing, which is, I think more interesting than it sounds. I guess you'll have to decide by the end of the podcast, if you think so.

Henri Seymour:

Technical documentation experts. So when you talk about technical documentation specifically, what do you mean by that?

Matt Reiner:

Well, I feel like that term is actually in the middle of a big change right now. In the past, technical documentation was very strictly like, "Okay, we're a team, we're making a thing, a product." Maybe it's an app, maybe it's, I don't know, a go-kart and we need to have a user manual for that. Technical documentation was someone sitting down and writing down, "Okay, here are all the knobs and switches and here's what they do. Here are all the features. Here's maybe why you would use them."

So putting together that user guide, which traditionally was printed material that you would get with the product. But it's become a lot more over time, partially with the internet, because we can just constantly iterate on content like many of us do with the products that our teams make. And then also we are seeing it in new forms. Maybe it's not a printed piece, in fact, most people do not want printed technical documentation anymore, they want it online. Or even better, they want it right in context in your app when they're using it, they can just get the info they need, and then get on with it.

That's what technical documentation is. It's supposed to be there to help you do the thing that you really care about and then get out of the way so that you can do it.

Henri Seymour:

Do you have a description of why good technical documentation? Not just having it, but having it at a good quality in a way that really helps your users, is so important to product users.

Matt Reiner:

Well, I suppose we all find those points in our day or in our journey that we find ourselves in where we want to accomplish something, but we don't know how to do it. So a lot of us have really gotten very used to jumping on Google and saying, "Okay, here's this thing I want to do, how do I do it?" And good technical documentation is there with the answer you need, the explanation you need. Because really ultimately all of us are smart people who should be empowered to do the thing we're passionate about.

And technical writers and communicators who are really all members of our team. People who sit down to create good technical documentation uses few words as possible to get a person on the way they're going. And that's like, when it happens its just like, "Glorious," not to the user. They don't even know that it happened, they didn't even know that they read your writing. But to the writer, it's like, "Yeah, I did it, I did it. They don't even care what I did, but I did it." And now they're doing the thing that really matters.

Henri Seymour:

That's great understanding one of the major differences of like, I've written something and I don't want my user to be spending time on it. I want as little time spent reading this as possible.

Matt Reiner:

Yeah, yeah, yeah. You can have great pride in your work, but one of those metrics that a lot of people look at for websites is time spent on page. So sometimes you can fool yourself into thinking, "Oh wow, they spent 10 minutes on my page. That means my documentation's really good." But also that might mean that it's not very good and they're having to reread it over and over again. So the true metric is, did they get to the thing they really cared about? And unfortunately, it's hard to measure.

Henri Seymour:

You mentioned now that with the advent of the internet and giving you the opportunity to iterate on those docs in a way that you wouldn't be able to with printed documentation. That iterative thing brings the agile process of iterate on something that you already put out and improve it in the same way that as a developer I do for products. Can you tell us more about that iterative agile sort of process?

Matt Reiner:

Oh yeah. Yeah, it's so true. Documentation used to be back in the waterfall standard, more typical product project management days, documentation was a major part of it. You'd start this project by writing these massive documents of, "Here's what we're going to set out to do. And here's all the considerations, and here's how everything's going to connect up." And that did work really well for a lot of hardware. Which was the thing that we made for a long time. Just everything that humankind made was hardware often, as groups anyway.

And then all of a sudden this whole software thing comes along and we're trying to build that like it's a physical thing. And we get to the end of this two-year software project and people are like, "Yeah, that's not the thing that I wanted." But we're like, "Oh, but we go back to the beginning and look at that documentation, and that's what you said you wanted." But now with the internet and with just agile development, we really need to move away from this place where we start with a pile of documents. And then we develop another pile of documents as our, I don't know, development guidelines.

And then our test plans, and then finally we end up with user documentation. Instead, these days, documentation should really just grow from a very small piece of content throughout that whole agile development cycle into that final user documentation. Because it doesn't matter what we set out to make, it matters what we make. Nobody he wants to read about what we thought we would make, that's straight up fiction. And it's probably not an interesting read. It's really that final user guide that comes out of the agile process, but that's a big change, but it's a good one.

Henri Seymour:

I love that idea of just like, this is gradually growing. There is no specific start block and end block. It's a process. And you mentioned the opportunity to iterate on those documents. Do you have any advice for after you've published digitally your technical documentation from iterating on what you've already got there, improving that over time?

Matt Reiner:

Oh yeah. I know every agile framework is different, but they all have that feedback phase, where... And really that's throughout the whole process, but we do need to dedicate some time. So, there's a lot of different things we can look at. For example, I don't want to say basic, a standard one that we should be looking at is, you should have a help center, where you can implement something like Google Analytics so you can see just, what are people looking at? How long are they looking at it?

Another really good one is, you have to set it up separately in Google Analytics. What are people searching for on your site? You can also use Google... used to be Webmaster Tools. I think it's called Site Tools now, but you can see what were people searching for on Google before they came to your pages. That's all really, really valuable stuff. Then you can get more advanced. You can look at pointer tracking, apps that you can embed on there, which you get some pretty wild stuff.

But then you also, you want to consider having a forum at the bottom of each page like, "Was this helpful? Was it not helpful? Oh, it wasn't helpful? Tell me why. Oh, it was helpful? Tell me why." Just like a YouTube creator, they look for that feedback. That feedback is essential, the thumbs up. In fact, it's very controversial, YouTube just announced that they're going to hide the thumbs down numbers, but a lot of creators are like, "No, no, no don't do that because that communicates the value of this video that is out there."

So there's a lot of those signals. And then there's just really soft signals that, it's hard to know if people are using the content or not. Because you may never hear. Especially, if it is one of those things that they just get in and get out, you're not going to hear anything about that. But the feedback phase, it's really great to... Anytime you're getting feedback on your product that you're making, try to get your documentation out there as well. Because that's the time where people are open to exploring your product and giving feedback.

So why not explore that same documentation, the related documentation to see, "Okay, is this actually helping these people do the thing that they want to do? Or should we improve it just like we do with the product?"

Henri Seymour:

No, that's a really good, comparing the, we've just released a product. Give us feedback with doing the same thing with the documentation. Because that's when it's going to reach its peak use before everyone's got the hang of it. We've just done this feature release, let us know how you go using it, and the documentation is in a sense part of it, especially for more complex products.

Matt Reiner:


Exactly.

Henri Seymour:

Do you have any background in the customer support side of things? We do customer support in-house as well as their documentation. So we're trying to improve the documentation to lower the support load on our team. Do you have any background in that... Can you solve it?

Matt Reiner:

Yeah. Well, yes and no. It's interesting. I work at K15t now, I used to be a customer of K15t's, so that's actually how I met the team. And that was also how I met documentation in the first place. At my last job, they brought me in to administrate this system called Jira. And I was like, "I don't know what that is." I told them, "I thought I could do it." And I figured it out, it was this little thing called Jira On-Demand, which is now Jira Cloud. And I introduced Confluence On-Demand to the company as well. And wow, I broke Jira a lot of times.

Luckily it wasn't like mission critical at the time, we were still really figuring it out. But it was through Atlassian's documentation on Jira that I really learned like, "Wow, there is tremendous value to this content here." And then I discovered, "Okay, how is Atlassian creating their documentation? Oh, they're doing it in Confluence. They're writing it in Confluence. They're using these apps from K15t." And so I started using those apps, and then I talked a lot to K15t customer support, just questions and how do I get this started?

And we also do our support in-house, so it's really great. So maybe as a customer, I overused it, I don't know. I should ask some of my colleagues if they got sick of me. But the benefit was very clear because they would send me, "Oh, here's documentation on this. And here's the answer to this question or here are the considerations you should keep in mind." And actually several of our teams now, we're really looking at, especially, for those features that are very robust, people have questions.

So it's like, how can we enable them to help them help themselves? And putting those resources out there is one thing, making sure that Google can find them, well, is another. But that is a really important thing, especially, since as a product team, when your user base grows, so does your need for support. It's just... I don't want to say it's exponential, but it's in line with each other. And so, one of the ways you can mitigate that is, making sure you have good design so that your product is easy to use. And then another is you need to have good content all around that entire experience so that you don't have to keep hiring more and more support people.

Or your support people can specialize and really focus on those deep entrenched issues, and then the documentation should help with the rest. But the secret sauce there is tricky. It's hard to write the perfect content to deflect the cases. That's everybody's dream.

Henri Seymour:

Even if it is just not all of them, but some of the common use cases start to get deflected away from support because people can self service. It does make a difference. And I really understand the idea of Jira documentation as well. Easy Agile works on Jira and it's... Jira is an incredibly complicated product at this point, and I imagine it probably was also complicated when it was Jira On-Demand. Because it's so complicated and so detailed, there's no way to make that easy to understand for a user without that documentation. There's no getting around that one.


Matt Reiner:

Yeah. I think there should be a club for the people who have broken workflows too many times in Jira. But yeah, I mean the documentation saved me many times and I would have to put out a... Well, it was a HipChat message at the time. May it rest in peace and I'd have to say, "I broke Jira, give me a minute. I got to go read something." Not the way you want to learn Jira, but it's an option.

Henri Seymour:

It is. Sometimes you learn things by breaking things. That's-

Matt Reiner:

That's right.

Henri Seymour:

Really seems like my experience in software so far. You try to break the things that people aren't currently using and that's about all you can do.

Matt Reiner:

Exactly.

Henri Seymour:

So K15t has recently published Rock the Docs. Can you tell us a bit more about this project?

Matt Reiner:

Yeah. Rock the Docs, actually, it came out of a lot of that information that I got from K15t. Customer support, I got from K15t documentation, I got from Atlassian documentation. And then some of the stuff I figured out on my own, or some of my colleagues at K15t did. Essentially like, what are the best practices for creating really good content in Confluence? And it really started with a collection of guides on how to create technical documentation content. It's geared toward like making a public help center, but really it's for any kind of content that you want to be like evergreen, longstanding content to be able to help people.

So we initially talked about all sorts of things like structuring your content, content reuse, managing multiple languages, which can be tricky in Confluence. Collaboration, publishing your content outside of Confluence in one way or another, managing versions of that content. So, that's the start of it. And then we saw a lot of positive response with that and we had more general questions like, "Okay, but what are the best ways to get feedback in Confluence?" Or, "How do I make a template or a good template or how do I make a good diagram in Confluence?"

And so we've grown that content to focus on just all sorts of general Confluence things. Because we found that there's a lot of information out there on how to do something. Atlassian documentation really helpful, but there wasn't as much, I'm like, "Why would you do it? And why would you do it this specific way?" And we've been working with Confluence for over 10 years now. Like I said, I've been with Confluence since the crashy early cloud days. It's grown up so fast, it's beautiful.


But we just know we've done a lot of stuff with Confluence, so it's been a real privilege to share that both in like these written guides. And then actually recently we've started publishing a series to our YouTube channel as well, all about Confluence best practices.

Henri Seymour:

That's great. It's real interesting to hear how that started as a smaller project than it turned out to be, because you could see the value in it and the use in it. We've discussed Confluence a few times now and K15t builds apps that use Confluence as a documentation source. Can you tell us more about what makes Confluence useful for building technical documentation? What sort of tools and approaches that make it useful in this context?

Matt Reiner:

Yeah. Confluence is by nature open, which is not the way technical writing tools are built. In fact, I remember the first time I went to a technical writing conference and someone asked me, "Oh, what tool do you use?" Which is like, what technical communications people talk about, because we're all nerds in that way. And I was like, "Oh, I'm doing it in Confluence." And they didn't really want to talk to me after that because they didn't think I was a serious tech writer. And I was like, "Oh no, no, no, no, this is all happening."

At that point, Rock the Docs didn't exist. So I couldn't be like, "Go over there and see how it works." But the biggest difference is most tech writing tools are just totally locked down. You have two licenses for your two people who are trained professional tech graders, and then everybody else, there's no access. You don't touch it. Maybe your tech writers will send you a PDF and you have to go through the God awful process of marking up a PDF to tell them like what to correct. Or, I've heard of teams printing out the content and people penciling in what needs to be changed.

The review processes are just out of this world insane. And those tools don't fit terribly well with agile processes because it's like, you build the thing over here, and then here's the two tech writers over here in their separate tool. And at some point we'll be like, "Okay, this thing's done. Would you write about it?" So with Confluence, the benefit of using Confluence is, it's accessible to everyone on the team and even people outside the team. And that's incredibly by an official because we've seen with agile, but we're also seeing in this technical communication and in information design field, that teams are less and less looking for those specialized individuals who are trained tech writers.

Which that's an oxymoron because half of us, we don't have degrees in tech writing, we fell into it for one reason or another. But now teams are starting to see, "Hey, I can be a code developer and an information developer. I might not write the final piece of written content that is seen by our customers, but I might write the first draft." Confluence really opens that up for everyone. And especially with like at mentioning and inline comments, review processes are just so fast.

Actually, the reason that I switched to Confluence at my last job, was my product manager threatened me and said, "I will not mark up another PDF. Go and find a good tool that we all want to work in." And that's where we landed on Confluence. It's about bringing the whole team into the writing process instead of having it be this separate thing. Because when it's a separate thing, we lose track of it. And content, we forget how important it is to our product, to the customer life cycle, to... God bless customer support, who really, really need that content to be good and accurate.

And it needs to be seen by the real experts who validate, "Yeah, okay, this is correct. This will actually show people how our product works." And Confluence is like the heart of that.


Henri Seymour:

No, it's great to hear how that all comes together to build the documentation as a team. Can you speak more to the different roles in, specifically in software development and the different roles you're looking to get involved in your documentation process? We are working on building our specific app teams here at Easy Agile as we're growing at the moment.

Matt Reiner:

Yeah. That's such a good question. Well, what-

Henri Seymour:

And how do you incorporate... Sorry, this is more specific to my question. How do you incorporate that technical writing process as part of the work of an agile software development team?

Matt Reiner:

Well, first, it starts by rethinking priorities because most teams are like, "Documentation down here, testing and then everything else above." So generally, those two things should be moved up. And actually, the content around our product is... I don't want to sound over traumatic, but if we don't have information, we don't have a product. I don't care how much code you write. If we're not explaining it to people, if we don't have good UI text, if we don't have good in-app help, it doesn't exist. It's not a useful tool, it's just a set of mathematics that humans can't interact with.

So content is essential, so it's really important that we elevate it to the position where everyone on the team recognizes that the content experience that our users have is the product experience they have. So it needs to be part of the product development process. So then the next step, which I know you're talking about team structure, but the next step is really everyone on the team needs to know they're a writer, and they're a good writer. And that's important because a lot of people have never heard that. They've never heard that they're a good writer, and they probably have never heard that they're a writer.

I remember going through university, my writing classes were the things that I didn't pay attention to. I was doing mathematics, and Java programming, and statistics. Even that seemed more important to me, not the writing classes. And then sure enough, it turns out everyone has to write. We all write. So knowing that that is a role that everyone fills is really important. And then when it comes to actually team structure, you need to have individuals who are willing to cross the streams, so to speak. If you're bringing in someone who's focusing on test engineering, they need to realize that the test plans they're writing are very similar to a lot of user documentation that needs to be written.

They're writing task topics, or task instructions, do this, do this, do this over and over again. That's documentation. They could be contributing in that way. Engineers, as I mentioned, they could be drafting the first copy of a lot of what are called concept topics. So areas of documentation where you explain concepts, because they already know what those concepts are. In fact, if you look at the root of a lot of agile development teams, they're using epics and user stories and acceptance criteria. And all those map perfectly into the documentation you needed to create for that new feature you're working on or feature you're improving.

So really, it's essential to have everybody recognize, we are all already creating documentation, so we can contribute. And then of course, you really do want to have at least one probably native English speaker. Maybe not native, but someone who feels confident in their English or whatever language you're authoring in. English is typically the cheapest one to translate to other languages, so that's what people go for often. But that person's the person who takes everything everybody's written, gets it to the right style and tone. And then gets it out there. That's what we are seeing be successful.

Like our teams right now, we don't have any legit tech writers. We have product managers writing. We have product marketers writing. We have engineers writing. Some of the best documentation I've ever read was from one of our German-speaking engineers. I was like, "Peter, this is an amazing guide. You got to get out of this Java and get into English, man. It's great. It's great." So he's done a few, which I really love. But yeah, it's about jumping out of your typical roles and realizing, we're all documenting this stuff, anyway.

Henri Seymour:

I love the focus, especially with your German-speaking colleague. The focus on, it's not just that you must write the documentation because you know how the product works and we need that written down. It's, you are capable of writing the documentation, you can do this. You have that added barrier of safety with somebody who's got the language proficiency that they're going to massage it and edit it at the end.

So, before it gets anywhere, anything that you do is going to get filtered out if it's not working. But you don't need a specific tech-writing background to write the docs.

Matt Reiner:

No, absolutely not. In fact, there's an entire community of what... They call themselves documentarians called Write the Docs. And that whole community, that whole group is focused on, it doesn't matter what you do, it matters that you care about writing the docs, contributing to the content. And that's been a big shift, I think in the industry, where people thought we're separate. But now it's like, "No, no, no, we are all able to do this." And once we can respect the contributions that each of us can make.

And then also, I have that protection of somebody else is going to have their eyes on this, which even my writing, I'm like, "I don't like to send it out until someone else has seen it." Because I make spelling mistakes and typos all the time. I really want to have another colleague look at it. Even if they're not native English speakers, because they catch my typos pretty often. That feeling of togetherness, it's the same way that we feel when we ship out a project or a product.

Whether you did the testing for it, or you wrote the code for it, or you did the product marketing for it. It's like, "It's our baby. Let's send it out and see what happens." Content's the same way.

Henri Seymour:

Yeah, part of my daily role and [inaudible 00:28:03]... We don't have QA team separate from developers. Our developers also review our code and it's that sense of, "I wrote this thing, but I have one or two other people who've refined it, who've made sure that it's good enough quality. They've got that fresh eye, so they'll see the spelling mistakes, they'll see the minor little errors that I've just been looking at it too long to notice anymore."

I found the documentation writing process has some parallels in there like, "Here's my thing. I'd like some feedback on it before it goes out into the real world."

Matt Reiner:

Yeah.

Henri Seymour:

That's great.

Matt Reiner:

Yeah, absolutely. Yeah.

Henri Seymour:

All right. Can you talk a bit about the difference between the customer-facing documentation that we've mostly discussed so far and internal documentation?

Matt Reiner:

Yeah. There are some differences and there are some major similarities. So this very... It sounds very technical and ugly. The term information architecture, it's really important with any kind of content, internally and externally. And really that's like, if you're a developer you're familiar with XML, you're familiar with structuring things in that way. Our content needs to work the same way. And that goes for internal and external documentation. So, many of the things that they use, writers, when they write a page or an article in the newspaper, they'll use that Pyramid approach, where they put the broad bits of information at the top. And then they slowly focus in on the topic and give more and more information about it.

But you want to make sure that if somebody only reads the first paragraph, they're getting a rough idea of what the information is. And that's really important for successful Confluence pages and spaces. People should be able to start at the top level of the space, understand what the space is about, and then be able to navigate down into the thing that they really want to learn about into the page itself. Which should then be using headings and subheadings and bullet points to get, again, just disseminate that information and break it down. Because everybody skims.

We need our content to be skimmable, our spaces need to be skimmable. And that kind of content also makes Confluence search happy, especially the new Confluence Cloud search, which has been greatly improved. There's a whole new elastic search base to that that's being optimized. But it's happy, it's just like with Google when we structure our content like that. So when you have a page that is just a wall of text, no headings, you're not breaking it up into pages or even spaces, nobody's going to be happy with that.

The bots aren't going to be happy with it, the people reading aren't going to be happy with it. So it takes a bit of work to structure, break up the structure of our content. It's probably all good as long as it's up-to-date, but it's really essential that we think about, how do we structure that in Confluence so that people can find it and people can skim it? And that is what seems to plague a lot of internal Confluence instances, because a lot of... Maybe the team isn't so focused on that.

It's like, "Oh, our external help center that's come coming from this space over here, that's fine. Our team space, hot mess, total tire fire." And nobody cares because they think they know where everything is. But then you start to think about, "Okay, but what about the new team member? How do they find something?" Or, "What about the team member who's been away for Paternity leave for six weeks? Are they going to remember where everything is or know where all the new stuff is?


What about folks with disabilities? Is it going to be much harder for them to navigate to the information they need? Because they're working with a screen reader and they're trying to go through a wall of text. They need headings, a screen reader relies on those headings and titles." So there's just so many considerations that really leadership of companies needs to understand, just because you have a process to do something or the information is somewhere, doesn't mean you don't have a major information problem. And maintaining all of your content in Confluence and then maintaining it well.

That is what enables people to avoid the frustrations of searching for information, losing information, having to relearn or rewrite information. I have worked at too many companies that just information sieves everywhere. I don't even want to call them silos because nobody knows where stuff is anymore either. That's what Confluence brings to things, and that's what matters with internal content pretty much as well as external.

Henri Seymour:

That's a great perspective on it. And I can see the silos, it's a really more... Just a one big pile, you can't find anything. I've been-

Matt Reiner:

Exactly.

Henri Seymour:

... at Easy Agile for more than half of its life now and I've got that sense of like, "Oh, I know I wrote this down somewhere. I know I've seen this written down somewhere." And we are making a habit, especially as we're hiring more and more people. Every time somebody's going through onboarding, they're going to be looking at all of this documentation with no previous background on it. And we want to hear their feedback on it specifically. Because if it works for them, then that's the documentation that we need for them and for everyone after them, and for everyone who's already here.

Especially, I've been at Easy Agile for almost three years now, and I've seen it grow from eight people to now we're up to high 20s, I think. We're going to cross over into the 30s by the end of the year.

Matt Reiner:

Wow.

Henri Seymour:

The growth of information that we have in our internal documentation, and I'm sure it would parallel the growth of the product documentation for a product that's been expanding for three to five years. How do you manage the documentation and the Confluence spaces as the team and the company grow and you just develop more and more pages out of it?

Matt Reiner:

That is the question since the dawn of the universe or at least the dawn of Confluence, which, what's the difference? The biggest thing is team responsibility, so knowing this is our space, this is our content. And not like in a territorial way, but this is our responsibility. Much the way we should think about our planet, we should also think about our content, keeping it groomed and taken care of, and up-to-date and accurate. And then as things change.

For example, we have a product called Scroll Viewport, which is actually what enables you to publish content from Confluence to a public health center, which is really, really cool. So with that, we had a server and data center version. We've had that for quite some time. That's what I was a user of. And then we set off to develop a cloud version, and cloud requires a whole bunch of new infrastructure, which is a lot of fun and very challenging, but it's a totally different beast.

It's not like you can just lift the server code and just drop it into cloud, which is what as a user I asked them to do for years, "why isn't this on cloud?" Now I know why. So we created a new team that started off this Scroll Viewport on cloud effort. And it was just a very scrappy project at first. And I remember the first page we got up there, it's like, "Whoa, look at this page we published." And then it progressed from there. But then at some point, we needed to bring the two teams back together. And what we could have just said, "Oh, this old Viewport space, whatever. We're just going to leave it there and then just go on with the new one."

But instead the team took time and brought the two spaces together and really went through the old content in the Viewport Server and data center space to say, "Is this all still relevant? Do we still need this?" So it's been reordered in such an amazing way. Several of our teams have gotten really good at making these spaces so that I can come in. Because I work with all of our teams, just get in and find what I need, even though I'm not working their day-to-day. I'm just so glad, I'm so proud of the team for not just letting that space languish somewhere or being afraid to delete or archive content, which a lot of people are.

It's like, "No, what if we lose something?" It's like, "No, no, no, we've moved past this. We really do need to delete it." So that's the kind of attitude it takes is, our teams to split and expand and grow, and we need conscious of that content. Because again, think of the new person, think of the person who's learning something new. Think of the person who maybe does have disabilities and is trying to get the content they need. They just don't have the background that you do. Having been with the company for half its life, you know how to dig through the thought pile to pull out just the thing you want, but they don't.

Henri Seymour:

Yeah, and I don't want to be the person that they have to ask every time they need information, "Hey, can you find this for me?" No, no. I want to build a system that means that I don't have to answer the same questions all the time. That's one of the reasons I've been doing internal documentation so much since [inaudible 00:37:36]. I've answered this question once, that will do.

Matt Reiner:

Yes. That's a really good way to motivate any contributors to documentation. "Hey, you know how you wrote that piece of our app that one time and then everybody's asked you about how it works ever since? Just document it once and I promise you can never answer it again." That's good motivation right there.

Henri Seymour:

It is. As well, we've got a team on support models, so I'm working on the store maps and personas, product development team. And that's the same team that gets all of the support requests about story maps and personas. So yeah, the better we make the product, the better we make the documentation, the less of our time every morning we spend doing that. And the more we can get back to our regular jobs.

Matt Reiner:

Exactly.

Henri Seymour:

It's been great for helping us keep in contact with the customers and what they're doing and what information they need when they're using our product. You mentioned that like it's necessary, it's valuable to be deleting an archive-based stuff, pages in Confluence from time to time. When you're looking at a page and wondering whether or not it's time to go, what sort of questions are you asking yourself?

Matt Reiner:

Well, a great one is like, look at the last modified date on that page. That's general a pretty good sign of like, "Are people even looking at it?" In fact, if you're on cloud premium and above, you can look at some great metrics on every page to see like who's looking at this thing? Is this valuable? What are the views like? Just the same way that you would look at your external website to see if your content is valuable or effective. But typically, we have a lot of debris left over from product development or team activities.

Like if you're in marketing and you have a campaign from three years ago, do you really need all of those detailed pages? Maybe keep the overall campaign page, maybe that's useful, but do you really need everything? If you're into testing, do you really need every test plan you ever created? If you're in the legal team, do you really want your legal terms from 10 years ago? Maybe, maybe, I'm not in legal. But often we have this fear of, it's like fear of missing content.

It's like, "Oh no, if I get rid of that, then I won't have it." But information, just like language, just like the way we think, just like the way our teams grow, it changes. And so we need to be aware of that. As we are changing as a team, you should expect our content to change. And part of that is shedding that old stuff. So it's always worth it, like if you're questioning it, ask another subject matter expert and be like, "Hey, I'm pretty sure we don't need this anymore, or we should revise this. What do you think?" But if nobody has any qualms, you should probably delete it.

Henri Seymour:

No, that's great. I am a big fan of decluttering, even digital decluttering. It's, I want people to find stuff and the less pile there is, the easier it's going to be.

Matt Reiner:

Yes. Because somehow bad information is less helpful than no information.

Henri Seymour:

Yes. It's like coming across a question and they're like, "Oh, I tried doing it this way." I'm like, "Oh, that way doesn't work anymore. You're going to have to do... Where did you find that written down? I'll go update out." It's-

Matt Reiner:

Yeah.

Henri Seymour:

... new people doing stuff. The best way to understand where your documentation is falling over. It's the same as you're never going to understand how your product documentation and that your product itself is failing your users until they come to you and tell you, "Why can't I do this thing?"

Matt Reiner:

Yeah. Yeah. In fact that that power of bringing in someone new on your team is so amazing. And it's almost hard to impart like first day of onboarding like, "You have fresh eyes, please use them. This is called an inline comment, please put it everywhere." I remember going through our human resources employee handbook, which we had just created not too long before I joined. And I remember them telling me, "If there's any questions, at mentioned us." And I was really afraid to do that. But we corrected a lot of things.

For example, we mentioned do these things on... What was it called after HipChat? The product that lived and died so quickly.

Henri Seymour:

I think I missed that one.

Matt Reiner:

Oh, the one that Atlassian made and then they sold it to Slack.

Henri Seymour:

Now, where do I even start on that?

Matt Reiner:

How am I... It was a great app, I really liked it. But we mentioned in the employee handbook to use that. And I'm like, "Oh, I think we're using Slack now, we should update this content." That's stuff that HR is never going to go through and catch, but your new employees can do that. New people are the best way to tell you if your processes are bad, if your content is better. Maybe not bad, but they're bringing in something new. That's why we added them to the team. And they should not be afraid from day one to ask questions, or poke holes in our already messed up or failing process.

Henri Seymour:

Yeah. And I can really see the benefit of the tools in Confluence, like that inline comment. Even if you don't know how you need that page updated or what the new version's supposed to be. It's just coming in fresh, you can go, "Oh, this is weird, or incomplete, or it might be wrong." It's just a little comment. You don't have to change it yourself, just say something. Here's a way to speak up without changing it yourself. And somebody who does know is going to be able to change it for you.

I was excited to hear you talk about information architecture. That's something I only got introduced to last year also. Do you have a general explanation of what information architecture is and why it's relevant to documentation?

Matt Reiner:

Oh, information architecture is, there are whole, people, professionals whose entire career is coming in and helping you. So I'm not one of those professionals, I just play one on TV. Really in essence, information architecture is breaking down what would be a wall of text into a pattern of information that anyone's mind can connect to. That's the real and ultimate goal, and that starts by just breaking up logical chunks. In fact, in a lot of pure technical writing, you break the content into tiny, tiny pieces, chunks or some technical communicators talk about atoms of information, really tiny pieces.

And then once you've broken that down and said, "These are separate pieces," then you assemble them together in an order that makes sense. In fact, you can also do really cool stuff with content reuse in Confluence, using include macros and the new Excerpt Include Macro is very cool in cloud, because you can do new stuff with that. But it's really about breaking apart all your content, figuring out what's the order of all of this? What's most important? What's more specific? What is important for everyone? What's important for just a few people?

And then just going down like you would with an XML structure or any other sort of hierarchy and tier that information using your spaces, your pages, your headings. And then finally bullets and paragraphs and that kind of thing.

Henri Seymour:

Thanks for getting that generally explained. Is there anything you want to mention in your work at the moment that you would be interested in getting readers onto?

Matt Reiner:

Yeah, totally. A major new effort for me, because I'm just this content explorer, I guess. I've done like technical content, I've written some marketing content. I started speaking, which I enjoy speaking. I got to speak in front of one live audience before... No, I guess a few, and then, the world's shut down for good reason. Because when you're breathing out on a bunch of people, you want to make sure that you're not potentially putting them at risk. So been doing a lot of virtual speaking.

But recently, I mentioned, we've worked on all these best practices on Rock the Docs. And so we've started this video series about Confluence best practices and it's been very exciting to figure out, "Okay, so I know how to create fairly good in Confluence, how to structure that content. Now, can we make a good video?" And it turns out, no, not at first. Made some pretty poor ones or ones that just took way too much time to make. And finally, as you do with any kind of content, we finally got a good structure, a good rhythm. And we also found what are those things people really want to hear about?

And so we've developed 16 of these now on our YouTube channel that are just out there for administrators to share with your users who are asking these questions. Or maybe these are for users directly who just want to subscribe and get these things. But it's like eight minutes of just as much information as we can pack and still speak fairly legible English. And then show just like how do you do this in Confluence? Why would you do this in Confluence? What are the things you should consider in Confluence? What are the best ways to do things in Confluence?


We've actually just started a series of live streams as well, where we're trying to look at those more in depth and then have people live listening in, asking questions and directing the whole thing. So far those have been really great and we're looking to do more of that. So the more people who pile into those, the more direction y'all get to give that content. But it's been new types of content that it's exciting to see, okay, our good written content in Confluence is coming to the real world in a new format. Which has been cool and challenging and fun and scary all at the same time.

Henri Seymour:

Yeah. That's sounds like a really exciting project. Rock the Docs is going audio-visual. And I can-

Matt Reiner:

That's right.

Henri Seymour:

... figure what... Get users on there to give you that iterative feedback that we talked about at the beginning. And so is this worth the thumbs up? Do you have comments? What else can we do? And especially in that sort of live stream webinar format, you get that direct contact with your users so you can find out what they're needing. That's that's fantastic. Probably see if I can come along with those. Easy Agile started using Scroll Viewport for cloud specifically earlier this year.

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

So that's been a major improvement for us actually.

Matt Reiner:

Oh, good. Yeah. I'm just loving what the cloud team is putting out. It's so exciting and so polished and it's just like every team has that documentation space, and Viewport, it lets you put it out there and you're like, "Ah, looks so great. We're so proud of it." You can read it on any device. It's just like it's the magic that everybody wants, but no team has time. Our very few teams have time to make it look that good, so it's nice to have Viewport just do the heavy lifting.

Henri Seymour:

We've got the Confluence space, we've got the documentation. We don't have to make a website about it. It's just, "Go ahead, please make this website happen. Here's what we need on it. Here's the structure." And golly, it looks a lot better now, even just aesthetically, it looks a lot nice in the house.

Matt Reiner:

Yes. And it's nice to know that like some designer peered over the spacing between navigation items to decide how spaced out they should be. And as a writer, I can just like, I don't have to care. I don't have to care. I can throw in Confluence macros and stuff, and they just look really great when they're published. And I don't know how or why, but I'm happy. I can just keep writing. Yeah.

Henri Seymour:

Yeah.

Matt Reiner:

It would be great to have someone from Easy Agile join us for one of those live streams. Because what we're really focusing on is just like great way to do things in Confluence. We haven't jumped into Jira yet. I'm not as much of an expert in Jira, but I have thought about it because that content doesn't really exist yet. But it's not necessarily app-focused or K15t app-focused. It's just like one of the best ways you've found to do certain things in Confluence, and we're just sharing those with people alive, and it's a lot of fun.

Henri Seymour:

Yeah, that sounds great. I've got the parallel of get really into Jira and making Jira apps and Confluence is, "Yeah, we've got a Wiki. This is where we write stuff down." And it is great to have stuff like "There's the visuals on our docs page." But I don't do those. I'm busy making visuals in a Jira app. I don't want to think about that spacing. I've got my own spacing to do.

Matt Reiner:

Yeah. Yeah.

Henri Seymour:

And it really is that, I can just do the writing, I can just do product. I can do my job more because this other stuff taken care of because the experts at K15t have made that happen. And I hope that our apps can do a similar thing for their users of, this is the thing we need, we don't have to think about this. Bring in this app and it will solve a problem for us. It'll help us see what we need to and organize our information in Jira. Which is a different type of information again, but.

Matt Reiner:

Yeah, yeah. It's funny. I've talked with some people who have actually described that whole app part of Confluence in Jira as App Hell. That's a term that I've seen and I can't help but love the community because we all come up with this stuff. But app hell is, it really comes out of not understanding what a platform is partially. For example, if you're using the Salesforce platform, yeah, that's going to be app hell if you really want Salesforce to be a marketing platform. Because Salesforce is a sales platform. But then there's apps, and Salesforce happens to a sell big one. And then all of a sudden it's a marketing platform.

So that is a really interesting perspective shift for people who are used to a tool that just does one thing. Everybody thinks Excel does everything. It doesn't, we really should just use it for spreadsheets, everybody. It's not a platform for other things. Confluence is really good at these core things, Jira is really good at these core things. And then these apps, they come in to answer the questions that don't have answers and do the things that can't be done. And that's why. So is it App Hell or is it App Heaven? That's the real question. Or maybe it's maybe it's App Purgatory, I don't know. I guess the listeners gets to decide.

Henri Seymour:

The constant stream of, and yet another app needs to update. Which to be fair, I think is not a problem on cloud at this point. That's an exclusively an on-premise problem, the constant app update cycle. But we are hopefully moving towards the end of the purgatory perhaps.

Matt Reiner:

Yes. Yes. I think we're all ascending together. We're just reaching new heights all at the same time.

Henri Seymour:

Is there anything else you'd like to bring up while we talking tech docs?

Matt Reiner:

I guess, I typically go back to when I was in university, I had a manager there who told us in this on campus job that I had, "Our job is to connect people with the resources that are already around them. You're not a teacher, you're just here to connect people." And that has really stuck with me. And that is essentially what we all do. Whether we're building a product that connects people with resources or that is the resource or we're contributing to documentation or some kind of content.

We're really trying to enable people to do that greater thing, that higher level thing that is above our content, it's above our product. It's that thing that they truly care about and any part we get to play and that greater thing, that better thing. That's what it's all about.

Henri Seymour:

Yeah, that's really great perspective. That's probably also a really great thing to round off the end of the podcast with.

Matt Reiner:

I guess so.

Henri Seymour:

Yeah. Thank you very much for joining us, Matt, and for talking all things technical documentation with us on the Easy Agile Podcast.

Related Episodes

  • Podcast

    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.

  • Podcast

    Easy Agile Podcast Ep.20 The importance of the Team Retrospective

    "It was great chatting to Caitlin about the importance of the Team Retrospective in creating a high performing cross-functional team" - Chloe Hall

    In this episode, I was joined by Caitlin Mackie - Content Marketing Coordinator at Easy Agile.

    In this episode, we spoke about;

    • Looking at the team retrospective as a tool for risk mitigation rather than just another agile ceremony
    • The importance of doing the retrospective on a regular cycle
    • Why you should celebrate the wins?
    • Taking the action items from your team retrospective to your team sprint planning
    • Timeboxing the retrospective
    • Creating a psychologically safe environment for your team retrospective

    I hope you enjoy today's episode as much as I did recording it.

    Transcript

    Chloe Hall:

    Hi, everyone. Welcome to the Easy Agile Podcast. I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodi Wodi 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 Strait Islander peoples who are tuning in today. So today, we have a bit of a different episode for you. I'm going to be talking with Easy Agile's very own Content Marketing Coordinator, Caitlin Mackie. Caitlin is the Product Owner* of our Brand and Conversions Team*. Now this team is a cross-functional team who have only been together for roughly six months. And within their first few months, as a team, mind you they also had two brand new employees, they worked on a company rebrand.

    Chloe Hall:

    A new team, a huge task, the possibility of the team being high performing was unlikely at this point in time. So, the team was too new to have already formed that trust, strong relationships, and psychological safety, but somehow they came together and managed to work together, creating a flow of continuous improvement and ship this rebrand. So, I've brought for you today Caitlin onto the podcast to discuss the team's secret for success. Welcome to the podcast, Caitlin.

    Caitlin Mackie:

    Thanks, Chloe. It's a bit different sitting on this side. I'm used to being in your shoes. I feel [inaudible 00:01:45]. I feel uncomfortable. [inaudible 00:01:46].

    Chloe Hall:

    Yeah. It's my first time hosting as well, so very strange. Isn't it? How are you feeling today?

    Caitlin Mackie:

    Yeah. Good. I'm excited. I'm excited to chat about our experience coming together as a cross-functional Agile team, and hopefully share some of the things that worked for us with our listeners.

    Chloe Hall:

    Yes, I know myself, and I'm sure our audience is very excited to hear what your team's secret to success was. Did you want to start off by telling us what was this big secret that really helped you work together as a team?

    Caitlin Mackie:

    That's a great question, Chloe. And that's a big question. I'm not sure if there's one key thing, I suppose, it is that ultimate secret source or that one thing that led to the success. I'm sure we all want to hear what that is. I would also love to know if there's just this one key ingredient, but I think something for us, and probably one of the most memorable things that really worked for us, and there was a lot for us to benefit from doing this, was actually doing our retrospectives. So that's probably the first thing that comes to mind when it comes to what led to our success.

    Chloe Hall:

    Okay. Yeah. In the beginning, why did you start doing the retrospectives?

    Caitlin Mackie:

    So, we were a new forming team, like you mentioned before, and we seen retrospectives as another Agile ceremony, and we saw other teams doing it and they were having a lot of success from it, so we became to jump on that bandwagon. And I think with being a new forming team, there are so many things that come into play. So, you're trying to figure each other out, how we all like to work and communicate with each other, all of that. And we were the first ever team dedicated to owning and improving our website. And we also knew it was likely that we'd be responsible for designing and launching a rebrand.

    Caitlin Mackie:

    So when you try and stitch all of that together, and then consider all those elements, we knew that we needed to reserve some time to be able to quickly iterate and call out what works and what doesn't. And what we did understand is that retrospectives are a great opportunity for the whole team to get together and uncover any problematic issues and have an open discussion aimed at really identifying room for improvement, or calling out what's working well, so we can continue to do that. So, I think retros allowed us to understand where we can have the most impact and how to be a really effective cross-functional Agile team.

    Chloe Hall:

    Wow. That is already so insightful. Yeah, it sounds like the retrospectives really helped you to gain that momentum into finding who your team is, becoming a well-working, high-performing cross-functional team. So, how often were you doing the retro? Were you doing this on a regular cycle, or was it just, "Okay. We have a problem. Some blockers have come up, we need to do a retro"?

    Caitlin Mackie:

    Yeah. I think initially retro, we kind of viewed retros as this thing where like, "Oh, we've done a few sprints now. We should probably do a retro and just reflect on how those few sprints went." It was kind of like this thing. It was always back of our mind. And we knew we needed to do it, but weren't really sure about the cadence and the way to go about it. So now, we do retros on a Friday morning, which is the last day of our weekly sprint. And then we jump into sprint planning after that. So after bio break as well, so let the team digest everything we talked about in retrospectives. And then we come into sprint planning with all the topics that we're discussed, and we will have a really nice, fresh perspective.

    Chloe Hall:

    Yeah.

    Caitlin Mackie:

    So, I think this works really well for us because everything is happening in a timely manner. We've just had a discussion about the best things that happened in the sprint or what worked really well, so you want to make sure you can practice the same behavior in the following, and vice versa for the improvements that you want to make. So, that list of action items that come out of a retrospective provide a really nice contact, context, sorry. And you have them all in mind during sprint planning.

    Caitlin Mackie:

    So for example, in the previous sprint, it might have come up that you underestimated your story points or there wasn't enough detail on your user stories. So, with each story or task that you are bringing into the sprint, you're then asking the question, is everyone happy with the level of detail? What are we missing? Or we've only story pointed this or two, is it more likely to be a five? So, everything is really fresh in your mind, and I definitely think that helps create momentum. When you've got the whole team working to figure out how you can be more effective with every sprint.

    Chloe Hall:

    That's such a great point that you just made Caitlin. And I love how going from doing the team retrospective, that you actually can take those action items and go into your sprint and put them into place straight away. It's really good. Otherwise, I feel like if you do the sprint retrospective on the Friday, and you're like, "Okay, these are our action items," get to Monday sprint planning and you're just thinking of the weekend. That [inaudible 00:07:20]

    Caitlin Mackie:

    Yeah, a hundred percent. Yeah. They're super fresher mind for everyone. So, it might not work for every team, but we find it works really well for us, because we're being really deliberate with how we approach sprint planning.

    Chloe Hall:

    Yeah. And then with that, I could see how doing the retro, how it could easily go over time, but then your team has sprint planning scheduled after. So, it's like you can't go over time. How have you managed to kind of time box that retrospective?

    Caitlin Mackie:

    Yeah, that's a really, really good question. And it is on purpose as well that they are scheduled closely together. Som as mentioned above, the discussion you've had in the retrospectives provides a nice momentum going to the sprint planning, but it does mean we have to watch the clock. And initially, this can be quite awkward, because you want to make sure that everyone feels heard and that everybody has the same opportunity to contribute. And I think this responsibility falls on the scrum master, or the product owner, or whoever's facilitating the retrospective to call it out and make sure everyone has the chance to be heard. You'll naturally have people tell the longer story or add a lot of extra context before getting to the point. And then you'll have others that will be a lot more direct. And I'm a lot like the latter. I struggle to get to the point, which doesn't work well when you're trying to time box a retrospective, right?

    Chloe Hall:

    And I can relate, same personality.

    Caitlin Mackie:

    Yes. So with this, I think it really comes down to communicating the expectation and the priority from the get go. With our team and with any team, you will want to figure out who you can perform really well and continually improve to exceed expectations and be better and learn and grow together. And I think if you all share that same mindset going into the retrospective and acknowledging that it's a safe


    space to have difficult conversations. And as long as you're communicating with empathy, the team knows that it's never anything personal, and it's all in the best interest of the team. And that then helps the less direct communicators, like myself, address their point more concisely and really forces them to be more deliberate and succinct with their communication style.

    Caitlin Mackie:

    And that's really key to being able to stick to that time box, I think. And it does take practice, because it comes down to creating that psychological safety in your team. But once that's there, it's so much easier to call out when someone's going down a windy track, and bring the focus back and sort of say, "I hear you, what's the action item?" And just become a lot more deliberate.

    Chloe Hall:

    Wow. I couldn't even imagine like how hard it would be, with the personalities that yourself and I have, just trying to be so direct and get rid of all the fluffy stuff. I mean, look at what it's done to form such an amazing team that we have. So, you mentioned that aspect of psychological safety before. And how do you think being in a new cross-functional team... Only six months together, you had those new employees, do you think you were able to create a psychological safety space at any point?

    Caitlin Mackie:

    That's another fantastic question. And I feel like, honestly, it would be best to have a team discussion around this. It'd be interesting to hear everybody's perspectives around what contributes to that element of psychological safety and if everybody feels the same. So, I can't speak for the team, but my personal opinion on this or personal experience is that creating an environment of psychological safety really comes down to a mutual trust and respect. And at the end of the day, we all share the same goal. So, we all really, really respect what each other brings to the table and understand how all of these moving parts that we are working on individually all come together to achieve the goal. So, when we're having these open discussions in retros, or not even in retros, just communicating in general really, it's clear that we're asking questions in the best interest of the team and individual motives never come into play, or people aren't just offering their opinion when it's unwarranted or providing feedback, or being overly critical when they weren't asked to do so.

    Caitlin Mackie:

    So, none of those toxic behaviors happen, because we all respect that whatever piece of work is in question or the topic of discussion, the person owning that work, at the end of the day, is the expert. And we trust them, and we don't doubt each other for a second. And I think the other half of that is that we're also really lucky that if something doesn't go as we planned, we're all there to pick each other up and go again. So, this ties quite nicely into actually one of our values at Easy Agile is commit as a team. And this is all about acknowledging that we grow and succeed when we do it together, and to look after one another and engage with authenticity and courage. Som I may be biased, but I wholeheartedly believe that our team completely embraces that. And there's just such an admiration for what we all bring to the table, and I think that's really key to creating the psychological safety.

    Chloe Hall:

    I love that your team is really embracing our value, commit as a team and putting it into place, because that's what we're all about at Easy Agile, and it's just so great to see it as well. I think the other thing that


    I wanted to address was... So again, during this cross functional team, and you've got design and dev, how do you think retros assisted you in allowing to work out what design and dev needed from each other?

    Caitlin Mackie:

    For sure. So, for some extra context for our listeners as well, so in our team, we've got two developers, Haley and David, and a designer, Matt and myself, who's in the marketing. So, we're very much a cross-functional little mini team. So, we all have the same goal and that same focus, but we also are all working on these little individual components that we then stitch together. So,, I think... We doing retros regularly. What we were able to identify was a really effective design and development cycle. So, we figured out a rhythm for what one another needed at certain points. For example, something we discovered really early was making sure that we didn't bring design and dev work into the same sprint. We needed to have a completely finished design file before dev starts working on it. And that might sound really obvious, but initially we thought, "Oh, well, if you have a half finished design file, dev can start working on that. And by the time that's done, the rest of the design file will be done."

    Caitlin Mackie:

    But what we failed to acknowledge is that by doing that, we weren't leaving enough capacity to iterate or address any issues or incorporate feedback on the first part of that design file, or if dev started working on it and design then gets told, "Oh, this part right here, it's not possible," so the designer is back working on the first part. And it just creates a lot of these roadblocks. So in retros, this came up and we were able to raise it and understand that what design needed from dev and what dev needed from design in order to make sure we weren't blockers for each other. And the action item out of the retro is that we all agreed that a design file had to be completely finished before dev picks up the work.

    Chloe Hall:

    I think it's so great that you were able to identify these blockers early on. Do you think like doing the retro on a weekly reoccurring basis was able to bring up those blockers quickly, or do you think it wouldn't have made a difference?

    Caitlin Mackie:

    No, definitely. I, a hundred percent, think that retros allowed us to address the blockers in a way more timely and effective manner. And we kind of touched on that before, but yeah, retros let you address the blockers, unpack them, understand why they're happening and what we need to do to make sure they don't happen again. So, for sure.

    Chloe Hall:

    Yeah. Yeah. I guess I want to talk a little bit now about the wins, the very exciting part of the retro, the part that we all love. So, how important do you think the wins are within the retro?

    Caitlin Mackie:

    So important. So, so, so important. It's like, when you achieve something epic as a team, you have to call it out. Celebrate all the wins, big, small. Some weeks will be better than others, but embrace that glass half full mentality. And there's always something to be proud of and celebrate, so call it out amongst


    each other, share it with the whole company, publicly recognize it. Yeah, I think it's so important to embrace the wins. It just sort of creates a really positive atmosphere when you're in the team, makes everybody feel heard and recognized for their really positive contribution that they're making. And I think a big thing here as well is that if you've achieved something epic as a team, it's helpful for other teams to hear that as well, right? You figured out a cool new way to do something, share it. If it helped you as a team, it's most likely going to help another team.

    Caitlin Mackie:

    So I think celebrating the wins isn't even just reserved for work stuff either, right? If somebody's doing something amazing outside of work or hit a personal goal, get behind it.

    Chloe Hall:

    Yeah.

    Caitlin Mackie:

    To celebrate all the wins always.

    Chloe Hall:

    Yeah. And I think it's so good how you mentioned that it's vital to celebrate the wins of someone's personal life as well, because at the end of the day, we're all human beings. Yes,, we come to work, but we do have that personal element. And knowing what someone's like outside of work as well is an element to creating that psychological safe space and team bonding, which is so vital to having a good team at the end of the day. Yeah.

    Caitlin Mackie:

    Yeah, a hundred percent. Yeah, you hit the nail in the head with that. We talked about psychological safety before, and I definitely think incorporating that, acknowledging that, yeah, we are ourselves at work, but we also have a whole other life outside of that too, so just being mindful of that and just cheering each other on all the time. That's what we got to do, be each other's biggest cheerleaders.

    Chloe Hall:

    Yeah, exactly. That's the real key to success. Isn't it?

    Caitlin Mackie:

    Yeah, that's it. That's the key.

    Chloe Hall:

    So, you've been working really well as a new cross functional, high performing Agile team. How do you think... What is your future process for retros?

    Caitlin Mackie:

    We will for sure continue to do them weekly. It's part of the Agile manifesto, but we want to focus on responding to change, and I think retros really allow us to do that. It's beneficial and really valuable for


    the team. And when you can set the team up for success, you're going to see that positive impact that has across the organization as a whole. So yeah, we've found a nice cadence and a rhythm that works for us. So, if it ain't broke, don't fix it.

    Chloe Hall:

    Yeah.

    Caitlin Mackie:

    Is that what they say? Is that the saying?

    Chloe Hall:

    I don't know. I think so, but let's just go with it. [inaudible 00:19:02], don't fix it.

    Caitlin Mackie:

    There we go. Yeah.

    Chloe Hall:

    You can quote Caitlin Mackie on that one.

    Caitlin Mackie:

    Quote me on that.

    Chloe Hall:

    Okay, Caitlin. Well, there's just one final thing that I want to address today. I thought end of the podcast, let's just have a little bit of fun, and we're going to do a little snippet of Caitlin's hot tip. So, for the audience listening, I want you to think of something that they can take away from this episode, an action item that they can start doing within their teams today. Take it away.

    Caitlin Mackie:

    Okay. Okay. All right. I would say always have the retrospective. Don't skip it. Even if there's minimal items to discuss, new things will always come up. And you have to regularly provide ways for the team to share their thoughts. And I'll leave you with, always promote positive dialogue and show value and appreciation for team ideas and each other. That's my-

    Chloe Hall:

    I love that.

    Caitlin Mackie:

    That's my hot tip.

    Chloe Hall:


    Thanks, Caitlin. Thanks for sharing. I really like how you said always promote positive dialogue. I think that is so great. Yeah. Well, thanks, Caitlin. Thanks for jumping on the podcast today and-

    Caitlin Mackie:

    Thanks, Chloe.

    Chloe Hall:

    Yeah. Sharing your team's experience with retrospectives and new cross functional team. It's been really nice hearing from you, and there's so much that our audience can take away from what you've shared with us today. And I hope that we've truly inspired everybody listening to get out there and implement the team retrospective on a regular basis. So, yeah, thank you.

    Caitlin Mackie:

    Thank you so much, Chloe. Thanks for having me. It was fun, fun to be on this side. And I hope everyone enjoys this episode.

    Chloe Hall:

    Thanks, Caitlin.

    Caitlin Mackie:

    Thanks. Bye.

  • Podcast

    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.