As organisations across the world embrace remote working, managers and business leaders are faced with a challenge: how can workers continue to develop? In the absence of in-person training, companies are having to adapt to virtual training and development models. But what separates successful online training from inefficient programmes? 

It’s not always easy to manage and motivate remote teams, particularly when it comes to continuous development. With online training and learning management systems, employers can upskill and onboard people in a flexible, cost-effective way that will remain beneficial even when teams return to the office. Here’s what you need to know about learning management systems and the differences between online learning and traditional training.

Learning management systems emerged from e-Learning, which uses digital resources to deliver education and training. Used to facilitate training and development, learning management systems are software applications that administer, track, report and deliver courses, training programmes and ongoing education.

Learning management systems fall under the online training umbrella and provide an alternative to traditional training courses. They can be versatile for use across different disciplines or be industry-specific, such as Canvas LMS, which has been specifically designed for education use in K-5 through to higher education institutions, and Learn for Jira, which helps to onboard and upskill Jira users. 

The demand for these systems is already significant and expected to boom in the coming years, with research suggesting the global learning management system market will grow at a CAGR of 20.31% from 2020-2024.

Online training should be more than just a pandemic stop-gap, and goes beyond simply getting new recruits up to speed quickly. According to a 2018 report prepared for the G20 Employment Working Group, it’s no longer enough to frontload skills through initial training. Instead, organisations need to invest in education and training systems which are flexible and support lifelong learning. 

Onboarding: One of the obvious implementations of learning management systems is in the onboarding phase of an employee’s journey. Look for a solution that can work on an individual level and at scale, with options to customise learning paths and create your own content. 

Upskilling: A good learning management system will allow employees to enhance their knowledge as they develop in their role - or indeed, take on new responsibilities. Think of it as an essential tool to deliver, monitor and assess courses that build skills and enhance knowledge.

Reskilling and maintaining: A good training programme is one that is ongoing. Organisational learning shouldn’t be a one-off - instead, look for solutions that provide long-term learning and development opportunities for your entire organisation.

Gartner recommends embedding learning assets into employees’ daily activities, investing in experiential learning tools and aligning employee skill sets with the future needs of the business. This suggests that organisational learning should go far beyond onboarding and become a fundamental part of any workforce strategy. 

What can online training and learning management systems help with?

In-person training is impactful, however it can be limiting in terms of accessibility, time and user engagement.

Freedom and flexibility: While learning management systems and online training can be implemented in-office, the current remote working landscape showcases one of the benefits of this type of learning. When trainer and trainee don’t need to physically be in the same place at the same time, there is an enormous amount of flexibility over how, when and where people undertake training. Online training and learning management systems offer accessibility and ease of access, especially if sessions are pre-recorded and can be accessed at any time.

Learn at your own pace: As businesses return to the office, learning management systems will continue to be effective. This is because they can provide a tailor-made learning platform that users can access in their own time, to learn at their own pace. In-person training is often delivered in groups and assumes all participants have the same level of knowledge. With a learning management system, organisations can customise learning paths, courses and training programmes for each individual, allowing employees to learn what they need, when they need.

Interactive and engaging: Gamification in workforce training isn’t a new trend, and it’s increasingly being used in online training modules and learning management systems. Quizzes, games, leaderboards and live progress updates engage users and ensure they’re interacting with the learning material in the desired way. While in-person training can rely heavily on demonstrating and explaining, learning management systems incorporate more hands-on doing and learning.

Cost effective: In-person training relies on the availability of key people, venues, time and training materials. This can be extremely costly for businesses, especially when you factor in employee turnover and maintaining knowledge. A customisable learning management system that can be rolled out company-wide can save considerable costs in the long run, and provides data-driven insights to further optimise courses and learning pathways. eLearning typically has faster delivery cycles than conventional learning and requires little ongoing upkeep, making it a sensible investment for any organisational learning and development programme.

What benefits does this style of learning have over in-person training?

There’s a learning management system for every occasion - but if you’re looking for a solution specifically for Jira training and development, your best bet is Learn for Jira. It’s a tool that not only offers initial Jira training online, but maintenance of skills and knowledge over time. 

Learn for Jira serves as a knowledge base thanks to its search functionality, offering ‘just in time learning’ to provide on-the-spot questions as well as linear learning. It helps users make the most of their Atlassian products, offering courses on Confluence as well as Jira, and covers onboarding, knowledge retention, progress tracking and the ability to learn Jira in Jira. 

Rather than relying on an in-person training experience with a stretched Jira Admin or IT training coordinator, Learn for Jira can be rolled out easily across entire organisations at any time, with powerful admin features and easily digestible training videos. You can also customise it to suit your organisation’s requirements, with the ability to upload your own courses and create learning paths.

How a learning management system can help you use Jira

Onboarding and scaling Jira training can be challenging at the best of times, and even more so when teams are working remotely. Take the pressure off your Jira Admin and IT trainer with a customisable learning management system designed to help companies learn Jira. Try it for free here, or read more about why you should choose Learn for Jira in our recent blog.

Learning management systems allow organisations to keep people learning, any time, anywhere. Discover the benefits of modern training solutions.

Learn for Jira could be the perfect learning management system for your organisation.

Learning management systems allow organisations to keep people learning, any time, anywhere. Discover the...

How your business can benefit from a learning management system

A new year often stirs reflection of the last, and I find myself in that position. Late last year, Adaptavist had the honor of hosting several friends and customers for discussions on the topic of agile delivery which followed from our Champion Hour webinar on Jira Align and the Agility Gap. As the host of the sessions, I was truly blown away by the openness and honesty of our audience.

Via Zoom from living rooms and home offices around the globe, participants shared stories about how 2020 made them think differently about existing processes, tools, and practices. We heard tales of how 2020 has created new and unexpected silos; required urgent reprioritisation of features based on new customer needs; and most importantly, how the mental health of teams took an urgent priority above all else as, without a team, there is no delivery. Period.

