It’s official, Novoda has joined the ranks of more than 7,000 businesses in 92 countries that have achieved B Corp certification. We couldn’t be prouder of our team who have worked so hard to get us here, or more excited for what B Corp accreditation represents for the future of Novoda.

Becoming part of the B Lab global network means that we’re now part of a group of purpose-led, forward-thinking, conscious businesses whose mission is to transform the global economy to the benefit of people, communities and the planet. 

Now, that’s a big mission! So, let’s break it down and get a bit more personal about what B Corp status means for us and our clients.

What B Corp means to us

When we embarked on the Novoda rebrand, we knew we wanted to put doing good at the core of our business. We wanted to have a purpose that every single person in the company could unite behind. We had ambitious goals, and we were looking for a framework to help us achieve them – and that’s exactly what B Corp has been for us.

Joining the B Corp community has also opened the doors to an incredible network of like-minded business owners who share our philosophy when it comes to business for good, and who continually inspire us to keep learning and improving.

What’s more, having official recognition from B Lab gives us the confidence that we’re doing all we can to be a sustainable, ethical, person-centred business. Of course, there’s always room for improvement, and being part of the B Corp community helps us to keep thinking about the positive changes we can make now and in the future.

“The B Corp accreditation is the main reason I joined Novoda. I was drawn to work here because I have an innate desire to create a positive impact in the world, and I saw an opportunity for that.” 

Sarah Gruneisen, Director of Engineering

What B Corp has taught us

One of our biggest learnings from the B Corp process is that it’s within the power of ANY business – no matter your sector – to do good. We’re certainly not the same company that started this process, we’ve learned and reframed so much of what we believe and how we operate along the way.

We’ve always known that the people who work at Novoda are what makes us so special – and it’s been incredible to see how everyone has banded together during the B Corp process, wholeheartedly embracing all the changes we’ve made along the way. Knowing we’ve made this happen together has hugely strengthened our team. 

There is something incredibly empowering about coming to work and knowing you’re doing good in the world – that’s not an opportunity everyone gets. Going through the process has strengthened our foundational principles and positively impacted how we work together, the work we do and the decisions we make.

But the process has also taught us that there is still work to be done. We want to go above and beyond the B Corp requirements. For us, this process was much more than a tick-box exercise, and we’ll continue to focus on making more impact in our strongest areas of community, learning, wellbeing and reward.  

How B Corp has changed our approach to business

Our identity as a B Corp has become a fundamental part of how we operate – it’s not just a tag on to business as usual. We take pride in the fact that, together with thousands of other businesses around the world, we are working together to create something better.

It’s important to us that the clients we work with share our values and intentions, and we’re looking forward to our B Corp journey becoming a key part of our sales and marketing conversations. Having the accreditation means we can step confidently into these discussions and demonstrate our commitment to the B Corp vision for an inclusive, equitable and regenerative global economy in everything we do.

Interestingly, we’ve met very few fellow tech companies that have achieved B Corp status – but we want to see more of them. We believe that when you combine innovation in technology with a vision for a better world, incredible things can happen. 

For example, we would love to dig deeper into how technology can be used as a force for good in the areas of privacy, democracy and equality. Big tech has a bad reputation in these areas, but they need to be tackled – and we hope to see more funding and investment become available for this kind of work in the future.

“As part of the B Corp process, we had to sign a declaration of interdependence, showing that we are committed to working together with other businesses to make something better. I love this idea.”

Carl-Gustaf Harroch, Founder & MD

How becoming a B Corp benefits our clients

First and foremost, we are humans – it’s always been the case at Novoda, but now it’s written into the fabric of how we do business. 

We bring the human touch into everything we do – we aren’t robots with a rate card, we bring genuinely creative thinking that adds huge value to our clients. B Corp has given us a framework to align our products with our purpose, which isn’t the case for most agencies. 

As a team, we’re feeling motivated and inspired to apply our values to every single project we work on in the future and make great things happen as a result.

Considering becoming a B Corp?

Here’s our advice…

• Start now! It’s a long process and there’s no time like the present to get started on the journey. It will have a huge impact on your business and will prompt deep reflections that can be transformative. 
• Don’t think you’re ready? Look at your business carefully and be open to the possibility that you can have more of an impact than you think.
• Lean on and engage with the incredible B Corp community throughout your accreditation and beyond – the fellow businesses we’ve met have been amazing, leading us to excellent conversations and ideas on how to implement our ideas and aspirations.
• If you’re a service-based company, it’s easy to think you don’t have that many emissions – but you still do! We did a carbon footprinting workshop and it was eye-opening, one of our biggest impacts (and easiest to reduce) was from banking, which many businesses don’t think about.
• B-Corp is just the first step, together as businesses we have the potential to do so much more good in the world!

Want to find out more about working with us?

Book a discovery call and let’s talk about making good things happen for your business and in the world.

The post We’re a B Corp! Here’s what it means for our clients and impact. appeared first on Novoda.

Software quality is a measure of the degree to which a mobile product meets its specified requirements and users’ expectations, as well as the extent to which it is free of defects and represents a stable and maintainable system. 

Here, we look at the key ways to ensure exceptional software quality on mobile including the pyramid of testing, performance and stability metrics, scalability and maintainability. 

Unit, Integration & UI: The Pyramid of Testing in Mobile

Unit tests are a core part of a mobile developer’s arsenal, allowing us to capture and test individual components in isolation. Later down the line, this will help you detect bugs early, which is crucial before a release or hotfix, and also acts as a safety net – so you can be sure that internal architectural changes won’t break existing functionality.

You’ll often hear people talk about the pyramid of testing, with Unit testing sitting at the base. This is where you test each unit and component within your application. This level of testing is vital for maintainability because it makes it easier for people to work with your code – they know that if they change something, it won’t break any existing software, making changes much faster to test and integrate.

Next, you have integration tests which are about how the component you’re developing interplays with others. At this stage, there will be fewer individual tests because you’re looking at multiple elements working together, rather than every single isolated component.

At the top, you have User Interface (UI) testing. This tests your app from a user flow perspective, looking at how users interact with the product and validating that each user journey functions in the way it’s supposed to and that the product does what it’s designed to do. 

The idea of the pyramid is that as you progress along the testing journey, the complexity and cost of implementation go up. Therefore, you can make your Unit tests as thorough as possible, then you will need fewer Integration tests and fewer UI tests.

This is vital in mobile development as, due to the complexity of different parts and how they interact with one another, UI tests can be complicated to execute because they have to be run on real devices or simulators. 

UI testing for mobile products focuses on validating user interface elements, usability, user flows and journeys. These types of tests usually involve mimicking user behaviour to catch bugs that are specific to the user interface or experience. Delivering a polished interface that has been tested in every way it would be used is vital to ensuring the quality of your user experience. Ultimately, if a component isn’t going to work in isolation then it can’t be tested in isolation.

Testing & Continuous Delivery in Mobile Teams

Taking a continuous integration/delivery approach within your team means running your unit and integration tests with every single pull request (PR) cycle. Therefore, you want the unit test to be fast enough that at least part of it can be run as part of the local developer cycle. 

When it comes to UI tests, because these are longer and potentially more expensive to run (if you run them on device farms or similar) then you would ideally run them either as part of your release cycle or once a day. 

Although some larger companies have put in huge amounts of effort to be able to run UI testing to a certain degree on the PR cycle, your ability to run these types of tests depends on how much time and investment you’re realistically able to make as an organisation.

Performance & Stability Metrics to Determine Software Quality

The quest for perfect performance and stability for users is never-ending. Users are always going to expect perfection – and every time new hardware is released, it pushes the limits of existing apps.

Here are some key performance and stability metrics to consider as part of your testing and feedback process.

Crash rate

When it comes to software quality, the crash rate of an app is what impacts users the most – there is nothing more frustrating than a crash causing an abrupt end to a user’s experience, which is why this is the most common reason for bad reviews. 

Therefore, maintaining a low crash rate should be one of your mobile development team’s key goals. This comes back to having a complete test suite as outlined above, as the more journeys you can cover in testing, the less likely you are to release updates that result in crashes.

Startup time

Other key performance metrics to consider when it comes to software quality are time-based ones, such as startup time or time to interaction. Startup time is a key part of your user experience – if your app takes too long to load, users will bounce off before interacting with it. 

As the average attention span of users decreases, load time becomes increasingly vital. Studies have found that you have a maximum of five seconds to show an interactable element before a user dismisses the app as not working. 

Of course, there are some external factors at play here such as network speed, so it’s important to focus on factors which you can control. For example, depending on your audience you might have a high percentage of users on older devices, therefore you need to make sure you are still testing on these. An app may be working perfectly on your two-year-old device, but if 20% of your user base is using six-year-old devices then testing on these is crucial too. 

Time to interaction

High levels of responsiveness are key indicators of software quality. Studies show that when a user engages with your app, interaction time has to be less than a second – otherwise, users suspect something isn’t working. This can mean that users have less confidence in your product, as they don’t feel like they can trust their inputs are being registered. 

User reviews

One of the easiest metrics to overlook when it comes to your mobile app is user feedback – this is a great indicator of how stable your app is. It’s good practice to regularly analyse user reviews, and feedback to your team to identify where the user pain points are. User reviews can also indicate wider issues that may have been overlooked in testing and can be really descriptive, providing key test points for the QA team.

Change Failure Rate

Change Failure Rate is the rate of failure every time you make a change or perform a release. Failure can mean lots of different things – introducing a bug, a crash, or not meeting user expectations in some way. 

Monitoring how often these things happen when you make a change indicates how stable your overall application development process is. If you focus on lowering your Change Failure Rate, then as you’re moving forward, you can have more confidence that you can introduce change without introducing failure. 

Battery usage

Battery usage is a metric that’s unique to mobile development. If an app is functioning on a device, then it’s functioning on battery power. Depending on what your app is doing, it can severely impact the battery life of a user’s device – and users can see this in their device settings. If your app is responsible for using 40% of a user’s battery then they’re just going to delete it – unless you’re providing an essential service.

API calls can have a huge impact on battery usage, but there are plenty of ways to reduce this. For example, if you don’t require real-time interaction then you can ensure data fetching happens at the same time as other applications which is better for a device’s battery life. 

