React Native: Building Mobile Products (MVP)

React Native for Building Great Cross Platform Products

 

W

hat is React Native?

 

React Native is a Javascript framework that was built by Facebook and re-licensed for use by third parties in 2017. It allows developers to create apps for both iOS and Android web stores using a single codebase and a single programming language. With React Native, developers have the ability to write one React code that compiles to native applications on both iOS and Android, rather than having to construct parallel codebases in multiple programming languages.

What are the Benefits to React Native Development?

Time and Cost Savings

Prior to the release of React Native a company was required to either find engineers that had experience with both iOS Android programming languages, or to hire separate developers to work on each platform individually.

 

In contrast, React Native allows you to have a single team of developers experienced in one primary programming language who can work on both platforms simultaneously in one single codebase. Depending on the functionalities of your app, at least 90% of the codebase can be shared across both platforms and since all the versions of your software are written in mostly the same code, updating and adding features becomes much faster and easier.

 

Though there are some differences between iOS and Android that need to be accounted for when using React Native, the time and cost savings of having one codebase are a huge benefit.

Open Source Libraries and the React Community

When using React Native you are taking advantage of the wider open source community and ecosystem that exists around React and Javascript.; A tremendous number of libraries exist that can be used for common mobile application features, meaning you won’t have to spend so much time writing code to add extra features to your app- it’s likely that that functionality has already been built and shared with the community.

 

Additionally, the number of engineers employed by Facebook, as well as a big open source community means a continued improvement in the platform over time.

Shared Web App Code

If your mobile app also calls for a web browser/desktop application, React Native can provide some reuse and sharing of code between those platforms. Because React Native is just React and JavaScript code, an experienced development team could get a head start on a web application.

 

Additionally, Electrode Native is an open source tool that will allow you to migrate existing React apps to React Native.

Who Uses React Native?

Because it’s such a reliable and powerful cross platform development tool, React Native is being used by many top companies to develop their mobile apps.

 

Facebook uses React Native for their social media site as well as for Facebook ads manager and Facebook analytics. Instagram was able to share around 85% of code between its Android and iOS apps by using React Native, allowing their team to deliver the app much more quickly than would have been possible using a Native solution. And Tesla’s app, an integral part of its user interface that enables users to remotely monitor and control their Tesla car or Powerwall from their iPhone or Android, was developed using React Native.

 

With React Native, developing and supporting apps for both iOS and Android is less effort it once was. From the ability to develop apps across platforms using one codebase to the benefits of utilizing the open source community, React Native provides an optimal framework for developing awesome cross platform products.

 

The right eCommerce solution

Which is the right eCommerce solution for my business?

 

Finding the right Partner for your E-commerce Business The new trend is to build a Marketplace using SaaS, and extend functionality with a plugins development.

Ecommerce in numbers

In 2019, retail e-commerce marketplace sales worldwide amounted to US$3.46 trillion, and e-retail revenues are projected to grow to a dizzying US$6.54 trillion in 2022 and will continue to drive the future of e-commerce forward. B2B (business-to-business) marketplace sales transactions are set to boom and will account for an estimated 30% of all worldwide online sales by 2024.

 

Combined, both B2B and B2C (business-to-consumer) marketplaces are expected to grow web sales worldwide to an estimated $7.1 trillion while peer-to-peer marketplaces including eBay and Airbnb will reach $240 billion in combined sales by 2024. However, the area with the fastest-growing global marketplaces will be in B2B.

 

Currently, only a small percentage of the annual worth of online B2B sales are made via marketplaces however, businesses are starting to realize the benefits of trading with partners via marketplace platforms. In this regard, as more businesses trade online, global sales will continue to grow which will include a wide range of industries and vertical markets.

Should I build around a SaaS?

SaaS, or otherwise known as Software-as-a-Service, is a software distribution model in which a service provider hosts applications via the internet for customers. SaaS falls under the form of cloud computing. Usage is subscription-based charging businesses either monthly, bi-annually, or annually to use the service. These online subscriptions come with their respective technical support and periodic upgrades, SaaS companies deliver usability without bogging down customers with details. You access content through a web browser interface and your content is hosted in either a cloud or shared server. There are a variety of businesses that provide this service for marketplace development such as Arcadier, CS-Cart, Dokan, and Sharetribe.