Days after the conversations it struck me that these sessions identified an aspect of agile that isn’t often talked about but is critical to agile delivery: The gemba walk.

The word gemba originates in Japan and means ‘the actual place.’ Within agile frameworks, gemba is defined as a process in which the product team observes how stakeholders execute steps and specific activities in their operational value streams to better identify opportunities for relentless improvement. The tl;dr of this: talk to your teams personally and find out how their world is working.

In a pre-2020 world, gemba walks ideally were done in person. But now leaders have the added challenge of understanding how their teams work together while in isolation. It’s not just one work floor to observe, it’s each individual’s home office or ad-hoc work area. And that takes time. 

So, how do we foster the connection that drives continuous improvement in our remotely-distributed reality? Here are a few approaches that came out of our sessions:

This is deeper than listening. Author Daniel Pink notes that leaders who ‘agitate’ (a positive term in this context) are leaders who help teams understand context and motivation so that the team will want to make a change to do things differently. These leaders hear their teams’ issues and concerns, and as a result, tailor their messages to support what they’ve heard.

If a manager simply tells teams what they want them to do and how they should do it, that is considered an ‘irritation’; which is not the behavior of a leader and can create more damage than good—especially during times of team isolation.

Psychological safety is key, and dovetails into the above idea regarding leadership listening and tailoring interactions. The aim is to create an air of ‘it’s okay and we’re in this together.’ When teams feel safe to speak up, deliver an unpopular message, fail, etc., they flourish. This culture shift can not exist however, without leaders who trust and respect their team. 

Even before our current period of isolation, leaders and managers have all been guilty at some point of making decisions that affect many from a room by themselves (or with one or two other people involved). 

In short, decisions can not be made alone since humans generally do not have a good understanding of how others will react. We are optimistic about our own assumptions, and unaware of our own blind spots. Daniel Pink touches on this too by explaining the Fundamental Attribution Error, which says: “When we try to predict people’s behavior and explain people’s behavior we almost always overweight the importance of their personality and underweight the importance of context and the situation they are in.” 

The conclusion of our Q&A sessions was that leading remotely-distributed agile teams is a challenge, but is absolutely doable. The gemba walk just looks a bit different now as it’s two-dimensional. But by leading with their ears, nurturing a healthy work environment, and including the teams in key decisions that affect their day to day, successful leaders keep their teams engaged with meaningful work, which is the fuel for agile delivery in 2020 and beyond.

Daniel Pink quotes and thoughts are from his Masterclass, Daniel Pink Teaches Sales & Persuasion

About the author: Jennifer Eolin is a Technical Consultant who believes in empowering organisations to make the 'people, process, product' principle a reality. She regards 'process' as more than a document but as the basis for an organisation's culture and future.

We reflect on what worked in agile team leadership during the pivot to a remote 2020, and how to create a virtual gemba walk.

How agile team leaders can walk the gemba walk in a remote world

We reflect on what worked in agile team leadership during the pivot to a remote 2020, and how to create a...

Join hosts Ryan Spilken and Heidi Araya in conversation with Adaptavist DevOps guru Matt Saunders about the overlap between DevOps and Agile, Psychological Safety in teams, and the trends to look out for in the future of work. 

Hello and welcome to Team Titans, the stories of people with unique perspectives on work itself. They're defining processes, building tools, leading teams, and sometimes they're breaking those processes that they then just made. I'm Ryan Spilken and I'm joined today by my cohost, innovation product manager Heidi Araya. Heidi, thank you so much for joining me today.

And I am so excited to be speaking with you with our guest, because you're going to be able to really prod and poke and get some deeply insightful answers out of today's guest, Adaptavist Head of DevOps, Matt Saunders. Matt, thank you so much for joining us.

So good to see you, Matt. You're role as head of DevOps has seen you move away from necessarily client facing work to working with our CIO team. So are you doing DevOps still? Are you still the DevOps guy?

Am I doing DevOps anymore? Oh, that's a good question. Am I still actually the DevOps guy? Yes, I think I actually am.

So let's talk a little bit about what's happened since I came into Adaptavist three and a half years ago. I came in with a fairly nebulous title of head of DevOps. I talked to Simon and others in the business around here, "What does that actually really mean? Should Matt be doing DevOps and getting his hands dirty and doing things that are DevOps all day long?" And we kind of came to the conclusion that the business is doing some DevOps. They're sprinkling DevOps everywhere. Let's do more of it. And so I kind of floated a bit around between internal teams doing DevOpsy type things, whether they are cloud engineering, working with Amazon Web Services or tools like Kubernetes and Terraform, but also going out to our customers in the consult team, our professional services teams, where they need some help in doing DevOps, whether that is with tools or in the more organizational process, culture type level of DevOps in terms of the way people actually work.

And so I've been working in the innovation community of practice recently. We've good friends, John Turley, Jon Kern, and more recently as well with Heidi, which has been brilliant, but actually we're at an interesting time in Adaptavist where the company is growing fast and some of the things we've been doing for our customers we can do with applying internally a bit more. So, yeah. So I've taken that new role under the CIO, under Neal Riley to help bring more DevOps to us internally. It's quite interesting how the things that you go off and do with your customers and you tell them things like release software as often as you can, have lots of tests, have cross-functional teams, how easy it is to not actually implement those sorts of things internally.

And so one of the things that I want to do, and that Neal wants me to do is to bring all that stuff out, make sure that we are actually one of the leaders in how we develop and run internal services because they're much the same as what our customers are doing. It's a classic bit of dogfooding. So just to finish off on that. So I was a head of DevOps, I think I still am a head of DevOps. We've been very lucky in Adaptavist in the acquisition we made. It has brought a whole load more of DevOps people and more heads of DevOps. So yeah, DevOps should be everywhere? So I'm really, really glad that I've lots of DevOps and lots heads of DevOps around.