Often, people build apps just like websites with the mentality that if I need something, I query the API and I get it. Therefore, to reduce battery usage the key questions to ask as a team are:

• Which parts of the app need to be real-time and interactive?
• Which parts could be fetched ahead of time?
• Can we have pre-ached information in the app? 
• What is the optimal time to cache information?

Data Storage

Another unique factor to consider when developing for mobile is how much storage space your app uses on a device. People with newer devices are typically going to have more storage than older devices, therefore this is something you need to consider if you are looking to target a wider demographic. 

Caching is a great way to make things run faster and reduce battery usage, but if you are caching too much information then you may be taking up too much space on a user’s device. Therefore, it’s important to find this balance.

Raising Code Coverage & Reducing Code Churn

Code coverage refers to how much of your code is being covered by your tests. In the context of mobile, certain areas of code might not be as easy to test as others. For example, when you’re interacting with the UI path, you’re really close to a framework that you don’t have much control over because you’re working on Android and iOS code. This makes these elements harder to test, meaning your code coverage may not be as high as you want.

If you can’t raise your code coverage, then you will want to move complexity away from the areas that have low coverage. This way, you can keep confidence levels high when it comes to releases

Code churn is a way of measuring how often code is rewritten or changed. If you have a high level of code churn, this indicates maintainability issues as it suggests that you have a lot of interdependencies within your development process. Ideally, you want to write as much code as you can in isolation, so that when you introduce a new feature you don’t have to go back and make major changes to ensure it works. Not only is this inefficient, but it also introduces more risks of bugs.

Scalability of Your Mobile Software

When you’re scaling a product, you might experience a rapid boom in your user base the same way you would experience a sudden increase in website traffic. Essentially, this means that a lot more people are trying to access your back end – and you need to ensure your systems and processes can handle it.

Planning for Increased API calls

API calls are a key factor here. For example, we worked with a newspaper app that wanted to make sure all devices received the new edition every day. That meant a boom in users would result in an increase in API calls to their endpoint. As all the API calls were happening automatically at a given time, we needed to prevent them from inadvertently organising a denial of service attack on their own infrastructure. 

The answer for us was not to acquire the normal endpoint for this specific type of automated syncing. Instead, we did it in a specific place that was resilient to high traffic and high load.

This is just one example of how to consider scalability when your app interacts with the rest of your infrastructure, ensuring you think about how it functions and planning for periods of rapid growth in advance. 

Reducing Tech Debt

Tech debt refers to the implied cost incurred when businesses do not fix problems that will affect them in the future. Ultimately, accruing tech debt causes existing problems to get worse over time. And the longer debt builds up, the more costly it becomes to rectify – which can prove problematic when it comes to scaling your product. 

The key thing is to find the right balance for your product and for your team. You need to ensure that you aren’t over-engineering things at the start, but also that you aren’t compromising your efficiency by having to continually respond to fixing unforeseen issues.  

Maintaining legacy versions

Following a new release, you will have 100% of users updating to the newest version of your app. Therefore, you need to maintain and support legacy versions of your app. As you grow and scale, this becomes a compounding cost because the more versions you have out there, the more effort you have to expend ensuring you aren’t breaking compatibility with those older versions.

Eventually, if it’s costing too much, you will have to decide to stop supporting those older versions and force users to upgrade. However, when you do this, you’re potentially losing a percentage of your user base. Therefore, it’s important to weigh up the impact of this versus the cost of maintaining older app versions.

Maintainability of Software

Documentation

Insufficient documentation is one of the main system maintenance issues mobile teams face. And the impact of poor documentation is amplified in teams with a high turnover rate or where knowledge silos are common. 

Without appropriate documentation, you run the risk of key information being lost. Ultimately, this delays and prolongs critical bug fixing, reducing a team’s productivity and potentially causing critical quality issues for your app.

Code ownership

One of the biggest issues we’ve seen as teams scale is a lack of ownership around code. When you start scaling, you’ll likely have different teams working on different aspects of your product. If you’re scaling fast, your team might build the things they need, thereby creating pieces of code as they go that aren’t directly inside products. 

Without ownership, if a bug happens in this piece of code later down the line and you don’t know who’s responsible or able to fix it, then this can be a recipe for disaster. It can easily lead to a difficult team dynamic as people argue over ownership, slowing down the response to fix the bug. 

Therefore, making sure that you have defined ownership of code is key. As a rule, if nobody is going to be maintaining it long-term, don’t build it. This will drastically improve the maintainability of your system.

Modularity 

Another hallmark of a system that’s easy to maintain is modularity. This refers to keeping parts of a project separate or decoupled when they are related to and interact with each other. A clean, well-defined module, complete with clear responsibilities and dependencies. is easier to extend in the future. 

Modularity involves your team agreeing to follow a clear procedural structure, ensuring everyone’s on the same page with how it should look and how the different modules should interact with each other.

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How To Ensure Exceptional Software Quality On Mobile appeared first on Novoda.

Businesses have gone through the fastest pace of evolution we’ve ever seen over the last 25 years. Before the 2000s, brick-and-mortar was the most common business model – then came the first digital transformation.

The most successful businesses in the last two decades were the ones that went all in on their digital investment early, developing teams of engineers to deliver an exceptional web experience. At the same time, plenty of businesses created basic websites and employed a handful of engineers, then wondered why they weren’t able to compete. Now, we’re seeing a similar thing happening in the mobile landscape.

Businesses are seeing higher proportions of their customers moving to mobile, putting more demand on their mobile capabilities. Organisations are identifying the need to be mobile-centric and yet, often mobile is an isolated team and it’s not uncommon to see a team of 250 engineers where less than 10 per cent will be mobile developers. 

If you’re serious about competing in the mobile space and scaling fast, first you need to be prepared to invest in the right people – and hire enough of them. Then, mobile growth is about structuring your organisation in a way that enables your team of talented mobile engineers to work together efficiently and effectively.

Invest heavily in your mobile engineering team

We almost always see an imbalance in organisations moving from a web-centric to a mobile-first structure. Usually, they’re organised around web technologies, with full-stack engineers across teams that can work on the back end and the front end. Their mobile engineers, however, tend to just do the front-end work on Android or iOS, and end up on the sidelines. This differs from mobile-native businesses, which won’t usually have this division of frontend or backend because the only entry point for customers is mobile.

The most significant investment your organisation will make in mobile will be hiring, organising and structuring your teams. Ideally, they’ll be fully-fledged feature teams where mobile is wholly integrated – not added into operations as a silo. Ultimately, becoming mobile-led means moving to a more agile working environment where multifunctional teams with mixed skill sets are able to lean on each other and focus on what the end customer needs.

The companies with the most advanced mobile capabilities today are the ones that started with mobile growth in mind and prepared for this from the start. Whereas, those that started with a purely web-centric focus have found that adding in mobile operations has gone against the grain of their company structure. Before you put any major investment into mobile, this operational risk needs to be mitigated by assessing and reorganising how you operate. Otherwise, you’ll bring mobile in as an experiment or add-on and it will stay on the sidelines. 

The key way in which mobile differs from the web is that you’re shipping a single-built artefact on a centralised platform which is all built in one place. This monolithic technology can reinforce a structure where a single team is in charge. So, if you want to effectively distribute your tech stack and organise your teams, you need to think outside of the box – finding a way to overcome this tension with the technology and creating a distributed way of working.

Understand exactly what you need from your mobile capabilities

There’s no way around it – building fully-fledged mobile capabilities into your organisation is a huge investment. The main advantage of having an app is that it places you on the main screen of a customer’s device, making it easy to send notifications and keep your users coming back. You have a captive audience, with the potential to become part of a person’s daily digital habits. 

The key questions to ask yourself to determine whether you actually need a native app at this stage of your business are:

• Who is our target audience?
• How do they engage with us? 
• Am I losing out to the competition by not having an app?
• Will a mobile app actually drastically change my customer engagement?

If anyone comes to us without a pre-existing product, we usually advise that they start with a mobile web solution and test it with users until they can clearly see the benefit of developing their own app. Building an app is the biggest technological investment you will make for your business, you don’t start there unless you can make a large investment – it’s best to wait until you have proof of concept and it becomes a necessity. 

If you offer a service in the realm of travel, health, finance or leisure, you’ll also want to look at what your competition is doing. For example, Lloyds Bank didn’t have a mobile engineering team until 2017. Then, Monzo came along with a team of 200 mobile engineers, ready to cater to a whole segment of younger, mobile-led users.

Lloyds had a basic app, and up until this point, if you had a Lloyds account then you probably weren’t going to switch banks based on the user experience of an app. However as consumers’ needs and preferences shifted, Monzo was there to meet demand with an app experience that was significantly better than most other banks. 

Suddenly, organisations that hadn’t been threatened by not having a dedicated mobile offering found themselves in a situation where it was essential to compete in the market. Consumers had begun expecting to be able to quickly check their bank accounts on their mobile devices – and not being able to do so was significantly impacting their consumer experience. 

Understand that mobile success is much more than just an app

When we talk about mobile capabilities, we don’t just mean your app. If you want to be a mobile-led business, you need to think about a far bigger picture. Not only will you need engineering to build the application, but you’ll also need product expertise, an in-depth understanding of user engagement and how consumers interact, integration of multiple technologies, and a full understanding of the user’s mobile journey. The app is just one part of your tech stack. 

When we talk about mobile investment, we mean your mobile capabilities as a whole – because this is the core difference between a business that wants to be mobile-centric and one that simply wants an app. 

If you’re serious about mobile growth, just one year of employing a senior team of developers, designers, and product owners with the capabilities you need will be a huge investment in itself. For any company that’s not ready to invest in that, our advice is to focus on an exceptional mobile website. 

Cross-platform isn’t necessarily cheaper

We speak to many tech leaders who look at cross-platform technologies as a way to reduce costs – but this isn’t necessarily true. 

We’ve worked with plenty of clients who told us that they’re fed up with having separate iOS and Android teams because they’re maintaining two code bases that need aligning in terms of feature sets, dedicated skills and training, and code that needs to be re-written twice when changes are made. From a CTO perspective, it’s easy to see how the ideal solution feels like having one front-end technology. But unfortunately, it’s not that simple.

Tech leaders are attracted to React Native or Flutter because they see that they can have one team that’s not split between iOS and Android. They tell us that their Android team doesn’t even talk with their iOS team, let alone talk with their back-end team, and they just want to get to a place where they aren’t having to explain and implement everything twice.