How can I customize the SaaS?

 

A plugin is a software add-on that is installed on a program, enhancing its capabilities. It is a form of integration of a separate application to the main platform, either by the platform owners themselves or by other third parties. For instance, you like to add an email marketing tool to your eCommerce business and you are using Shopify or Woocommerce to build your eCommerce, you can utilize the Quickbooks plugin that seamlessly works with your Shopify Store or your book-keeping or LiveChat plugin to create your customer support chat capability. A number of online store platforms offer a plugin that can turn your single merchant shopping cart into a multi-vendor shopping cart experience. Most of these were developed by third-party developers using their respective APIs and Webhooks, and these developers charge a fee for its use.

What option best suits my business model? 

This is the first question that goes through the minds of people who are trying to start their first eCommerce marketplace. Go with a SaaS provider such as Arcadier, CS-Cart, Dokan or Sharetribe, or via a plugin alternative that augments your platform to become a marketplace for online store platforms such as Shopify, Magento, or Woocommerce? It is key to understand the comparisons of their respective software delivery models.

 

The answer to this question will be dependent on three factors: User preference, costs involved, and feasibility associated with plugin systems.

 

Using standalone plugins is a great option, but it does have its limitations. For example, the plugin builder will still have to work within the confines of the eCommerce platform to change a user experience that is not natural to the main use case of the eCommerce platform. Dedicated Marketplace SaaS products have been built for the purpose of the marketplace experience in mind, so the user experience is designed from the ground up for a multi-vendor experience.

Build a team for your eCommerce business

 

Marketplace SaaS solutions are not significantly more expensive than what most plugin developers are charging for the download and use of their plugin. However, the risk of failure that the augmentation using a plug-in to a platform not developed to be a marketplace makes a dedicated marketplace SaaS solution a safer bet. The features provided by SaaS also enable businesses to efficiently create their own marketplace because a lot of the heavy lifting is already done for you, plug-and-play extensions, themes for your front-end, site optimization, dedicated support, analytics, and bug fixes are such examples.

 

The SaaS option is built-for-purpose but that does not necessarily mean the plugin alternative option should be ruled out, it is still a good option for building a marketplace, however, there lies the problem that all the plugin components on your platform of choice may not necessarily be able to properly shake hands with each other especially on more mature platforms.

Build fast and iterate 

 

SaaS vs Open-Source eCommerce solutions has their similarities, benefits, differences, and challenges. Both have their own niche market and success stories. A lot of people have built excellent marketplaces around both solutions.

 

The main factors to consider when choosing an eCommerce solution are budget, technical proficiency, and knowledge, and how serious are your plans to scale your business.

 

The more niche or more mature your marketplace is, the more customization will require.

Managing Remote Agile Teams: 7 Strategies

How can teams maintain effective communication when they are separated by location and time zones?

Principles like “software over documentation,” “responding to change over following a plan” and “quality interactions over tools” take on whole new meaning when managing remote teams.

Why Agile prioritizes communication

Agile methodology recognizes face-to-face communication as the most efficient and effective means to share ideas. The benefits of sketching on cards or a whiteboard are two-fold — improving the level of understanding and reducing the time it takes to deliver the core message.

 

Most credit the adoption of Agile thinking as the primary driver to create more open, collaborative office spaces no longer punctuated by rows of cubes and team members appearing every so often. Open spaces led to more drive-by conversations between team members and more feedback collected throughout the development process naturally.

 

Unlike smaller teams who do have the option to co-locate, enterprises managing remote teams often don’t have the luxury of sharing the same physical space each day.

 

Team structure options:

  • The stakeholders and the development team share the same physical space.
  • The business is physically separated from the development team with the stakeholders in one office and the development team in another, often offshore or nearshore.
  • The stakeholders and the development team are separated by distance and time. Additionally, the development team itself is distributed across cities or countries.

 