So one thing that I look forward to speaking with you about today is something that I've seen you do as in your role as head of DevOps and that is almost like team psychologist. I remember sitting down with you for a team meeting and thinking, "Was that DevOps? No, it was just an aspect of it," but I certainly do look forward to chatting through that.

Well, yeah, it is. There's a psychological element here, which you, of course, have directly experienced. I remember that session very well. It was excellent. And it can be a surprise. When you think of having a discussion about DevOps, which to a lot of people is all about tools, maybe Jenkins or things with bizarre names to onlookers. Let's do some Terraform and some Kubernetes and some EC2, but actually is, at its more fundamental level, it's so nicely with things like agile and flow. Now, how do you actually get work done? And we'll talk a bit, I'm sure, in the next few minutes around how agile intersects with DevOps and how there's a whole class of stuff that's looks like you should be doing, but actually it's just masking the interesting stuff, which is all about delivering value.

And so the session that we were, that Ryan's referring to, was one that wasn't really about technology. And I think that's why we got a lot out of it because we were looking at how do we get people to be able to do their best work and how do we get people to be able to deliver stuff? So, yeah.

That's interesting. In late 2016, early 2017, I happened to attend a conference and I met a DevOps consultant there. And after attending that his intro to DevOps, I walked up to him and I was doing agile coaching at the time. And I said, "We're saying the same thing, only you're just approaching it from a different angle." And so we ended up collaborating on a talk called DevOps, a Catalyst to Enterprise Agility. And we spoke at a conference there a few times, a few different conferences, but I'm curious what you've seen as when people approach DevOps and thinking about it from a tools perspective because that's exactly what we found, is there something that you normally start with when folks come up to you and say, "Hey, I want to do this DevOps thing." How do you start?

Well, how do you start? Well, you find somewhere to start and you've got to, sorry, that sounds like a terrible answer. But what I mean by that is people generally want to talk about the tools, and you can go in and spend a hell of a lot of money on getting in the right tools and consultants to put in the tools for you. But I would encourage people to start small. I mean, if you're talking about doing things that are transformational, whilst every company is individual and has its own particular needs, for most people, it is all focused around getting software delivered and you're only really going to find out the things that are really unique about you and your organization by going off and developing this stuff. It kind of helps that people start talking about tools because, well, you can go in and give them some tools.

But I think the attitude you take to that is critical. If you take it from the point of view of like "We've delivered a lot of tools, therefore we're DevOps," hey, fantastic. Then all you've ended up with is a load of extra complexity, probably some more friction in letting people actually get stuff done. I try and see the tools as being a bit of a focal point around what's going on around the tools. Who's actually running the tools? How does that tool interact with the next thing down the chain? Other people who are not directly running the tools, use the tools, they'll get value out of the tools. And bit by bit, you start to unravel the whole system and by system, I mean, not just a computer system, but the system of how you get stuff done. Right? So that's the key there.

Oh yeah. I was going to ask when folks approach you with tools, much like they may have approached me for agile coaching, I find that it could have been impacted by the organizational culture and hierarchy. So how do you handle that? When someone just wants to implement a piece of the tool somewhere.

I generally do a very big sigh a bit like this. Okay. Sorry. That's very kind of old worldy kind of cynical type approach. You've got to take people at face value. You've got to appreciate where they are on their journey. Prior to Adaptavist, I worked in consulting for a while and we had a sequence of engagements which were very much like this. It was like, "Yep, we got this man or this woman who wants to go and implement some tools. Matt, go implement the tools for them." And you're like, "Okay." And the worst thing you can do is go in and start challenging someone. You start to talk about something else. Somebody asks you, "Can you do the tools for me?" And you're like, "Well, no, because of this, this and this."

And quite often you find that when I say this, this, this, it is all about process and culture, exactly what you're talking about there, Heidi, you'll find that possibly the person who's asked you to do that sort of thing doesn't actually have any influence in those other areas, especially in the larger organizations. And so from that point of view, you're in a bit of a tricky spot. It's a bit like if you've got a picture that needs to be put on the wall and somebody's given you a saw and they say, "Can you use this saw top put this picture on the wall?", well, yes, we can probably do it somehow. Actually, maybe not with that. Terrible example. But it's the wrong question. So what I will be doing is asking the [Ingrid 00:10:08] questions around how do you see actually deriving value from this? What is actually the value?

And given the right sort of culture in the organization, those questions go down well. I've had it work both ways. There's some terrible examples of pathological culture, which is actual thing, if you look up Westrum's definitions of culture, for example, the pathological, where there are people are not really allowed to operate outside of their own silo. And that sort of initiative is frowned upon because it might make somebody else look bad. Meeting those sorts of organizations, you can tell fairly quickly what type of organization you're working with. And the problem with those is it's almost tragic, in that the organization desperately needs to change to not become like that but you've got no possibility of doing that. In those sort of cases, you're a bit stuck. All you can do is work within those narrow confines.

Those things tend to end up with a nice new DevOps team where there wasn't one before and I'm being a bit negative about DevOps teams. Sometimes it's a means to an end, but ultimately trying to work out how value is actually delivered, the last bit of that is kind of DevOps. And if you don't consider it as being a part of a bigger whole, like somebody has an idea for a product, somebody wants to write some code and then somebody wants to deliver that, that whole thing you got to take that into consideration when you're putting in tools. Otherwise at some point it's all going to fall down.

So for a second, if we could, let's step back to a company that is maybe not grown to the point where it's gotten that sort of parasitic culture thing happening, right? And there is still like some uncertainty and it's growing and somebody up top says, "You know what we need is a DevOps strategy," because they read it in a magazine and they think it's a good idea. But they're starting fresh and things are a little bit fuzzy. How are they going to go about developing a strategy to be successful in this arena?