But with these cross-platform tools, there’s still a lot of consideration and cost, including maintenance, investment in the technology, learning, training, recruitment, and the ability to talk that language. If your teams don’t talk to each other and you’re looking at cross-platform as the answer, then you’re applying the wrong solution to the problem. Bringing in any cross-platform tool requires a lot of coordination, and it’s definitely not going to be feasible if your teams aren’t coordinating effectively already. 

While cross-platform might save costs or speed things up when you’re a small start-up, as you scale and the complexity of maintenance increases, it’s unlikely that cross-platform will continue to deliver the same benefit. At this stage, you will still require native platform skills within your teams, but you’ll also require the skills to manage the cross-platform solution you’ve implemented. 

In our experience of working with large, mobile-centric organisations, once you reach a certain size it doesn’t matter whether you have a cross-platform solution or native teams – you’ll pretty much always end up with the same amount of engineers dedicated to maintaining the framework and having to do additional work on top. Big businesses have complex code bases, and complex code bases come with their own sets of problems – unfortunately, there is no one-size fits all solution. At that scale, cross-platform or native is no longer a cost or efficiency decision but becomes a resource and organisational one.

Set yourself up to experiment and take risks on mobile

A key part of being a mobile-led business is leading your product development through mobile experimentation. If you aren’t prepared to experiment on mobile – which is often more complex than experimenting on web – then you’ll continue to experiment on web. Then, when you translate the features to mobile, you’ll simply end up with a version of your web experience there – which defeats the object. 

When you experiment on mobile there is a lot more work involved compared to web. You need to build it, deploy it, and maintain versioning. And if your experimenting leads to a crash, it creates a bad user experience which you can’t fix until you deploy another update. It’s not like on web, where you can simply roll back a change, refresh and continue. 

You need to invest in an environment that enables experimental practices for mobile, ensuring you’re in a position to be able to run experiments and drive your product from a mobile perspective.

Invest in experts to get the best from your mobile team

Ultimately, there is no low-cost, low-risk way to invest in mobile. And it’s far too complex and unique to each organisation to put a price tag on it. Getting the right technology, product thinking and engineering in place to deliver what you need to scale your unique product is a balancing act – and it pays to get the right expertise to set you up for success. 

If you’re serious about scaling your mobile capabilities efficiently – talk to us. Our goal is to ingrain the mobile-first practices, processes and mindsets you need as a business to scale quickly and efficiently, starting with our mobile team efficiency audit. 

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps. Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How Much Should My Business Invest In Our Mobile Capabilities? appeared first on Novoda.

In larger organisations, mobile engineering teams often end up working in a silo. Understandably, this makes communication across teams a challenge. But for any organisation that’s serious about scaling its mobile capabilities, effective communication within mobile engineering teams and across the organisation as a whole is vital – especially given the prevalence of remote and hybrid working.

In this article, we explore the reasons why mobile teams get siloed, how Mobile DevOps aims to bridge the operational gap between teams, and the key principles of exceptional communication within mobile teams and organisations as a whole. 

Why do mobile teams get siloed?

There are a multitude of reasons mobile teams become siloed, the most common is due to historical organisational structures. Many of the businesses we work with existed for years, perhaps even decades, before native mobile development was a priority for them. Consequently, their organisations are structured around their web capabilities or, in some cases, bricks and mortar locations and operations. 

Did your organisation first launch its mobile capabilities as an experiment? And today, even though mobile has now become a central part of your business, have you shifted the way you function to accommodate that? If not, you’ve likely ended up as a fully structured business with a mobile team bolted onto the side, which struggles to fully integrate with the rest of the company. 

The mobile tech stack is a contributing factor to this siloing of teams as well. By design, mobile apps are a monolith. They have to be shipped whole as a package, making it easier to end up with a centralised team. While web and backend have shifted to microservices, micro frontend, and other technologies to support more distributed teams, mobile has to do without the ability to decouple that much of the tech stack.

Since mobile engineering teams end up being siloed, their skill sets and experience remain very different compared to everyone else in the organisation, which doesn’t encourage diversification. Within a large company, it’s not uncommon to have a team of mobile engineers who have only ever worked on mobile. This lack of wider experience can make them more reticent to open up and be part of discussions with back-end engineers and other team members. 

Thanks to these and various other contributing factors, mobile teams are in danger of becoming isolated. As a result, communication suffers – which means that collaboration, morale, productivity and innovation suffer too.

Bridging the communication gap between your teams

As Mobile DevOps specialists, we look at how we bring the core principles of DevOps to mobile development. Mobile DevOps isn’t completely new, and we don’t want to create a completely new structure for mobile teams that’s entirely independent. Instead, we want to bridge the gap between existing DevOps processes and mobile operations, ensuring we address the specific quirks and requirements of mobile while integrating teams to make communication easier. 

When we work with any company, we aim to look at how we can bring learnings together from across the organisation, integrate mobile engineering processes with the rest of the business, and mitigate the specific challenges and pitfalls that mobile presents without causing the mobile engineering teams to feel isolated and separate.

To successfully implement Mobile DevOps processes that work in the long term, communication is the most vital component.

Managing remote teams with asynchronous communication

Now that remote and hybrid working is pretty much established as the new norm in tech companies, effective, asynchronous communication is a vital part of day-to-day business operations. To make remote or hybrid working truly work for your organisation, it must be fully embraced, with remote communication policies and expectations clearly documented and defined.

In remote or hybrid teams, your processes need to ensure that everyone can work and communicate effectively in an asynchronous way, especially if you’re operating across multiple time zones. There’s no definitive answer as to the best communication method – you might use Slack or a project management tool – but the key principle is that not everything needs to be a meeting.

In hybrid teams, if you have ad hoc conversations on-site, you must always bring them back into the async channel to update the team members who are working remotely. Make it a rule to never have conversations or make decisions that do not get translated back into this channel immediately to keep everyone in the loop. 

Hybrid meetings are never effective

If you have hybrid teams where some people are on site and some people are remote, and you need to run a meeting, then everybody should dial in remotely. 

When you have half of the attendees around a table and the other half dialling into the room, the people dialling in remotely will likely miss key points and struggle to engage in the discussion. It is always far better practice to have fully in-person OR fully remote meetings, having everyone on-site using noise-cancelling headsets or finding their own meeting room to join from.

Implementing effective meeting practices

It’s always easier to implement effective meeting practices when facilitating in person and it’s easier to ensure everyone feels heard, seen and respected because you’re in the room. One of the main reasons online meetings can be so challenging is that you can’t read the visual cues telling you when someone is trying to speak.

It takes more work and planning to facilitate effective online meetings, but if you invest the time and effort then it makes a huge difference to the extent to which people feel able to engage and participate. Generally, it’s more difficult for everyone to pay attention in remote meetings because they’re not fully present and are easily distracted by notifications pinging at them or things happening around them at home. 

Therefore, as a facilitator, you will need to work harder to ensure you mitigate distractions and keep people engaged. This can be facilitated even easier when using meeting practices like liberating structures as an example.  In longer, larger meetings you may want to implement breakout sessions where people can contribute to a particular issue in a smaller group. This might feel less intimidating to some people and give them more time to share and explore their insights and perspectives. 

As a rule, if someone is not contributing to an online discussion for more than 10 minutes, it’s unlikely that they’re still listening. Building in opportunities for everyone to have their say boosts engagement and leaves your team feeling like their contribution is valued. 

Ensuring everyone gets their say

Implementing regular, ultra-focused tactical meetings and stand-ups is an effective way of ensuring everyone has an opportunity to raise their concerns, questions or tensions. During these meetings, your structure should ensure that everyone has a chance to speak and that there is a clear decision-making process. 

We’ve all been in those online meetings where you don’t know when to speak up because as soon as you open your mouth another person starts speaking again. By having a clear turn-based structure, you ensure meetings aren’t dominated by the loudest voices. 

Check-ins and check-outs

One of the best practices we have introduced at Novoda is the check-in/check-out for all our meetings. The check-in allows everyone to get a sense of everyone’s mindset coming into the meetings. Allowing all attendees to share what they are dealing with means that, as a facilitator, you can easily tell if you are going to be able to hold everyone’s attention or whether it would be better to reschedule for a time when everyone can give the meeting their full attention.

For example, if somebody comes into the meeting and says: “I have an urgent support issue I’m working on and I’m feeling anxious and distracted,” then you have the opportunity to reschedule the meeting with no judgement. 

The practice of checking in is also important for creating a culture of psychological safety within your organisation. It ensures that before every meeting you are checking in that everyone feels able to be present, and whether there is anything that needs to be addressed before the meeting begins that’s going to prevent people from being able to contribute.  

The check-out allows people to comment on what went well in the meeting and what didn’t, which factors into your continuous improvement. It provides an opportunity for people to raise any issues, such as feeling like their points didn’t get discussed, or that a method of communication didn’t work for them, which gives you the opportunity to improve the next meeting you have.

In order to keep psychological safety, it’s important that the facilitator listens to everyone’s checkout feedback without judgement or defensiveness, validating any concerns and taking time after the meeting to learn from the experience and note down actions and considerations for future meetings.

Managing tensions effectively

It is vital that your organisational leaders can facilitate and create space for effective communication and remain objective when people are raising tensions. It’s likely that in an environment of open communication and transparency, there will be times that team leaders feel attacked by someone raising a particular tension and allow their defences to rise.

In these scenarios, it’s important that your leaders learn to self-regulate their emotional responses and set a precedent for how the rest of the team deals with conflict. If your leaders struggle with this, it is a sign to invest in further facilitation or leadership training to support them in key areas of communication. 

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How to create exceptional communication with mobile engineering teams appeared first on Novoda.

By Sarah Gruneisen and Benjamin Augustin

As an engineering leader, fostering a culture of psychological safety should be a priority. In a psychologically safe working environment, people feel included and respected, and able to share their ideas, questions or concerns without fearing repercussions for any mistakes or failures. 

Creating a culture of psychological safety is essential for innovation – without out-of-the-box thinking, trying and failing, there can be no progress. Therefore, it’s arguably one of the most important things for engineering leaders to focus on when it comes to improving their leadership skills.