Distributed teams must actively work to avoid falling into communication traps that shift the project process away from Agile development to a decidedly waterfall one. But, the world is a small place even for distributed teams — made smaller by the available communication platforms from Microsoft Teams, Trello, Slack, Jira, or Skype. Promoting the same close communication expectations is the key to supporting the Agile process on distributed teams.

7 Communication strategies for managing remote agile teams

Foster a culture of continuous integration while builds are regularly reviewed and planned.

 

Creating a culture where continuous integration is the norm is especially valuable on projects with extended timelines or while managing remote teams. In this structure, it’s easy to opt for dividing work for teams along technical boundaries. These technical boundaries may be divided by frontend/backend work or even database and services layer/frontend. Team bandwidth or security might drive the boundaries. Additionally, some businesses may be cautious of releasing intellectual property into a cloud-based platform like GitHub.

 

This usually results in the maintenance of two source code repositories with a commitment to merge them later. Resist this. The technical debt that results from this fractured code is more time-consuming to overcome than if the teams had increased the communication necessary to manage just one code repository in the first place. Overcoming any communication barriers to work on the same code base is worth it in every way.

 

The team manages successfully at leading remote teams and achieving this culture will begin to see evidence manifest in the daily communication and behavior of team members:

  • All members actively strive not to break the build.
  • They will provide visibility to broken builds.
  • All will react with a sense of urgency to adjust build issues.
Commit to frequent builds, so you don’t prioritize upholding the plan over agility.

 

It’s easy to produce a giant spec instead of communicating daily with the remote development team or let distance become a reason to stay the course and avoid developing the solution when challenges or barriers arise.

 

Building on a weekly schedule is good, daily is even better. Hold your team accountable to submit a change set to the source code control each time. Then, take advantage of your compiler as a stand-in team member to ensure your source code has reached or exceeded quality expectations. Adding smoke tests can propel this even further.

 

Welcome the human process of developing custom software.

 

Most people assume custom software development is a purely technical process. While it’s true the process is highly technical requiring years of training and experience to run successfully, software development is a human process first and relies on trust between individuals.

 

Promote knowledge sharing on every team. This is less about documenting processes in a Wiki and more about nurturing this behavior in daily stand-ups or any time team members give updates.

 

Support your team to share beyond what concerns to that day’s work. If a team member expects something they are working on may impact another role the next day, call that out. Once team members master the habit of sharing important, forward-looking insights, that’s when true knowledge sharing has been reached.

 

Foster communication between UX designers and business analysts to accelerate throughput by a factor of two.

 

Fostering close collaboration between designers and business analysts, urging extra attention to the graphical interface. This mean additional time is spent creating visual artifacts for the technical team to complement related user stories. The prize? Less questions related to aesthetics and less iterations created as a result of the mismatched expectations.

 

Consider even non-functional requirements.

 

For teams who are co-located, it’s easy to address questions around performance and scalability as they arise. Imagining and documenting requirements with the appropriate level of detail serves as the link between the business and technical teams.

 

For distributed teams, understanding non-functional requirement feature plays an even bigger role. Without specific directions documented for the technical team, it might result in the production of an architecture that makes assumptions about the non-functional requirements resulting in increased rework, and time waste later.

 

Managing a distributed team may mean documenting more.

 

While all Agile teams strive to write “just enough” requirements, managing a distributed team means accepting “just enough” may still mean documenting more than would be created for a co-located team.

 

Distributed team members can’t quickly sketch on a whiteboard to work through a complex concept. Rather than leaving your development and testing teams left guessing on the nuances that would otherwise be delivered verbally, document them and “give the answers” before the test.

 

By augmenting user stories with test or acceptance criteria you can set the technical team up for success without drastically expanding the narrative.

 

Choose a set of communication tools for your team that allows for the usual escalation of communication needs.

 

When teams are co-located, the level of communication needed escalates naturally. It might begin with co-workers speaking one-to-one in the breakroom. If clarifying details are needed, additional subject matter experts may be pulled into the conversation. Then, the conversation shifts from many-to-one or many-to-many, depending on the context. Maintaining this escalation process is essential to create outlets for quick answers or more in-depth conversations despite any distance that may exist between team members.

 