I think the fundamental thing behind a DevOps strategy is that, great, that it's being mandated from the top. It should stay at the top and it should continue to be at the top because these sort of things are fundamental to how companies are delivering value these days. So much of what any modern business does is around software these days. And you can trot out examples like Uber, for example, taxi companies that used to be about getting vehicles on the road, but actually it's technical. It's a software problem. Everything that they do, well, not everything, but fundamentally in its core days. So yeah, DevOps strategy. See, you want to have a strategy. Okay, cool. Are you going to align everyone in your products world, in your development world, your marketing world, around this DevOps strategy? This is why you should.

Because these things are so key, it's got to fit in and it doesn't just have to be a DevOps strategy. It could be a more all encompassing thing, because again, ultimately, and I've said this a few times already, it's about how do you flow? How do you get the flow of value to your customers? And that just ain't DevOps. And if you treat DevOps in isolation, then you're not going to get there.

It sounds like you might be thinking about also start with the vision and the outcome, not actually what problem is DevOps solving. Much like agile, we're implementing Scrum or we're implementing an agile framework here and so agile ends up being the goal or DevOps ends up being the goal without really thinking about why do we care about that? What's the bigger problem at hand?

Totally. Yeah. There's a danger there in that you can say, "Oh, I'm not going to go and install Jenkins on that server for you, because we need to think about DevOps as an overall strategy," and they're pitting to agile and everything and high level, but refocusing the discussion to be slightly wider is always a benefit because yes, you're absolutely right. Especially in big organizations, these things can be intangible unless you make them tangible. And every time you make them more tangible, like delivering, I don't know, an environment where you can do SAFe, for example, or an environment you've got a CI system installed and running tests every X minutes or whatever, could accidentally move you away from some of your goals. So you've got to be very careful to make sure they're all aligned or within that wide scope.

We've kind of danced around the issue a little bit. I think we just need to talk about how DevOps and agile sort of overlap, right? Because you're both saying pretty much the same thing about the bigger picture, the strategy, where are we going? Not here. And you're coming from, like you said, Heidi, in your talk, you're talking about the same stuff. So where are the overlap pieces? Maybe you two could highlight some of the differences as well.

Well, I'll start out with the agile piece. So agile really is about delivering value to customers frequently so we can get feedback and we can make better decisions. That's really what agile is about. I mean, I can say when, when I'm thinking about how DevOps adds to it, well, it helps us get releasable now. What kind of feedback are we receiving? How are we going to receive feedback and get feedback in ever smaller and smaller loops so we can reduce organizational waste? But Matt, please add your perspective just as an agilist. I'm coming in here with mine.

Yeah. Well, so this is a terrible interview because what you want is a bit of conflict, you want disagreement. No, it's like, "Er. Grr." But, yeah, it's two sides of the same coin. Here we go. I'll try and be slightly controversial. Those damn agilists wanting software delivered like all the time because they can't make their mind up on what's going to be the right thing and wants me to move out their product. I'm just a poor ops person with my servers in a room. And they want to release 17 times a day and they've got 17 different things on the go. So I need 17 different environments. That used to be a point of contention. If you look at DevOps the word, dev and ops, dev throws stuff over the fence to ops. But yeah, you lot want to deliver value, or you want to do your experiments to work out what is the right thing to do, because let's be clear.

It's almost impossible to work out what the right thing to do is a planning stage. That's why we don't do Waterfall or anything like that, because it's wrong. It's inevitably going to be wrong. Information that you find out later down the development process re-informs your decisions and you have to go back. And part of agile, of course, is acknowledging that that is a fact of life, regardless of how much we want to be able to plan things. So, yeah, there was conflict, dev and ops, between the CIS admins and the coders, because, well, basically we ops just want stable systems. We don't want people changing stuff because stable systems, things that aren't changing, don't break in new ways. Maybe they break in old ways because they were always breaking but at least it's the same old ways. Fine. Great.

But yeah, and here's where it all comes back together. A definition of DevOps could be that it is actually providing the environment that agile people need to be able to prove the value in terms of delivering it, getting it out in front of customers. One of the key things that I always come back to on this point is a blog post, an old CTO of mine, a guy called Benjamin Wootton, when I was working at Contino, he wrote, which is around how environment provisioning was a key differentiator between high-performing ops teams and non high-performing ops teams. This was written before the State of DevOps Report came out, which talks about what those differences actually are, but they're all kind of tied together.

And so, yeah, I've been that person with servers in a basement and have coders come and be like, "Oh yeah, we got this new thing. I want to try this out. Not really sure if it's going to work. Can you give me a box to try it on?" And I'm like, "Oh, here we go again." We can do all that stuff. Now we can automate it. Virtual servers. You want a server, click, click, click, bosh, there you go. New environment. Exactly the same as the last one, it click, click, click. Okay. Maybe wait a few minutes from the database to get provisioned, but fine. There you go. There's your environment. It's disposable. Do what you like with it. Do your experiments on it. Be agile. Brilliant. We're there.

That's one of the things that, and when I was collaborating with this DevOps consultant a few years ago, I ended up thinking, gosh, looking at the manifesto and the 12 principles, I thought they have the DevOps mindset in mind. So luckily with us, we have working with us, we have Jon Kern who is co-author of the Agile Manifesto so I was able to ask him. And he said that actually he had been preaching and practicing DevOps-like things driven by the need to see frequent, tangible, working results. I was happy to find out that just as I thought, they were really thinking about those things when they were writing and crafting the Agile Manifesto.

Jon Kern was our first guest on Team Titans. So if you want to listen to that episode, we'll include a link in the show notes.

It is a mindset thing. I mean, we talk about an agile mindset and there is a DevOps mindset as well. And they are highly compatible. When both sides of the relationship work in harmony, you've got agile things going on, DevOps things deploying them, reporting back on them, giving you feedback back into the cycle. It's something you have to work on the balance a little bit on. It can't be all one way, but ultimately, that is one of the keys to delivering stuff. It's being able to implement agile and DevOps in a mutually compatible way. And it isn't actually that hard.