Everyone has a ‘hierarchy of needs’

You may already be familiar with Maslow’s hierarchy of needs, which remains an excellent way to demonstrate the importance of psychological safety in the workplace.

The base of the pyramid represents our most fundamental physiological needs (e.g. food, drink, and shelter), followed by safety needs (e.g. security, stability, and well-being), then love and belonging needs (e.g. trust and acceptance), and esteem needs (e.g. dignity, achievement, respect). 

Only when your needs are met at one level, can you progress to the next level of psychological safety. Eventually, you reach self-actualisation which is all about fulfilling your potential and personal growth – and that’s where true innovation and creativity happens. If this is what you want as an organisation, your people must have their needs met at every level.

Right now, amidst the cost of living crisis, many of your team will be feeling like the base of their pyramid is unstable. Their concerns are probably feeling impossible to leave at the door when they come to work, such as:

• Do I have enough money to feed my family and pay my bills? 
• If I have to get to the office and back each day, who is going to pick up the kids after school? 
• Inflation is going up, will I still be able to make my mortgage payments?

As leaders, if we want our organisations to grow and prosper with healthy, happy teams who are capable of doing their best work, we need to do what we can to actively support them not only to survive but to thrive.  

Building your team’s confidence and esteem

A key area that workplace leaders contribute to is employees’ esteem – their sense of feeling valued. In your words and actions, focus on answering your team’s inner questions:

• Am I seen and valued?
• Am I empowered? 
• Does my boss know or care what my talents are?
• Are my skills being used?
• Does anyone care about my ideas?
• Do I feel appreciated and supported?

Let’s say you have an employee with ADHD and they’re exceptionally good at coming up with creative ideas and getting started on projects, but they quickly get disconnected. They’re hugely proactive and motivated, but they struggle with the finer details and finishing off the last 20% of a task. 

As a manager, if you only ever focus on that last 20% in every one of their appraisals, telling them that they don’t finish projects and aren’t good at the details, they are going to end up feeling like a miserable failure. They’ll worry that their job is on the line. They won’t feel valued or empowered. They won’t feel like their talents are being used. And so, they’ll never reach a point of being able to contribute to your company at the highest level of their potential.

This scenario is true for anyone, not just neurodivergent members of your team.

Understanding and fulfilling your team’s values

Do you know the core values of the people in your team? Do you know what they need and want as individuals to thrive in their roles? If not, organise a values workshop to find out what environment they need to feel nourished and energised. If you try to plant a seed in a desert (rather than a tropical forest), it’s going to take a lot longer to grow. 

Everyone’s values are equally important and it’s perfectly possible to build a team that meets everyone’s needs. Let’s say you feel someone in your team is not making an impact on your business development goals. You might say to them: “I want you to speak at conferences, you need to get your voice out there!” 

If they’re introverted and they tell you that they don’t want to speak on stage, listen to them. They can still make an impact, but in a different way that respects their values and preferences. They don’t need to be loud or stand on a stage. It won’t feel authentic to them and it’s likely to make them feel deeply uncomfortable – possibly even fearful. 

Instead, explore other ways they could make a difference. They might be better at one-on-one interactions, writing blog posts or contributing their expertise to articles or podcasts which can have just as big an impact. If they are an artist, they could even make a small cartoon series describing tech how-tos, etc.

An exceptional manager asks, who are the individuals in my team? How can I support them to make an impact using the skills, talents and preferences that they have? How can I create a space where their values are honoured? This is psychological safety. 

Fostering a failure culture in your team

Understanding and respecting people’s values and making sure everyone in your team feels able to contribute is vitally important for innovation. Equally important is fostering a culture of failure.

In organisations with good failure culture, people know that failure is not a reflection of who they are as an individual – it’s the result of trying something new that you can learn from and move forward with.

During project debriefs or post-mortems, avoid pointing the finger at people. Instead, point a finger at the actions (or lack of action) that led to the outcome. Then, as a team, look at what everyone can do collectively and proactively to avoid that outcome in the future. 

When you pass judgement on or blame an individual for failures, that person is unlikely to try anything new again. Now, you’ve killed innovation within your team because you’ve said to them: “Don’t try anything if you’re not 100% sure it’s going to be a success, or you’re going to be blamed.”

Blame culture is the opposite of failure culture – and as well as damaging team well-being and morale, it can damage your business too. In a blame culture, the things you need to know as a leader will be hidden from you, as people are more likely to shut their eyes to problems than risk speaking out and being punished. 

You want people to feel safe enough to have tough conversations and bring challenging issues to light. Not only will your team feel valued and more productive, but you’ll get the insights you need to drive your business forward.

Don’t have team heroes

Most teams will have a “hero.” This is a person who’s doing brilliantly and smashing their personal development and individual work goals. As a leader, it’s natural to want to sing their praises, reward them, give them raises and tell them they’re doing amazingly. Meanwhile, the rest of the team – who for whatever reason haven’t been able to achieve their goals – don’t get rewarded. 

In this scenario, the heroes – often the go-getters and perfectionists – will stop helping their team because they’re doing fine on their own. And so, when the team is struggling, they’ll focus on perfecting how they show up and do their job to get that next raise.

Controversially, we need to stop rewarding the heroes. Either everyone in the team wins, or everyone loses. If you have a team hero, ask yourself why everyone in the team is looking to the same person for help. What knowledge or skills do they have? Why aren’t they sharing this expertise with the team? Why are other members of the team feeling that they need to work late or work weekends to “catch up”?

No team is successful because of one individual’s success. Having an irreplaceable “hero” on your team doesn’t make your team a highly successful one. A highly effective team is one where everyone is able to contribute efficiently and feel like they’re equally valued and part of the team.

Take the opportunity to enable and empower that irreplaceable “hero” to take on the role of mentor or trainer, bringing others up and spreading their knowledge. This will lead to a much more balanced and productive team environment.

Lead by example

Engineering leaders are the ones who drive cultural change in organisations. For example, if you want to shift away from a culture of overworking, then as a leader you need to set an example by not working overtime and setting boundaries around your working hours. 

It’s the same with psychological safety – leaders must be the drivers of the culture shift. If you want to create a failure culture, the first step is to acknowledge and celebrate your own failures as a leader. Raise up your hands and say: “I messed up. This didn’t go well” and invite the team to engage in dialogue around what happened.

Psychological safety enables powerful communication

When your team feels a lack of psychological safety at work, communication suffers. People in trigger mode aren’t in talking mode. And if, as a leader, you don’t understand the needs of the individuals in your team, you can’t hear them when they express those needs. This leads to feelings of frustration and disconnection.

Psychological safety also creates the ability to have courageous conversations about difficult things. If you’re being micromanaged and checked up on constantly, causing you increasing stress, then you might well snap, shout at your manager and tell them they’re making you angry and anxious. Whereas, if a culture of safety is in place and you feel able to communicate, you might say: “Today you’ve asked me to update you four times and it’s making me feel stressed, distracted, and like there’s a lack of trust.” You can express and own your feelings, show you value your autonomy and know that this will be respected.

When you can share your feelings in this way, it opens up a conversation about personal values – and you can work together to find a solution that honours and meets both your needs. In this scenario, that might be agreeing to message once a day about your progress, or promising that you will let them know 48 hours in advance if you anticipate any delays. This way, you get to keep your autonomy while honouring your colleague’s values. And that’s only possible when our needs of safety, belonging and esteem are being met.

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post Creating a Culture of Psychological Safety in Engineering Teams appeared first on Novoda.

By Sarah Gruneisen and Benjamin Augustin

The essence of great leadership is getting a group of diverse, highly passionate individuals unified and heading in the same direction. It’s building a team that knows where they’re going, that’s connected to the reasons why and that’s clear on what they’re trying to achieve. Achieving this holy grail of leadership ultimately comes down to having a vision and communicating it well. 

A vision not only tells everyone what you’re doing as a business, it works on a product level too. If you’re creating a product and don’t have a clear vision as to why the product exists, who needs it, what people want from it and what pain points it addresses then your engineering team won’t connect to that product – they’ll just write code. The product might turn out well, but it won’t be amazing. Because if you want to knock people’s socks off, you need passion behind a product. 

What happens in an engineering team without vision?

Without a unified vision – and we’ve seen this happen many times before – teams tend to create one anyway. Then you end up with a bunch of different visions, teams working in silos, and everyone becoming disconnected from what you’re trying to achieve as a business. While everyone may be doing a lot of work, it’s not work that’s needed. And eventually, they’ll get disheartened because they’ll feel like nothing they do is good enough. 

On the flip side, you can also end up with people having no vision and doing only the bare minimum. They see their job as taking a ticket, doing the ticket and not asking questions. And this doesn’t work either. 

One of the core tenets of Mobile DevOps is ownership, accountability and autonomy for every individual in an organisation. If you want people to be able to drive initiatives from the beginning right through to delivery, they need to understand why they’re doing it and how their role fits into the bigger vision.

Enabling engineers to ask the right questions

We often speak to engineering leaders within large organisations who feel like their engineering teams “aren’t passionate enough” or “don’t care about the product.” In most of these cases, we find talented engineers who care about their work but who are feeling disconnected from the rest of the business. 

It could be that the engineers aren’t included in decision-making so they don’t know why the business priorities shift, or it could be that the work environment doesn’t empower them to ask questions. Whatever the underlying factor, once we identify and address it, we find those same engineers suddenly empowered to bring passion and creativity into their work, shine in their roles and proactively work to improve business outcomes.

Having a vision that everyone understands and embodies not only enables your engineering team to write good code, but to have tension towards the product and continually question their work. An engineer’s most valuable skill is looking at something and seeing what could be done differently to achieve an outcome. For example, the iPod would have never been created if Apple’s company vision didn’t empower its engineers to question WHAT they were doing in order to achieve the WHY. Without this enablement, we might still have drop-down, functional menus leading with “Start”.

To create a working environment that welcomes and encourages questions, we recommend scheduling two separate refinement sessions. The first is purely for asking questions – why are we doing this? Is it critical to our business? Is it bringing our product to where we want it to go? Is it what the customer needs? The second is to discuss solutions. 

Empowering engineering teams to innovate

When you get your teams truly connected to a product vision, the outcomes can be genuinely surprising. For example, we worked on a project for a popular TV channel in the UK looking at their content playback on various devices. A huge part of their product was ad integration and they had a simple system in place which loaded the adverts in the same way as the content. 