Types of Communication

  • Chat 1–1
  • Chat many-to-1
  • Voice call
  • Visual call
  • Screen share
  • Collaborative Board

 

The ability to ask quick clarifying questions is inherent in how most teams work. In the past, this could be accomplished with face-to-face drive-bys in the office. But, increasingly even teams who are co-located are relying on instant messenger or video calls to accomplish this.

 

Instant messaging is a powerful tool for managing remote teams that include non-native English speakers. The tool allows them the space to craft replies without the pressure of discussing directly (and quickly) with a native English speaker. That said, tools like Microsoft Teams or Slack allow for escalation from messaging to voice and video calls and even screen sharing if needed.

 

While the importance of instant messaging cannot be over-emphasized for distributed teams, watching body language and physical reactions to comments or questions are also critically important, especially when discussing challenges or questions to estimate feasibility or understanding.

What does it take to win with distributed Agile software teams?

No digital tool or communication strategy can replace the determination of the leaders needed to achieve the Team highest potential.

 

Co-Innovate with us.

 

Towa SoftwareBoosting Digital Transformation with best ROI – Remote Tech Teams. 300 strong.

 

Tips for distributed agile teams

“Agile development isn’t any longer considered to work for collocated teams only. Also, teams, projects, and organizations that are distributed are asked to focus on delivering value. Yet, with Agile’s emphasis on -among other things- face-to-face communication, this seems like a contradiction. So the question arises, how to adhere to the Agile principles when applying them in a distributed environment.”

H

ere you will learn about the key success factors for distributed teams. Readers will understand that also distributed teams can benefit from a value system and from principles that are beneficial for small teams. In fact, the two trends – distribution in terms of globalization and Agility – can even complement each other.

Many organizations find themselves faced with the challenge of making distributed agile work. Mergers and market consolidation, geographic expansion, and offshoring have made multi-site development the norm rather than the exception. Companies with sites in competitive labor markets can find distributed team members as an alternative when they can’t recruit locally.

Agile can work in a distributed environment, but it requires work; more effort than you’d expect if you’ve never done it before. Here are eight hacks that can make it easier.

Why distributing the team might make sense

You might not be able to get all the people with the right skills in the same location, but the world is filled with talented, motivated people, and being open to working in a distributed way opens up your options.

Besides, today’s technical professionals have more choices about where they live and work. They may like where they live and not want to move. In short, the people you need may not all live in the same location.

Local culture matters. If you’re developing a product that needs to appeal to customers in different countries around the world, you’ll need people who know the local culture and language. There are also political or security reasons for distributing development—from tax advantages for doing work in certain countries, to restrictions on data crossing country borders, to the need for people on the team with particular security clearances.

As you can see, there are a lot of reasons a business would choose to have a distributed team, and whether we like it or not, the number of remote workers is only going to grow. With that in mind, here are eight simple distributed-agile hacks that can set the right tone for a successful remote team.

1. Recruit motivated individuals

It is possible to make distributed development work; open-source projects do it all the time. They have a couple of advantages that other initiatives often lack.

  1. Their team members are often exceptionally self-motivated, at least if they are committers.
  2. They often don’t have to deal with stakeholders or requirements, because they are often building a project for themselves, so they know the problem domain very well.

In more normal situations, having highly motivated team members is really important, and the remote team members are going to have to be exceptionally self-motivated. that’s because they are going to have to work harder to communicate, stay engaged, and stay focused and productive. They won’t have the informal network of co-located team members to fall back on.

The co-located team members are going to have to work harder, too. They are going to have to make a special effort to engage their remote team members.

2. Create self-organizing teams

The worst thing to do when forming any team is to assign people to work on it; it kills motivation and destroys initiative. Since distributed work is even harder than co-located work—because it requires even greater motivation—the distributed team needs to be strong, with members who are committed to the mission, to the way of working, and to each other. That level of commitment doesn’t happen by accident.

Letting people choose to be part of the team—to work with one another—is an important first step. They must want to work in an agile way, and they must want to work with one another. Let people volunteer to join the effort, and then bring them together to establish their norms and working agreements.