Well, this brings me to an interesting question, right? You've just described a scenario where things are happy and harmonious, where there are birds singing and unicorns frolicking in a field, right? What about when things start to break down? How do we reconnect people? How do we reconnect teams? How do we refocus on delivering value to the customer?

It comes down to people. I was just going to say, it comes down to empathy. You've got to have empathetic people. If you, and again, these sorts of things inform how pathological or otherwise your culture actually is. If you look at how people are rewarded, how things that cause them stress in their work, the kind of even the joy that's brought, sorry, if any of those things are out of whack, then you start, you do, you start to get these little problems. Maybe there's a perception that the environments that the ops people are building for you aren't actually good enough or are not providing the right sort of feedback. And for whatever reason, you can't actually actively collaborate on those things. But in a lot of companies, you can, and I would stress those. It's a significant thing around leadership to make sure that those avenues are always open.

We're moving somewhat away from this kind of siloed approach where this team does this, that team does that. These people write code. These people write tests. These people provision infrastructure. These people respond to alerts in the middle of the night, and you kind of need that to scale to an extent, but giving everyone else an appreciation for what everyone else is doing can lead to some interesting positive effects. So we talk about things like T-shaped people, so people who have... Maybe you're a coder, but you have an understanding of everything else. And one of the traps is that people feel like they have to kind of understand everything about everything. And in an ideal world, that would be true. It's a lot easier to... One of the problems with silos and people doing these very narrow roles is that it can be hard to understand what's going on at the interfaces between the silos.

So if you're handing something over, any bit of software over, from dev to testers, you've got to explain to the tester what the intention of the software was. And there's a whole series of informal discussions and contracts that go into that. And taking this to its logical extension, you can get yourself into a better position where everyone has an appreciation for the whole flow, the whole cycle and so much more than that. Another example is stuff like being on call. Traditionally being on call has been something that ops people would do. I've been there, going back, even back to the 90s, pager goes off in the middle of the night, something's gone down. I have to get out of bed and fix it. So I'll go and fix it. The next night happens again because I just bandaided it. It's been fixed temporarily, et cetera.

If you put your devs on call and they get the page, but they probably don't get it in the middle of the night because they probably see it earlier. And they see, "Oh, what I'm doing there is causing this thing to go down at three o'clock in the morning," so they can fix it. So there's a lot in there, but ultimately it's the working together. You consider yourself to be part of a wider team, getting appreciation for what other people do, really gets you along. But you have to have the right sort of people in the first place. First time I ever, sorry, just one more point on this. First time I ever did devs on-call, I was really surprised by the reaction. People don't really like being woken up in the middle of the night. That's fair enough. Right?

Thank you. But actually, there's an interesting thing going on there, which is that a certain class of person doesn't like somebody else being woken up in the middle of the night for something that they did wrong or that not that they did wrong, but with hindsight, they could now do better. And so the first time I ever did devs on-call, it was a tiny startup back in 2009, I think. They loved it. The devs loved it. They were like, "Oh right, okay. We can be involved in this stuff right at the start when it breaks and stop it breaking again." So that then leads to, "Oh yeah. That sort of thing wakes people up." So you write some code, I don't know, a month later, middle of the day. Oh yeah. You get an appreciation for what sort of things go wrong. So in that environment, those who went on call, people stopped getting woken up because people were coding better. You get all those sort of benefits from that. I can't remember what the original question was. I probably landed on for about an hour on that one.

It sounds like empathy. It sounds like what you-

Yeah. Yeah. So I have a question because you mentioned the word flow a few times in this call already. And so I'm curious whether you feel the concept of flow has been intuitive to folks or challenging for them to understand.

I think it's really challenging. I think we spend so specializing on things, especially technical people. We're encouraged to do that. We're encouraged to specialize, be really good, be a really good Java coder, be a really good Terraform engineer, et cetera, be a really good HTML slash CSS slash angular slash react slash whatever the hell front end's written in these days type person. But the more you specialize, the less you can see your individual part, which actual cog in the wheel you actually are, if that's not a terrible metaphor. And so being able to take a step back and be a bit more general to see actually, yeah, so I'm doing this work and I'm probably motivated and my own serotonin levels are heightened by solving problems in my own particular world.

But actually that's not the same as what my business is trying to do or the business that I work in is trying to do or the organization, whatever it is. The reality is you look back at agile, DevOps it is all about flow. It's the flow of ideas from something in someone's head to somebody who writes some code to it getting actually delivered out. And if you look at it from that point of view, that your system is always moving, stuff is always flowing through it. It's transactional and the faster you can get these things, though not necessarily faster, the more efficiently you can move things from one state to the next governs how fast you can go. Yeah. That's flow or value streams, any of these words, but it is. It's not what we're encouraged to think about or we're encouraged to go into, especially going into computer science and its related disciplines.

It's actually around perfection, specialism in things. We all know perfection is the enemy of finished or is it the other way around? And you get this interest in conflict in your mind around what should you be prioritizing? Is it getting them through the system or is it making them really, really good? And, yeah, that's a wake up call for me when I realized I'd spent months working on a particular project, just trying to make it perfect and meantime that the business had moved on. They were interested in something else and that thing I'd made perfect didn't need to be perfect. What about the flow?

So Matt, we've been talking about quite a few things over this time and what are the current trends that we should be paying attention to? What should we be looking out for?

Adaptavist DevOps guru Matt Saunders joins Ryan Spilken and Heidi Araya to discuss psychological safety in teams, the overlap between DevOps and Agile, and the trends to spot in the future of work.

Transcript: Team Titans Season 2, Episode 3 - Matt Saunders

The transcript of Ryan Spilken, Heidi Araya, and Matt Saunders discussion of Devops and Agile on this epi...

February 2nd is fast approaching. For Atlassian customers, this means you will no longer be able to purchase or request a quote for new Server licenses. Customers new to Atlassian, meanwhile, will have no option but to go straight to Data Center or Cloud.