The viewing experience was frustrating, as the ad content needed to load and reload and was being interrupted by buffering. And yet, their vision was to bring the best entertainment experience and to make people happy. 

Adverts were a critical part of their business model, but we needed to stop them from causing such a disruption to viewing – because that wasn’t aligned with the business vision. Our engineers came up with an idea to create a unified feed which integrated ads within the content, so the show would start buffering while the ads were running for a seamless viewing experience. 

Nobody at product level would have known this was possible. For them, the process was just, adverts then show. But from an engineering perspective, we could see the gap between the current product and the vision. This solution didn’t come from customer feedback or the product teams, it came from the engineers’ understanding of what was possible within the context of the vision.

To use a different example, let’s say a customer is looking out of a window at a tree and says:  “I want to touch the tree outside the window.” The product team might come up with the solution of going downstairs, walking around the building and crossing the road to touch the tree. But, if we take a moment and ask as a team why the customer wants to touch the tree, product can understand that the customer just wants to feel the fresh air, and engineering can recommend that we open the window to achieve this. It’s by communicating and working together that we achieve the best outcome for the client.

Essentially, engineers ask the right questions and find an alternative way to do things. It’s rare for customers to think that way – not because they can’t think that way, they are just often not aware of the possibilities. Therefore, the only way you can get to those amazing, simplified solutions is to bring your engineers to the vision. Engineers are inventors and artists who want to get excited and be part of the solution – they’re not just developers.

Communicating your vision starts with leadership

Just like any challenge you’re looking to fix in a team of engineers, unifying a team behind a vision starts with leadership. If leaders can’t communicate a product vision to their teams, making each individual feel like part of the solution, and giving them the autonomy to operate within their role, then there’s no benefit to having a vision. Teams will become just as disconnected as if there were none at all. 

How do you communicate your vision effectively?

Repeat, repeat, repeat

You have to repeat, repeat, repeat the vision. Over and over. It has to be in every single presentation and in the background of every single conversation. Your team has to see it all the time. It has to become embodied within them. This doesn’t happen with just one presentation that says: “Here’s our vision!” 

If you don’t talk about your vision often enough, people will forget about it. So, whenever you have a decision to make or have to prioritise, always reflect back on the vision. Whatever action brings you closer to the vision, that becomes the priority.

Make it tangible 

Make sure your vision isn’t abstract. Paint a picture of what it looks like in real terms. If people aren’t sure what it looks like to have achieved the vision, then they won’t be clear on the action to take to move towards it.

Simplify

If you can’t explain your vision in two sentences, it’s too complicated. Simplification can be tough, so work on it as a team. Once you can explain it simply and succinctly, it becomes a mantra you can repeat when making any decision to make sure you’re making the right choices.

Break the silos

Bring every single person in your company into the overarching vision. This expands peoples’ horizons and ensures everyone within the business understands the bigger picture that goes beyond their work and their team. Bring engineers into a product’s lifecycle as early as possible, so they can be a part of these early decisions and bring their knowledge on board from the start.

Create sub-visions

The overarching company vision might not feel relevant to every team within your company. In this case, teams can create sub-visions for different products. This way, every product has its own sub-vision that connects to the top vision, making it feel more accessible and meaningful for product teams.

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How To Communicate Your Vision & Why It Matters appeared first on Novoda.

Continuous improvement is a practice that involves a loop of reflection and adaptation and improvement as part of the work process. It encourages learning and iterating, which is a vital element of a successful Mobile DevOps strategy. 

Having a culture of continuous improvement within your mobile developer teams ensures you remain effective as you scale – and most importantly, that you don’t scale problems with solutions. 

In this blog, we delve deep into how to create a culture of continuous improvement within your mobile teams and why it matters if your organisation wants to master a mobile-first mindset and approach.

Scaling products without scaling problems

When you write new software, you start out small. Most likely you’ll take a pragmatic approach that works within your existing business context. And that’s quite right, because when you’re just starting out you don’t want to over-engineer your processes – the priority is getting your product out there into the world.

The trouble is, if you don’t have a system for continuous improvement in place as you scale, then you’re in danger of ending up with a bigger version of that first prototype – and as most of us will agree, first prototypes are horrible. 

Balancing simplicity and over-engineering

At Novoda, we’re rarely involved in a product from the start, which means we often end up coming in to work on a product that’s been around for a while. Consequently, we often see one of two problems:

1. The team have never learned how to build mobile products at scale. They’re learnt as they go and they’ve gotten pretty good. But then things have plateaued. In these cases, we’ll usually end up taking them back to the beginning to rebuild things from the ground up. Not only does this take a lot of time, but it can be daunting when everything you’ve built needs to come apart and be built back the ‘proper’ way.
2. Products have been over-engineered from the start because the team of engineers felt that they had to tick every box before they scaled and plan for every eventuality. This means they’ve spent a lot of time and effort building things their users don’t need, or they’ve taken so long to get to a point of delivery that the feature isn’t needed anymore.

Embedding a culture of continuous improvement within your mobile teams aims to stop either of these scenarios from happening. 

Channelling creativity towards solutions

Engineers are creatives and often have a siren pull to their ideas. Within mobile teams, there is always a tension to be managed between giving space for people to experiment and explore those new ideas and innovations without encouraging them to go off and do whatever they want regardless of whether it benefits the business in a real, commercial way.

When you have a robust continuous improvement process in place, it’s much easier to strike the balance between allowing that creative freedom and ensuring it’s channelled towards the highest priority solutions.

Balancing long-term objectives with responsiveness

A lot of people think ‘agile’ means working without a roadmap in order to be wholly responsive, but that isn’t the case. Agile doesn’t mean reactive. In fact, it’s all about continuous improvement. 

When you’re building any mobile product for a large, scaling organisation, it’s vitally important to have a clear roadmap with key objectives to hit along the way. That doesn’t mean you don’t leave space to be responsive to customers’ feedback – this is a hugely important part of an agile methodology – but it does mean that you can conduct a risk vs reward analysis on improvements and new features before you start to engineer them.

Your product managers may be pushing to put out feature after feature – and quite rightly because the customers are asking for them. But what the customer is asking for might not always be the right next step for the business’s long-term success.

If you’re asking developers to churn out feature after feature and by doing so they neglect something that slows down the overall development of a project, then ultimately you’re going to end up rolling out fewer features because a bigger problem will arise that needs fixing. 

Ensuring retrospectives are effective

Within a culture of continuous improvement, you need effective retrospectives with concrete actions, assigned to individuals. It’s easy for retros to become a complaining session where people moan about the same things week after week, but they need to be focused on immediate solutions and the bigger picture. 

Often in retros, people focus solely on existing processes – what has been done and what needs to be done. Less often, teams step back and ask: do we actually have the right process? Do we need to remove some aspects? Are we doing the right thing here? Effective retros aren’t necessarily about how to do things better, but whether you’re even doing the right thing. 

Following on from retros, you then need to measure the impact of any improvements or changes you’re making. You don’t want to keep jumping into new ways of doing things if you don’t have proof that productivity and quality are improving.

Prioritising changes

Without a framework in place for objectively prioritising work, meetings around priorities can easily descend into conflict with everyone wanting their priorities to be everyone else’s. 

One of the ways we use to objectively prioritise work is the RICE method, which asks:

• Reach – how many people will this reach and affect?
• Impact – what impact will this have on our business?
• Confidence – how likely is it that this project will be successful?
• Effort – how much effort will this take to implement?

Using this framework, everyone in the team scores each proposed change anonymously which produces a number or ranking that determines a task’s priority.

Moving people between teams

Considering different perspectives and alternative ways of thinking is vital for a culture of continuous improvement within mobile engineering teams. As Conway’s Law states: 

“Organisations who design systems are constrained to produce designs which are copies of the communication structures of these organisations.”

If you have multiple product teams within your company who work in silos, you can end up fostering an ‘us vs them’ mentality, with each team bringing different perspectives to meetings and arguing their points of view. 

However, if you move people around between teams means, you can introduce new perspectives and bring in fresh knowledge, ideas and creativity. Not only does this lead to greater innovation and faster improvement, but it can result in greater job satisfaction for your team too.

Engineers tend to change jobs every couple of years, but by allowing people to regularly work on new projects with new teams, you can offer them a new challenge and learning environment without them having to change jobs.

Balancing maintenance and innovation

One of the biggest threats to continuous improvement within an organisation is not getting the balance right – often, we see companies doing too much or too little.

Every time you make a change, your mobile teams will go through the process of:

• Forming – getting used to changes and forming new ways of working
• Norming – embedding changes so that they become the norm
• Performing – hitting their objectives and performing well together
• Storming – ramping up innovation and creativity to exceed objectives

If you’re shifting your processes or your team structures too often, it’s difficult for teams to get to a place of performing because you’re keeping teams in the forming and norming stages and they miss out on opportunities to grow together.

As soon as you add a new team member or change a process, your mobile teams are back in a place of forming, trying to get to norming. They never get to perform and storm which can have a detrimental impact on your product quality and innovation. 

What’s more, if you’re continually bringing in new things which your engineering teams need to spend extra time and brainpower getting used to, this might cause them to neglect maintenance, leading to cracks in your foundations. Worse, you might even end up with dysfunctional situations where people are having to work overtime to keep on top of everything which is more likely to lead to burnout. 

Ensuring observability is meaningful

Within a continuous improvement culture, observability is essential to ensure that processes are not deteriorating over time and that improvements are adding genuine value. 

Observability can be defined as the ability to ask any question of your system and have it answered. It’s not about micro-management, it’s about ensuring you can identify what happened whenever things go wrong and spot small issues before they become large-scale problems. It’s about observing the right things that are going to tell you what you need to know about the quality of your work. 

For observability to be effective and accurate, it’s crucial to ensure you aren’t measuring something that can be easily manipulated. For example, you might want to bring down the number of bugs as an indicator of work quality. But on the other hand, you want people to find bugs so they can fix them. If engineers are being measured against having fewer bugs in their work, they might be less likely to find them because they want to be seen as performing well. Ultimately, this isn’t going to serve your business.

Alternatively, if you’re measuring how often a system crashes, that’s an objective measurement.