3. Co-locate, at the start, to let teams form, storm, and norm

Forming a team usually takes at least a couple of sprints, sometimes longer. You will make your life, and theirs, much harder if you don’t invest in helping them develop into a high-performing team. It takes time and experience working together as a team to develop the trust, commitment, and mutual accountability that they need to perform well together and to be transparent about the state of the work.

Artificial team-building exercises do little to help teams go through the forming-storming-norming-performing process. Bringing teams together for a couple of sprints is really the best way to develop the working relationships that are essential to future performance.

4. If the effort is large, have co-located teams at each site

Let’s say that an organization has sites in multiple locations, as well as multiple teams, each with team members at every location. In this situation, you’re going to end up maximizing the amount of extra work for everyone.

Instead, you should try to form co-located teams at each location and let them figure out how to share the work among themselves, extending Scrum with a scaled agile approach such as SAFe or Nexus. In this approach, multiple teams are working on the same product.

With a scaled Scrum approach such as Nexus, you help multiple Scrum teams simplify cross-team collaboration by resolving and preventing cross-team conflicts and ensuring that they deliver an integrated product increment with every sprint.

Regardless of which framework you use, you should make sure each team has a Scrum Master. Masters will not only help their own team perform better, but they will also help everyone else who needs to collaborate with that team.

5. Co-locate development teams with their product owner

This sounds obvious, but I’ve encountered plenty of strange situations where this is not the case. I’ve seen companies with the development team in one location and the product owner in another. This really hurts collaboration and communication, so don’t do it. Find a different team or a different product owner, move the product owner to the same time zone, or empower a local delegate for the remote product owner if the product owner is co-located with another team.

6. Invest in collaboration, but invest first in teams

Collaboration technology really helps teams be more effective—distributed source-code management, continuous integration, continuous delivery tools, wikis, video conferencing, and chat platforms such as Slack all help high-performance distributed teams be more effective. But they can’t make a low-performance team into a high-performance team. Lack of these tools can decrease the effectiveness of even a high-performance team, however.

7. Share the pain of time-zone separation

When a team has members at multiple sites, they demonstrate mutual respect by sharing the burden of working odd hours. Some teams make the mistake of having the team with the most members set the workday rules, but this sends the message to teams at other sites that their contributions are not valued as much. Making everyone share the burden is not only fairer, but it also creates a sense of empathy with what other team members have to endure.

8. Minimize wait times

Different time zones increase wait times. When a person at one site must wait for a team member at another to start the day to resolve a blocking issue, the rest of the day is lost. These delays add up. The daily stand-up can help uncover these problems, but the team will have to look not only at today’s work but potentially at tomorrow’s as well to know what issues might block them. It won’t be perfect, however, and some additional delay is inevitable.

Flattening roles and refining the product backlog to spot potential conflicts earlier can help. With dependencies reduced, and with teams having members who potentially can work on any product backlog item, blocking issues and slow hand-offs will be less frequent. But the issues can’t be eliminated.

No shortcuts to great teams

Distributed agile development is harder than co-located agile development. Time zone differences make collaboration more challenging. However, teams with members working at the same site but in different buildings will find collaboration more challenging as well. Being agile requires transparency, which doesn’t exist unless team members trust one another, and developing trust requires time spent working together.

Organizations make a big mistake when they think of teams as simply a group of individuals. A great team is far more than the sum of its members’ contributions. Being part of a great team is motivating—it challenges people to do their best, and it rewards them with a sense of shared accomplishment that individual accomplishment cannot. Great teams take time and investment to build, and they are worth preserving when they come together.

“When distributing work, for whatever reason, focus on forming great teams at the beginning. These teams can be formed with distributed individuals if they are motivated and supported, but it does take more practice on everyone’s part.”

Risk Management Banking Industry Trends

Fintechs and nonbanks now have a substantial influence in the banking industry. They are highly agile, innovative, and aim at exceeding the demands of modern customers in banking services and experiences. Established retail banks need to compete and often play catch-up. Still, they acknowledge the need to change, and change fast.