With this in mind, we thought it would be useful to take an in-depth look at your current options and, with the help of our pricing calculator, assist you in deciding the best next steps for your business. First thing’s first, here’s a simple overview of the options available to you:  

What’s the best move for your business?

We’ve said it before and we’ll say it again—there is no one-size-fits-all approach here. What’s right for one company may be wrong for the other. 

With so many different, organisation-specific variables—from add-on apps and customisations, to security provision—it’s hard to speak broadly about the precise next step for your business. 

But, that’s not to say we don’t want to help where we can. So we’ve come up with this breakdown of the pros and cons of each option to hopefully guide you in your decision making. 

Before we take a look at the advantages and disadvantages here, it’s really important to highlight that Server licenses can only be renewed until February 2024, after which Atlassian will stop providing support for all Server customers. 

Some businesses may opt to stay on Server after this date as they look for an alternative solution to Atlassian Data Center or Cloud that better suits their business needs. That said, if you chose to stay with Atlassian, we recommend making up your mind well before February 2024. With that, here’s a look at the pros and cons of staying on Server.

Ideal for: Companies who don’t want to make a decision on migration just yet. 

With Atlassian promising to support Server licenses until February 2024, you don’t have to make the decision to move on from Jira Server right now. What’s more, you can use the additional time to trial Cloud for free.

Holding off on your decision to migrate also gives more development time for the Cloud versions of your mission critical apps to reach feature parity with their Server versions. Our own ScriptRunner for Jira Cloud, for example, is very close to parity after four years of development! But don’t wait for too long or you may find your Server add-on apps falling behind—more on that later!

Disadvantages: If you don’t lock-in the price before February 2nd, the cost goes up. You can use our price calculator to work out what you may save by deciding to lock-in Server in the next two weeks. 

Our comprehensive Atlassian licence calculator gives you a realistic picture of Atlassian licensing upgrade costs.

Here is a small example of our price calculator in action—showing the Server price increase for 100 users on Jira Core, Jira Software, and Confluence:

Another important factor to consider here is that marketplace app vendors may well deprioritise work on the Server and Data Center versions of their apps as Cloud takes center stage. While this may not be the case for all vendors, it’s something worth considering. Crucially, another important date in the diary is May of this year—when Atlassian will stop accepting new Server app submissions for the Atlassian Marketplace.

Finally, let’s be honest, if you stay with Atlasssian you’ll have to make the decision to migrate from Server eventually, and for some getting ahead of the game and making the move to Cloud now might be the best option. 

Ideal for: Organisations with widely distributed teams that are looking to access Atlassian tools quickly and efficiently, while simplifying their everyday operations. Cloud is especially good for businesses that use Jira in both technical and non-technical teams.

Depending on the number of Jira users and add-on apps you have, the price of migrating to Atlassian Cloud can be more attractive than Data Center. You can do a comprehensive price comparison - including the cost of migrating your apps - in ‘advanced mode’ of our pricing calculator:    

Lastly, with Atlassian’s Cloud-first approach, some Cloud apps are now more feature rich than their on-premise versions, with vendors prioritising the release of new Cloud functionalities. 

Disadvantages: Put simply, Cloud isn’t right for every business. Data residency and security are perhaps the biggest concerns companies have when it comes to Cloud migration. For businesses that require high levels of data protection, and therefore need their data on-premise (government organisations are a prime example here) migration to the Cloud probably isn’t a viable option. 

Secondly, enterprise organisations with thousands of users can experience performance issues with Cloud (as they can with any deployment model), and of course Atlassian are free to do updates when they see fit, rather than when it suits you.

Finally, while there is considerable work going into ensuring apps for the Cloud gain feature parity with Data Center and Server versions, it’s true that some aren’t quite there yet. This could mean that you lose some app functionality when you migrate from Jira Server to Cloud, and is something worth checking on a case-by-case basis.

Ideal for: Businesses that are growing quickly and need fast, easy scaling capability without running into problems. Data Center tools offer greater customisation options than both Server and Cloud—ideal for teams that require the flexibility to fully tailor their tools to meet their business needs.

Finally, and perhaps most importantly, Data Center is currently the most fitting option for organisations in highly regulated industries with stringent data security and compliance demands that need their data on-premise with guaranteed reliability and stability. 

It could be that Data Center seems like the right choice for the needs of your business, but you’re not in a position to manage the day-to-day management of infrastructure or admin. In this case you may want to outsource your Atlassian tool management altogether. 

Whether you outsource management for your own equipment, or move to a seamless cloud experience with a cloud provider like Amazon Web Services (AWS), working with an Atlassian partner like Adaptavist allows you to maintain control over your Data Center set-up.

You can find out more about our Data Center managed service here and be sure to check out our Demystifying Data Center Migration eBook for best practices and technical advice.  

Download our eBook for best practices and technical advice on making the switch to Data Center.

eBook: Demystifying Data Center Migration

Disadvantages: There are no two ways about it—migrating to Data Center can be a costly option. That said, if you have the infrastructure and team to support Data Center, and a whole host of business critical apps to migrate, it may in fact be a less costly option than Cloud. 

Ideal for: Businesses that want the security and reliability of Data Center for some of their Atlassian tools, but are happy to have a Cloud experience for others. There are many organisations currently running with this hybrid approach, especially if they rely on tools that don’t exist on one of the platforms. 

In addition, moving some parts of your solution to the Cloud, whilst keeping others on-premise, can actually reduce your total cost of operation. This is especially true if you minimise the use of your on-premise solution. 

Want to prolong the Server vs Data Center vs Cloud conundrum? Again, this hybrid model is a good option for companies looking for a slower transition to the Cloud. Stay on Server or Data Center while trialing Cloud for free, and take the time to see what’s best for your organisation.  

Disadvantages: This may still be a costly option and not the best choice for smaller businesses. One final point worth mentioning is, with a hybrid approach, you must ensure you have a clear demarcation between your on-premise and Cloud solutions and help your user base understand which one they are using.