Conducting pre-mortems and post-mortems

As part of our culture of continuous improvement at Novoda, pre-mortems and post-mortems are one of the most useful things we do. 

Before we begin any project we start with a pre-mortem, which aims to consider all possibilities and risks, so that predictable risks can be mitigated in advance. Post-mortems cover everything from communication to processes to likely team changes. 

Additionally, whenever anything goes wrong, we conduct a post-mortem where we ask: 

• Why did this happen? 
• How did it happen?
• How did we detect it?
• How early or late did we detect it?
• How can we be better at detecting it in future?
• How can we prevent it from happening again in future?

If you commit to this process in a blame-free environment and ask these questions every time, including everyone in the team, then not only does this foster a culture of continuous improvement, but it also creates a culture of psychological safety in which it’s safe to fail and make mistakes.

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How To Create A Culture Of Continuous Improvement In Mobile Engineering Teams appeared first on Novoda.

Continuous integration and delivery (also known as CI/CD) or simply continuous delivery is a software development process determining how code changes within your products are deployed to production – in essence, how productive and proactive your developer teams are. It’s a topic that’s not discussed all that often in mobile – and we want to change that.

While there is extensive information out there on best practices for implementing continuous delivery for web and backend technologies, mobile is often not part of the discussion. So we want to take the time to cover this topic with mobile in mind. Especially since continuous delivery faces a few restrictions and requires adaptation and thinking to apply well to mobile. 

When properly implemented, continuous delivery practices and processes allow your mobile teams to build and deploy products at a much faster rate by improving developer productivity in a number of ways, including:

• Making it quicker to find and identify bugs
• Providing automated and standardised testing
• Supporting a frequent (usually weekly) release cadence

Why continuous delivery matters for scaling organisations

When you have a large mobile team, you’re probably pushing changes dozens of times a day – if not hundreds. As a result, inefficiencies and barriers within your feedback and release cycle can quickly add up to huge amounts of lost time.

One of the main goals of your mobile developer team should be to shorten the feedback cycle as much as possible, making it easier for developers to make changes quickly and making you more responsive as a business.

Why take a continuous approach to releases?

Implementing a weekly or fortnightly release cadence for your mobile app shifts your approach from deadline-driven work to continual iteration. 

Instead of ensuring the latest version of your product is ready to ship on a set release date, you’re pushing regular changes to an internal version of your product, testing, and then rolling out to your user base. As a result, your team are no longer striving hard for everything to be perfect for one set release date – and dealing with all the bureaucracy that comes with release management – they’re working to make improvements to features and UX week after week.

What’s more, having a weekly cut-off point forces dev teams to ensure anything they contribute is ready to go to production, eliminating delays to releases when features aren’t yet ready to push. 

Of course, there will be times you want to get a crucial feature or update released with a concerted and coordinated marketing push – but if you want to move as quickly as your competitors, you can’t operate all the time.

Automation is key for continuous delivery

If you properly implement automation to manage your continuous delivery processes, you’ll avoid many potential points for human error which can arise along the way.

For example, giving machines dedicated access to be able to publish to the store automatically, or auto-release at the press of a button, means you spread responsibility across your engineering team rather than having a single person responsible for overseeing the process. One of the best things about automation is it means there is no single human point of failure – this makes the process more efficient and less prone to errors. 

Ideally, you’ll want every part of your continuous delivery process to be automated. However, in practice, there aren’t currently any off-the-shelf tools that will do everything for you. With some effort though, it’s possible to build the scripts you need to achieve full automation from code to delivery, with no manual input required – we’ve achieved this in some of our teams. 

Of course, automation doesn’t mean everything has to happen with zero human input.  In fact, we’d recommend that you add confirmation times or block points requiring human confirmation if you have a strict release process or protocol. But just because you have a process that requires human involvement doesn’t mean you shouldn’t invest in automation. Automation means you can change the person responsible faster and share responsibility more easily – it’s a lot harder to do this with manual processes.

Choosing the right release cadence

In mobile development, due to necessary steps such as store validation, it’s just not possible to go faster than a certain release cadence. What’s more, users need to download updates to your app to access features and fixes – think about how annoying it would be for your users if they had to update the app every day. 

When it comes to your release cadence, you also need to think about what’s commercially right for your organisation. For example, if you’re a bank and require heavy validation before every release, a weekly release will likely be too much. Or if your app is available in countries where people have restrictive data plans, too many releases will eat into their allowance.

As mobile product engineers, we’ll always have caveats and constraints around continuous delivery, so we need to think about how we adjust and adapt to these in order to shorten feedback cycles, remain responsive and make progress as fast as possible.

Benefits of continuous delivery

One of the key benefits of continuous delivery is that it eases up chaos and removes stress from the developer environment.

Of course, it’s impossible to eliminate all releases outside of your schedule as there will always be situations arising like crashes and bugs which need hotfixes. However, often after a release, it will become apparent that a feature is missing or an element of UX needs tweaking – these aren’t hotfixes, but they are time-sensitive to a certain degree. 

If you have a monthly release schedule, and changes like this can’t wait, you’ll end up having to perform exceptional releases which can disrupt working processes and introduce additional overheads. Whereas, if you have a release every week, you can simply raise a ticket, the team can start working on it and it will be ready for next week’s release.

Additionally, continuous delivery enables faster feedback – if you’re building a feature, the earlier it goes to users, the sooner you’ll know whether it works or not and you can make adjustments quickly. 

Stages of continuous delivery

Alpha stage

In CI/CD, you would generally start your release with an alpha group – typically an internal deployment channel. Every time something gets built within your CI cycle, it gets published here immediately. 

You’ll want to encourage people within your organisation to use this internal version as much as possible – perhaps through incentivisation such as discounts and freebies – so that they can identify bugs needing to be fixed before production. 

Don’t just limit your alpha group to your tech or development teams though, it’s a great way of getting everyone in your company involved in using and testing your app to gain as many different perspectives and explore as many use cases as possible. 

The great thing about alpha environments is that they can be updated 100 times a day without impacting anyone, allowing your internal team to thoroughly test functionality. The sooner new functionality gets used, the sooner bugs will get found – because you’ll never eliminate bugs by just thinking about them harder. 

Beta stage

If, for whatever reason, you have a slower release cadence in your organisation – for example monthly – you may want to have a beta group of users who can use the product before it’s fully validated. 

This way, you can release weekly to the beta group and keep your monthly cadence for your main release. If the app doesn’t pass all checks at the beta stage, it doesn’t get deployed to the next release cycle – you might even decide to skip the next week’s release to the beta group to fix the issue. 

Incremental release

If you’re releasing weekly updates to a large user base, at the incremental release stage you might start by releasing to 2% of your users. Then, if everything seems to be working you would progress to 5%, then 10%, before releasing it to everyone.

The key thing is to start small. That way, if you have a crash or other bug, you only impact a small percentage of your users and you can stop the release at this point to fix it. Releasing in stages like this limits the risks associated with a faster release cadence by getting easy feedback from an initial small group of users. If you release to 100% of users straight away and introduce a crash, the result could be disastrous for your business. 

Assessing continuous delivery success

When you’re assessing the success of your CI/CD process, of course you’ll want to look at user metrics such as error rate, crash rate, session length and any other metrics which are tied to your business KPIs.  

You’ll also want to look at internal metrics such as how many times you need to deviate from your normal processes – for example, to perform hotfixes. If you’re having to perform hotfixes too often, this might tell you that you’re letting too many things fall through the cracks and your validation process isn’t good enough. 

On the other hand, a high number of hotfixes might indicate that people are abusing the process and using it to introduce specific features which aren’t business-critical. In this case, you’d need to look at why people feel they aren’t able to wait and look at whether you’re releasing often enough, or perhaps seeing if there’s a better way of helping your team manage workload and priorities. 

Ultimately, metrics shouldn’t be looked at in isolation. Look at your continuous delivery processes holistically and identify trends over time to see how changes to your continuous delivery process have impacted team efficiency, productivity and developer experience as well as business KPIs relating to the performance of your app.

Summary

A well-implemented continuous delivery system should always give you confidence in your release – and confidence in handling situations when things go wrong.

Continuous delivery is a staple of any business that relies on mobile products because it makes your developer teams more efficient, improves the day-to-day experience of your developers, gives you a much faster feedback cycle and avoids unnecessary overheads as a result of unplanned releases. 

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How Continuous Delivery Improves Mobile Developer Productivity appeared first on Novoda.

His anecdote sparked a broader discussion on the efficiency businesses can gain from using GPT within white-collar workforces, which forms a significant part of the UK economy.

The UK economy is predominantly service-based, with 80% of businesses categorised under the white-collar sector. A recent study by students at the Massachusetts Institute of Technology (MIT) found that ChatGPT led to a 37% increase in productivity* among white-collar workers. Therefore, it’s easy to see how such a boost in productivity could potentially lead to a massive surge in economic growth.

At Novoda, we were intrigued by these findings. As a leading digital product agency, we are always on the lookout for innovative ways to enhance our services and deliver more value to our clients. Following the London CTOs session, we planned a 3-week sprint to understand how GPT could increase productivity for our clients. However, we soon realised that we should also look inward and explore leveraging GPT to enhance our own productivity.

* The MIT study, which involved 444 white-collar workers performing tasks such as marketing, grant writing, data analysis, and human resources, found that the group using ChatGPT completed tasks 37% faster than the group that did not. 

But can AI improve productivity while retaining quality?

Crucially, they found that the quality of work remained consistent. Even more importantly, as the tasks were repeated, the quality of work produced by the ChatGPT group improved significantly faster than that of the other group.

These findings clearly have profound implications for not only the services we offer at Novoda, but for the future of work. 

We are currently developing a suite of AI engineering services with a strong focus on leveraging generative AI. We believe that these tools can revolutionise the way we work in a relatively short space of time, leading to significant efficiency gains and improved outcomes for our clients.

Prompt engineering will be a key aspect of our AI engineering services. This involves the creation of effective prompts that can guide AI models like GPT to generate desired, high-quality outputs. Our AI consultants are fast becoming experts in prompt engineering and are dedicated to harnessing its potential to enhance productivity and efficiency.

But our exploration won’t stop there. We are embarking on an exciting journey to understand how we can use GPT to transform the way we work.

The power of AI is transformational in many ways