With so many different options, and a myriad of factors to be considered when making your decision, it can be easy to feel overwhelmed. Remember, you don’t have to decide alone and our experts are always here to offer a helping hand. 

From guidance on migrating your add-on apps to working out the best licensing option for your organisation and everything in between, please don’t hesitate to get in touch with us to see how we can help.  

Whatever path you choose to take, our experts are here to help. Just fill out this short form and we'll get back to you: 

Want to discuss your Atlassian upgrade options?

As Atlassian stop selling Server licenses from February 2nd 2021, we take an in-depth look at your current options and, with the help of our Atlassian license pricing calculator, assist you in deciding the best next steps for your business.

Migration from Jira Server: is it time for Atlassian Data Center or Cloud? 

As Atlassian stop selling Server licenses from February 2nd 2021, we take an in-depth look at your curren...

Guest blog post by Nishaat Rajabali & Tomasz Bryla

Developers don’t like anything they perceive as taking time away from actual coding, and prefer a barrier-free software development cycle. But, power is nothing without control, especially when developers are working through the process of moving from code to product delivery. That means, in order for a company to function, compliance and uniformity must be respected and enforced across the board. The DevOps/IT/Systems Manager is usually in charge of making sure this happens without missing any vital approval steps or slowing down operations.

In this post we will detail how our Productivity Tools Team (responsible for CI/CD and Atlassian toolchain) helped GAIN Capital’s developers to follow and understand best practices for positive outcome in product development and delivery. We hope this workable example will help others to discover the hassle-free process of automating and controlling their DevOps workflow and stop all the head scratching.

Join our webinar with the GAIN Capital team on 17 February 4pm GMT / 11am EST.

How to standardise and control best practices in Bitbucket

Like many other companies that grew through a series of acquisitions, we also had to start finding automated ways of overseeing the output of multiple development teams that were operating with different toolchains, set-ups and rules.  

We started the consolidation work with tooling. For version control, we chose Bitbucket - it integrates seamlessly with Jira, and is much easier to set up and use than Team Foundation Server, now called Azure DevOps Server. However, everybody working on the same tools does not guarantee that they will be working or collaborating in the same way.

We found that not all the teams were following DevOps best practices, and each one of our teams was following their own rules. This could cause tracing and reporting problems, which for a heavily regulated financial company like ours can turn into an audit nightmare.  We absolutely had to correct problems such as:

No commit messages
Users committing with very short or no commit messages are counterproductive, especially because Git history is merged as is from feature to trunk branch.

Commits not being associated with the Jira ticket ID: 
Users were frequently forgetting to add the Jira ticket ID on the commit, which made it very difficult for reviewers to trace work.  

Pushing binaries to Git: 
Binaries increase repo size, which increases disk space consumption, and in turn increases git clone time both locally and in other systems such as on our CI/CD server. And once they make it to Git, destroying files and associated history is not easy.

It was clear to us that in order to enforce standards and smooth operations, we needed to add some ‘speed bumps’ on Bitbucket. 

We set out to create and implement a series of control policies at the global level in Bitbucket. 

In a nutshell, any push that didn’t comply with a control policy had to be automatically rejected. To achieve this inside Bitbucket, we created a series of ScriptRunner custom pre-hooks that trigger automatically upon ‘git push’.

To avoid bottlenecks while developers were getting used to the new rules, for the first few weeks the pre-hooks only returned warning messages instead of rejecting the push outright.

After that, we set up the pre-hooks to reject a push that didn’t comply with the rules. However, this setup allowed for some exceptions. For example, to permit break fixes, the pre-hook for commit message control accepts a push with [EMERGENCY] in the commit message. 

Setting this up was easy. We have been using ScriptRunner for Jira for a long time, so Groovy scripting is natural  to our team. You can see a couple of the scripts we used (written by Nishaat and Tomasz) here and here. 

The set-up was easy, but getting our users to understand why these controls were  necessary was more complicated. To achieve this, we relied on a solid documentation. 

Having proper documentation is the easiest way to share knowledge among developers and to ensure managers don’t need to explain things over and over every time somebody new joins the company. In our case, every single Bitbucket control policy is scrupulously explained in our Confluence Wiki, and follows this model:  

Examples: What does it look like when the rule is respected?

Compliance: What steps to take to comply with this rule? 

Resolution: What to do to resolve a conflict with this policy?

Error message: What is the exact error message you will get on Git if the conflict is not resolved?

When a control policy is breached in Bitbucket, the custom pre-hook rejects the push and returns a short ‘error message’ with a link to the detailed documentation on our wiki. This way, it’s easy for the developer to understand the reasons for the rejection and to know what they need to do in order to correct the situation.

Documenting the rationale for control policies

Try ScriptRunner for Bitbucket free for 30 days

Not everyone openly embraces change, so as you can imagine, there was some initial resistance from our users when we announced these controls. Mostly, they perceived them as blockers that would slow down their ability to ship code fast . But, thanks to detailed documentation and our two step-approach to implementation (warning messages for the first weeks, instead of outright rejection) it did not take long for  everybody to see the logic and relevance of best practice enforcement. 

Even better, once the process was in full swing, they also started appreciating the benefits. We now have traceability and context for each commit, and communication among developers on code has improved tenfold. 

Further proving adoption success, individual teams are now requesting more granular controls on their team repos and projects. Today, they often write their own scripts for custom hooks in ScriptRunner, which we then review, approve, and implement on their projects or repos. If their scripts turn out to be useful across all teams, we implement the new controls at global level. For example, one team wrote a local hook that searches through the checked-out branch name and extracts the Jira id, and when it finds it it then adds the [JIRA-ID] in the commit message. The local hook is automatically copied using git templates from a shared Bitbucket repository that the users clone. This reduces errors and the need to look for the JIR AID when working with multiple branches. We have plans to check JIRA ID status in the future and only allow ‘In progress’ tickets.

Adaptavist thanks GAIN Capital Productivity Tools Team Manager Nishaat Rajabali and Atlassian Specialist Tomasz Bryla for taking the time to share their experience in this post. 

GAIN Capital standardises and controls Bitbucket operation with ScriptRunner. Read our blog to find out how.

Getting Bitbucket control policies right at GAIN Capital 

GAIN Capital standardises and controls Bitbucket operation with ScriptRunner.

No matter how religiously we use Jira as an organisation, a certain amount of email communication is inevitable. Today we’re going to take a look at how you can work with email as part of your project toolbox, rather than fighting against it.

We’re also going to share with you five readymade scripts, totally free, to help you instantly supercharge your Jira mail management capabilities using ScriptRunner for Jira’s Mail Handler.

Allow users to add comments from their inboxes, automate issue creation based on email triggers, auto-create users, assign tickets and much more! Let’s go...

ScriptRunner Mail Handler is a feature found in ScriptRunner for Jira which builds on Jira’s native mail handling capabilities to give you more flexibility and more control.

ScriptRunner Mail Handler enables you to run groovy scripts when a message is received, letting you define both:

the criteria for action (which can be complex and multi-part if necessary), and;

what you’d like your Jira instance to do with the incoming information.

For Jira Server and Data Center, we’ve recently moved ScriptRunner Mail Handler into the main menu of the app too, to make it easier to find and start using (for those with smaller screens, search under 'More' as shown below!)

Since it’s script based, this feature can be used for all kinds of automations. Not only can these automations be used to save Jira admins huge amounts of time, they can be a great way to tighten up processes to ensure nothing slips between the cracks, and to improve both internal and external service management offerings.

If your groovy scripting skills are a little rusty or you’d like some inspiration for how you can start leveraging Mail Handler, here are some examples you can start using today, including free scripts for you to copy-paste from our Script Library.

Here’s the inspiration we promised, each with its own readymade script for you to copy and customise.

How to customise your Jira mail management

1. Create a new issue and set the assignee to CC’d user

Whilst standard Jira mail management allows you to create a new issue from an email, this script enables you to simultaneously set the ticket assignee to the first valid user who’s in carbon copy on the email (CC) in one fell swoop.

If you only want issues assigned to specific users, you can customise this script for your own organisation by defining a list of pre-approved assignees for ScriptRunner to check against. Get as specific as you need to make it work for you!

You may have some, ahem, Jira-resistant members of staff who insist on replying to issues they are mentioned in by continuing an email chain from their notification mail, rather than logging into Jira. 

With this script, your users can reply to the email and automatically add a comment to the issue mentioned in the subject line. Simple but effective.

3. Trigger new issue creation and assign to Epic from existing issue in email body

Plans change and move, via email as much as anywhere else, but this isn’t a problem if you can build for it. With this script, you can create a new issue and automatically set the Epic link based on the email content. It’ll comb the email, figure out which Epic you’re working on and create a new ticket within that Epic.

As with the other scripts in this post, you can customise this further to suit your requirements and handle any specific exceptions: we know that each business has its own needs. Unique and complex are two words that ScriptRunner is not fazed by.

4. Create new issue and set priority to match from email header

This is a powerful suggestion that can be used to great effect in combo with the other ideas outlined above. You can map the priority of the newly created issue in line with the priority of the email that triggered its creation. For instance, if the sender has flagged the email as high priority, you can automatically assign the corresponding issue as high priority in Jira. 

Don’t forget to outline a default option and feel free to add extra rules to determine an even more defined priority list, too!

5. Add a comment to the Service Management issue mentioned in the Mail Subject

This relates to the second script on our list but applies specifically to service management, allowing you to quickly centralise, scope and triage emerging IT or other service issues within your business.

Get ahead of your Slack/Teams notifications or the creation of 200 new support tickets by sharing instructions for anybody affected by a known issue to send an email with the ticket name in the header and detailing their experiences in the body copy! Empower your service management teams to centralise automatically, understand fully and act appropriately.

We hope this post has given you some inspiration for how these scripts could slot right into your business to start saving you some headache, or, better yet, prompt some additional ideas for how these free scripts can be tailored for your needs to remove more email triage from your day!

Try it free today to show your team what’s possible.

Check out this on-demand webinar as an introduction or refresher for the basics of groovy scripting! We’ll have you coding confidently in no time.

Looking for inspiration for how to automate emails related to your Jira instance? Check out these free scripts to get you started.

Next-level Jira email automation | How to automate emails in Jira

Looking for inspiration for how to automate emails related to your Jira Server or Data Center instance? C...

5 ways to make mail magic in Jira with ScriptRunner for Jira’s Mail Handler

Welcome to the final part of this blog series, where we’ve been getting under the skin of Data Center migration. We’ve already covered the following topics:

The big benefits driving businesses to choose Data Center

The final part of our six-part series looks at common concerns about making the switch from Atlassian Server to Data Center, and arms you with the advice you need to take the next steps in your migration journey.

Blog

All blog posts
Page 1

How your business can benefit from a learning management system

How agile team leaders can walk the gemba walk in a remote world

Transcript: Team Titans Season 2, Episode 3 - Matt Saunders

Migration from Jira Server: is it time for Atlassian Data Center or Cloud?

Getting Bitbucket control policies right at GAIN Capital

5 ways to make mail magic in Jira with ScriptRunner for Jira’s Mail Handler

Top three fears stopping you from making the move to Data Center (and why you shouldn’t worry)

3 top tips for promoting Jira configuration changes from staging to production

Transcript: The Atlassian Ecosystem Podcast Ep. 108 - The Long Holiday

A leap of logic – what to expect on Data Center

Striking a balance between flexibility and control in Bitbucket

Four facets of agility, part 1: being agile deliberately

Migration tools checklist: top apps to make the switch to Data Center

How to start a podcast the Adaptavist way

5 ways to customise your Jira issue view with Scripted Fields

All blog postsPage 1

All blog posts
Page 1