For us, leveraging AI isn’t just about improving our services, but also about transforming our internal workflows and processes. We are committed to becoming a leading example of how businesses can harness the power of AI to make it work for their workforce.

In our upcoming blog posts, we will be delving much deeper into this topic. We will share our experiences, challenges, and successes – and quite possible failures! – as we integrate GPT into our workflows. We will also provide insights into our new AI engineering services, how they’re developing and evolving, and how they can benefit businesses across different sectors.

Stay tuned for our follow-up blog posts where we will share plenty more about our journey with generative AI. We are excited about the future and look forward to sharing our insights and discoveries with you.

Want to be the first to get these insights? Sign up for our newsletter

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps and generative AI insights straight to your inbox. 

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

References:

• Financial Times
• MIT Research Paper
• Josh Bersin’s Blog Post

The post Unleashing Productivity: The Power of Generative AI in the White Collar Sector appeared first on Novoda.

As generative AI technology improves and access to tools becomes increasingly democratised, its ability to streamline processes and increase efficiency is proving game-changing for mobile development teams of all sizes.

From automating manual tasks to improving customer experience within mobile products, as a team we’re exploring as many use cases for generative AI as possible to support Novoda and our clients.

So, what are the core use cases we’ve found for AI within Mobile DevOps?

Automatic Documentation

It is incredibly important for mobile devs to document everything they build, but this can be an arduous and time-consuming process with the output varying in quality.

Generative AI tools such as Mintlify, which read code and automatically create explanatory documents, not only automate the documentation process for devs but also ensure the quality of documentation produced.

What’s more, automating processes such as documentation gives your devs more time to work on the more enjoyable and valuable parts of their job, increasing overall efficiency and enabling your mobile teams to deliver greater value. 

Code Review

In the same way that any language has a specific grammar and syntax, code has its own set of language rules too. Because of this, AI tools can be programmed effectively to read through code and pick up the smallest mistakes faster and more accurately than any member of your team. 

Using AI such as Amazon CodeGuru to review code before it passes to a team member not only speeds up the process but catches the tiny mistakes that might otherwise be missed and impact testing later down the line.

User Testing

To effectively test code before deployment, dev teams need to consider all the possible different scenarios a user could face – which is tedious and time-consuming. 

Right now, AI-powered user testing tools are being developed which will be able to generate a large number of the specific tests you need to perform in a fraction of the time – and for a fraction of the cost – that traditional user testing would take. 

For now, we would still recommend supplementing any AI tools with proper user testing, but we think it’s realistic to assume that within a year, user testing could be fully AI-powered.

Ticket Classification & Creation

When working on any mobile development project, robust classification of tickets is essential, making sure that the category and complexity of each ticket are correctly identified before being assigned to the correct individual or team. 

Problems with this process can arise when there are different people across multiple departments, as well as users, creating tickets – particularly if the creator isn’t familiar with the language used by devs.

AI language models can take a history of tickets which have been written in the past, and use this to rewrite tickets which are submitted in layman’s terms into a developer brief which can then be easily categorised and assigned appropriately. This frees up time that’s being spent ping-ponging tickets between different departments or seeking further clarification. 

Knowledge Sharing Between Teams

As your company and mobile development teams scale, onboarding new team members becomes an increasingly difficult challenge – and generative AI can help here too.

By developing a ChatGPT-style interface that learns from team infrastructure and documentation, new team members can easily get answers to common questions like:

• Who within the organisation do I need to speak to regarding this particular problem?
• What piece of code is related to my current challenge?
• How has this problem been resolved in the past?

This means your senior team members waste less time repeatedly answering the same questions or pointing new starters in the right direction. It also allows your teams and departments to work together more effectively – especially in the case of remote and hybrid teams.

Integrating Generative AI Into Products

As well as leveraging generative AI to streamline operations and processes, familiarising your mobile development teams with the available capabilities, they’ll inevitably start thinking about how to integrate AI into the products they’re developing.

For example, food delivery apps might use generative AI to make more personal and specific recommendations to users based on previous ratings, activity or dietary needs without them needing to trawl through the app to find what they’re looking for. 

It’s an exciting time to be working in the Mobile DevOps space, as the capabilities of AI are growing every day. As more and more developer teams embrace AI within their internal processes and product work, if you’re not starting to use AI now in the use cases outlined above, it won’t be long before your organisation is left behind. 

If you want to speak to us about how to leverage AI within your organisation, get in touch here or fill out the form on this page to receive an overview of our generative AI services. 

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps and generative AI insights straight to your inbox. 

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How To Leverage Generative AI in Mobile DevOps appeared first on Novoda.

When you’ve launched a successful mobile product and need to scale quickly, your engineering team will likely grow quickly too.

While it’s not difficult to be aligned and work well together when you have a handful of people in a team, as you hire more people and start separating into different teams and departments with various responsibilities and KPIs, getting all those parts to work cohesively and efficiently becomes more difficult. That’s when a robust mobile team enablement framework is vital.

Why mobile team enablement matters

Mobile team enablement encompasses absolutely everything your business does to improve the efficiency, comfort and experience of your development teams.

Creating an environment that enables your mobile team to operate to the best of their abilities and maximises their skills takes time, continuous attention and sustained effort. While most organisations have good intentions and care about creating a better working environment for their teams to function, often mobile team enablement tasks will be de-prioritised as they feel less tangible and harder to measure than day-to-day performance metrics such as releases, fixes and user feedback.

That’s why, when it comes to measuring the success of your mobile team enablement efforts, instead of looking at the outcomes, you need to look at how efficiently these outcomes are being produced, such as how long it takes to ship a product once it’s built or how often you’re able to release.

So, how does a fast-growing organisation create the most effective and efficient working environment for its mobile development team? Here are some of the most common ways we support our clients.

Enabling automation

When it comes to mobile operations, it’s possible to automate everything including building, validating, pushing to app stores, incrementing and releasing.

If your processes involve a lot of steps to reach a goal – for example, if a release process usually spans multiple days with several actions – then it’s time to put in an automated process. 

While this might mean more effort up front, if it means the same result can be achieved with drastically less time and without interrupting your team, this is going to have a much greater long-term benefit in terms of saving time and resources.

Implementing shared tooling and frameworks

If you have different teams taking the same actions in parallel multiple times, this equals a lot of wasted energy that could be directed to other things. Developing shared tooling and frameworks for multiple teams to access and use is an excellent way to create efficiencies.

To be able to implement shared solutions, you’ll need to review and identify where this is happening across multiple departments – a difficult thing to spot if you’re only measuring output and not efficiency.

Focusing on communication

When you have multiple product teams, all doing independent work, communication across those teams might not be necessary for product tasks – but it is vital for the overall efficiency of your business.

If you have separate verticals within your business, you need horizontal communication.  Without communication between teams about the solutions they’re working on, multiple teams might identify the same need and end up working on very similar things. Whereas if needs and solutions are regularly discussed between teams, one team can be assigned to develop a tool or framework and share it with everyone else.

Streamlining the release process

It’s not uncommon for the release process on mobile to be suboptimal, because there are so many more additional steps when it comes to shipping on mobile compared to the web. This means there’s more that can go wrong, and more places efficiency can be lost. And when you scale, these inefficiencies can add up to create big costs for your business.

There aren’t a lot of existing tools out there to support mobile releases, which means increasing efficiency here usually requires a bit more effort than on web or backend where existing tooling is established. This might mean custom work such as creating release management, custom scripts to automate deployment, etc.

Reducing build time

The bigger your organisation grows, the more impact delays to build time will have on your operations. For example, if there’s a 30-minute build time within a process and you’re building 300 times a month, that’s 150 wasted hours. When we worked with Glovo, we reduced the time taken for full validation from an hour to 15 minutes. Multiplied by hundreds of times, this was a huge cost-saving for them.

It can be difficult to identify where there’s potential to reduce time within your processes because they become so habitual. Your team might not even be aware of the things that slow them down. Recently, I spoke to a team who had a CI environment where the build on CI was failing 50% of the time when running PRs. When it failed, they just ran it again. It had become so habitual for them, they didn’t even think to raise it as an issue. But when we realised what was happening, we could see that the knock-on effect of all that unnecessarily repeated work was enormous – and we could find a solution.

Avoiding context switching

Developers are part creatives and part problem solvers. Usually, they’ll spend a lot of time absorbing a problem and creating mental models before moving forward. This is why avoiding context-switching – jumping from one task to another – is especially important for your mobile teams.

Research has shown that if you’re forced to task-switch, it takes an average of 23 minutes to regain your focus. Therefore, if you’re being forced to do this multiple times a day, it’s easy to see how this can add up and impact productivity.

For example, if you have a mostly manual release process and you want to release weekly, team members will probably have release-related tasks to worry about every day. Not only does this take their focus away from more skilled work, wasting time on tasks that can be automated, but they’re also wasting additional time due to context switching. 

While we all have to multitask sometimes, adding forced multitasking daily will drain your team. They’ll feel more stressed and less productive because they don’t have the environment they need to do their best work.

Ensuring ownership and accountability

Within developer teams, people will often build a piece of code because they need it to accomplish something. After a while, it isn’t needed anymore, nobody pays attention to it, and it falls into disrepair. And when it inevitably needs an update or breaks, it creates problems because it doesn’t have an owner, and nobody knows whose responsibility it is to fix it.

When you build anything, identify who is going to own it and be responsible for maintaining it moving forward. Create a rule that says if you can’t identify that person, it doesn’t get built.

Having a dedicated mobile team enablement function

Undoubtedly the most efficient organisations are those that have a team dedicated to mobile team enablement, ensuring it’s always a priority alongside day-to-day delivery work.

Having a dedicated team allows you to look at mobile enablement from a product mindset, running surveys across your developer base to identify pain points, identifying where it’s necessary to create longer-term efficiencies and coming up with solutions that benefit the organisation as a whole.

Additionally, having an individual responsible for enablement within every team creates a coordinated effort across verticals, ensuring the dedicated mobile enablement team is continually in touch with the developer experience within each team.

This structure of representatives from each team is also a good option when a dedicated team is not yet achievable, as it allows for coordination and focus on enablement across the business. For this approach to work, the representatives from each team need to meet regularly and be empowered to drive enablement efforts within their team.

Setting enablement KPIs

It’s easy to overlook operational elements that are less visible, therefore you need to measure your mobile team enablement efforts in a way that makes them tangible.

Some operational elements are easier than others to surface and measure, for example, CI metrics and delivery are a widely discussed topic and a few solid examples have emerged including DORA metrics or Circle CI’s take on 4 metrics for CI/CD.

For the most part, what you measure will depend on the structure of your organisation, therefore it’s best to start by looking at your team’s processes and feedback from beginning to end and identifying what can be observed and measured. For example, if you notice feature tickets are often ping-ponged between teams, look at how often this happens and ask how you can reduce it.

Involving your team in the process

Your mobile enablement efforts are for your team, so they need to be involved in the process. Top-down management won’t work, you need to talk to your teams and be guided by their needs and insight.

Regularly ask your mobile developers what their average day is like, how they go about specific tasks, and what frustrates them. You’ll likely notice trends in what people struggle with and where people are manually performing habitual tasks which could easily be automated.

While dedicated mobile team enablement might not feel critical when you have eight people, it will certainly feel critical when you have thirty.

No matter the size of your organisation, mobile team enablement must be a key focus if you have any intention of scaling efficiently and profitably. The sooner it becomes embedded into your processes, and you start evaluating and improving your efforts, the easier it will be to maintain efficiency as you grow.

Want more content like this?

Sign up for our newsletter here and get our Mobile DevOps insights straight to your inbox. 

This blog is part of our Mobile First Mastery series, which will form part of our upcoming guide, Mobile First Mastery: The Complete Guide To Mobile DevOps.

Register here for early access to the guide, and get notified as soon as it’s available to download.

Want to talk to us?

If you need support with anything we’ve mentioned in this blog, get in touch and let’s talk.

The post How Mobile Team Enablement Creates Efficiency As You Scale appeared first on Novoda.

By Juan Soriano

The rapid evolution of technology has consistently brought forth new possibilities and opportunities for businesses to grow and thrive and being able to capitalise on these developments is often what marks successful companies from uber-successful ones.

One groundbreaking technology that has captured the world’s attention is Machine Learning (ML) and Artificial Intelligence (AI), the most notable example of which is Open AI’s GPT models and its most publicly recognised use case ChatGPT.

ChatGPT demonstrates the power of AI-driven solutions in an easy-to-use and accessible package meaning that businesses no longer need extensive knowledge or specific domain expertise to tap into the possibilities that large language models afford. This perceived democratisation of AI paves the way for developers who previously lacked the necessary knowledge to create AI-driven solutions and help create business value previously out of their reach.

The days of needing a PhD or years of Machine Learning experience to even access and benefit from such technologies are long gone. Today, companies and organisations, irrespective of their size or industry, can implement these technologies and enjoy the benefits. Ultimately the complexity has been reduced to a point where making use of them is not very dissimilar to consuming REST APIs. This is a game-changer, with easy access to training resources and development tools, companies can now create sophisticated AI solutions to improve their value propositions or use GPT models internally to optimise and automate their business processes.

The newfound accessibility of AI and its applications also means that any company can quickly adapt to changing market needs, lead the competition, and find new ways to provide superior service to their customers. In essence, the widespread availability of AI technology levels the playing field, allowing organisations to innovate and compete effectively in their chosen sector.

The Democratisation of AI: Impact on MLOps and DevOps

The field of Machine Learning Operations (MLOps) has been garnering significant attention in recent years. Previously, incorporating ML into workflows demanded specialised knowledge. Now, with the emergence of new services offered by big tech companies, two major consequences have arisen. On one hand, MLOps has become a discipline more accessible to a wider range of software professionals, as these services simplify the process of integrating ML models into applications and workflows. On the other hand, the popularisation of these services is providing businesses and individuals with a better perspective on how to use AI in their workflows, enabling them to make more informed decisions. This phenomenon is what we refer to as “The Democratisation of AI”.

The MLOps landscape is evolving to embrace a more DevOps-centric approach, leading to an integration of the two methodologies. As a result, organisations now face the challenge of determining how to effectively combine MLOps and DevOps, instead of selecting one over the other. The dilemma stems from the previous perception that MLOps and DevOps were distinct disciplines, each requiring its tools, workflows, and expertise.

Thankfully, incorporating both methodologies into business operations does not require a PhD or extensive knowledge of ML or AI. Engineers can now assume MLOps roles, as third-party APIs often simplify the task of working with familiar REST APIs.

MLOps manages the lifecycle of a machine learning model from development to deployment in a production environment, while DevOps streamlines the process of building, testing, and deploying software. As the boundaries between these methodologies blur, the collaboration between data scientists and software engineers becomes vital. This partnership ensures that data scientists’ models are efficiently and swiftly integrated into the software engineers’ pipelines, ultimately benefiting the organisation as a whole.

In conclusion, the democratisation of AI has made the synergy between MLOps and DevOps more crucial than ever before. Companies no longer need specialised technical knowledge to incorporate ML into their workflows, and engineers can now fulfil the roles of MLOps without that specific knowledge. The convergence of MLOps and DevOps will lead to improved efficiency and collaboration between data scientists and software engineers, ultimately enhancing the overall success of business operations.

AI Models and Tools for Businesses: Streamlining Operations and Enhancing Decision-making Processes

OpenAI and other companies offer a plethora of AI models and tools that businesses can leverage to enhance their operations. These tools include DALL-E, GPT, and Whisper, each with its unique capabilities.

GPTs and other large language models (LLMs) provide conversational AI capabilities that can improve customer service, automate repetitive tasks, and assist in decision-making processes. DALL-E and Stable Diffusion enable the creation of unique artwork and images, opening up new possibilities for marketing and design. Meanwhile, Whisper is a powerful speech-to-text model that can transcribe audio and video content, providing businesses with valuable insights from a variety of data sources.

For developers, Replicate, RunPod and Banana.dev are essential tools that simplify server deployment and infrastructure management. They also facilitate the deployment of AI models selected from HuggingFace. As the largest ML model repository on the internet, HuggingFace offers businesses access to a wide range of pre-trained models without the need for extensive in-house development. By using HuggingFace to choose models and RunPod and Banana.dev for deployment, businesses can streamline their operations and take full advantage of AI capabilities.

Fine-tuning and custom embedding with these technologies allow for more accurate insights and more bespoke support from your AI applications. Incorporating AI models and tools into everyday operations can ultimately help organisations to streamline processes, enhance decision-making, and ultimately stay competitive in the market.

Revolutionising customer experience with GPT, Hugging Face, and Replicate: A hypothetical use case for an online media company

The widespread accessibility of Artificial Intelligence has given businesses an opportunity to apply powerful AI tools to their specific organisational context and offering. Tools that can revolutionise customer experiences and significantly improve team productivity. Let’s explore a hypothetical use case for an online media company that is considering using  AI for content curation, audience targeting, and content creation.

The Objective

The organisation’s primary goal is to:

1. Streamline the content curation process, 
2. Deliver tailored content to the appropriate audience at the right time,
3. Enhance content creation through AI assistance.

To achieve this, they might incorporate various AI tools, such as GPT models, Hugging Face, and Replicate. Making use of those tools is very similar to the way we typically consume REST APIs; understanding how to use the tool is sufficient, not needing to be experts in all the underlying theories behind them. Consequently, the team that initially handled DevOps functions can transition to MLOps without requiring specific deep knowledge of Machine Learning.

GPT models: Automating Customer Support and Content Creation

GPT models are integrated into the media company’s website and social media pages to automate responses to frequently asked questions (FAQs) from users. This reduces the workload of employees, allowing them to focus on other essential tasks. By providing real-time solutions to customer queries, GPT models enhance productivity and facilitate data-driven decision-making.

Additionally, GPT models can be used for content creation, especially when fine-tuned with embeddings. By training the model on a dataset relevant to the media company’s niche, GPT can generate article summaries, draft engaging headlines, or even create short news snippets that cater to the audience’s interests.

Hugging Face: Access to ML Models

The media company leverages Hugging Face to access a wide range of ML models without the need for extensive model development. Hugging Face offers options to deploy models using services like Replicate, which simplifies server deployment and infrastructure. As a result, the organisation can analyse data from various sources, such as social media, website traffic, and customer feedback, to create content that resonates with its audience.

Simplifying Server Deployment

Replicate, Runpod or Banana.dev could then be used to streamline server deployment and infrastructure management. With Runpod or Banana.dev, the team can focus on building applications using models from Hugging Face without struggling with enabling GPUs for their servers, simplifying the deployment and management, and enabling the business to concentrate on delivering high-quality content to the right audience at the right time.

LLMs for Development Teams and GPT Integration

Another practical use case is a development team that incorporates large language models (LLMs), or GPT, to automate tedious tasks, such as writing changelogs, reasoning about code changes, extracting more information from acceptance criteria based on previous tickets in the reporting system, or even as coding assistants or “copilots” while they write software. With GPT integration, the team can also generate human-like descriptions of code changes, making it easier to understand the impact of updates on the overall system. Allowing the team to focus on more complex and creative work.

Conclusion

The democratisation of Artificial Intelligence (AI) has profoundly impacted businesses and developers worldwide and will continue to do so. This transformation has opened up new opportunities and lowered barriers to entry, enabling developers from various backgrounds and skill sets to leverage powerful tools and services. As a result, they can create innovative solutions that were once beyond their reach.

This widespread accessibility has led to a more diverse range of AI-driven applications. In turn, businesses can streamline operations, enhance decision-making processes, and gain a competitive edge in the market. As AI continues to evolve and expand, we can anticipate further breakthroughs and advancements in the coming years.

The ongoing development of AI will foster even greater innovation, empowering businesses and developers to fully harness this game-changing technology. This has the potential to contribute to a more connected and intelligent world, where systems and processes work in harmony to achieve optimal results. There’s no doubt, the democratisation of AI has set the stage for something incredibly exciting, and we have yet to witness its full potential.

Interested in GPT, LLMs and what AI can do for your business? Join the conversation on Linkedin and tell us about what you’re up to. Or, if you want to chat directly drop me an email at juanky@novoda.com.

Disclaimer: We used a custom tool to support the research that made this article possible. More info on that coming soon!

The post The Democratisation of Artificial Intelligence with ChatGPT appeared first on Novoda.