Public speaking is not quite the easiest thing to do for most people. It is called “Glossophobia” and it is believed to affect up to 75% of the population, so yes, you are definitely not alone. Maybe you are an introvert and being the center of attention isn’t your cup of tea. Or you have little experience with speeches and you are not sure if the message you are trying to convey will get to your audience. But even if you are an extrovert with a bunch of presentation skills, there are still some tips and tricks that could help you improve your public speaking. The 5 SHOWS The main aspect of delivering a powerful speech is the quality of the actual content of your presentation. Does it matter to the audience? Is it engaging enough? Is the audience stimulated to continue learning about the topic? A presentation is ultimately a performance, a SHOW and the public is the star of it. To help you deliver a captivating, clear, well-defined message, let me share with you some simple tactics to make it a success! 1.) The public is the star of the SHOW One way of engaging your listeners is to make them feel that they are important. The key is to talk to the audience in a personal, 1 to 1 manner, and not talk AT them. By shifting the focus from the message of the presentation to the recipients you will shape their perception on the topic itself. Don’t deliver a lecture you couldn’t sit through. Think about what questions are in your mind when you are the outlooker. Things like “How could this change my life?” ,” Is this even helpful?”, “Will this be a waste of time?”, ” Does this apply to me?”. By answering these questions early on in the presentation you can help them understand the VALUE their attendance brings in return of their invested time. And this brings us to the next topic: Adding value. Tip: You can raise the impact by using the word “you” Help them understand how the information you are presenting will affect them personally. 2.) SHOW them the value Humans are passionate about themselves. It’s a fact. If you don’t focus on them, their attention will slowly drift away. They will think about the bills they have to pay, the food delivery options, the latest game released and so on. The human attention span has decreased tremendously in the past decades. The most recent studies tell us that the average human has an attention span of just 8.25 seconds . That’s why it is crucial that you present the value straight away and get to the point. Let’s take e-shops as an example. What do you see on the landing page? The best deals, new products, you even have the option of “add to cart” before you go to the actual shop section. What about the “about us” page? It’s on the far end of the navigation bar or in the footer somewhere. Why? Because the user is there to shop, not read about how the company was founded. By engaging the individual, you will find yourself speaking to a motivated listener who is more likely to follow suggested action-items as a result of attending your talk. Tip: Go straight to the value Keep the information relevant and give pointers on where they can learn more about it, if they care to do some extra research afterwards. 3.) Promises should SHOW up to the event Before attending your event the audience should know what the topics and the gains are. You have to fulfill your promises and touch every subject priorly mentioned. Some people have the tendency to go with the flow and drift into other subjects that might be more or less related to the main subject. Remember that the allocated time is limited and keep to the topics that bring the most value. Short and sweet. Tip: Keep it simple Don’t overwhelm the public with too much information, after a certain point they will enter the cognitive overdrive and no matter how brilliant your ideas, there’s simply no more room for it. 4.) SHOW off through storytelling Story time has a huge potential to aid in your delivery. Some of the benefits of incorporating stories into the speech are: increasing the personal connection with the people attending, helping them visualize the message, and making your message more relatable. It can also act like a connector and bring all the ideas together, putting the information into context. When using stories or anecdotes to convey the message, make sure that the stories are not too lengthy and they are well-structured enough to capture their attention. Presentations should be first of all, understandable, so talk in their language. Memorable. Don’t be afraid to introduce them to out of the ordinary ideas. And emotional, because we should not forget that we are all humans with common perks and problems. Tip: Make it personal. Imagine that you are talking to an individual and not to a mass of people. Capture the persona of your audience and understand the knowledge level of your audience. Just like in marketing: Who is your audience? What do they need? How can you help them? How would they receive the message easier? Maybe the persona relates to emotional stories, and you can use emotional stories to touch their heart-strings. Or you can go with humor, to release tension, to connect with them and to potentially make it memorable. When you are pitching for a product, for example, the product is the solution to a problem they can personally relate to. 5.) Don’t rely on your slide-SHOW The slide-show is not for you. Don’t read off your slides, they’re there just as a short, easy-to-read synthesis for the audience. Changing-up the way you deliver the information every now and then can help the dynamics of your presentation. Images or videos can be a great asset in helping the

If you have ever been in contact with a development team in the past 20 years or so, chances are that you’ve heard about User Stories quite a lot. Agile teams all over the world have embraced this concept, especially when using the Scrum framework. Developers, testers and designers are all relying on well written User Stories as snippets of requirements and documentation setting clear expectations and defining the shortest road to success. Not just their own, individual, professional success, but the success of the products they’re working on. In this article we will look at what User Stories are and how we can work with them so that they enable us to convert our backlog into an amazing product. Of course, this relies on having an effective, efficient and creative development team, working as a well greased backlog consuming value delivery system. The purpose of this article is by no means to clarify all concepts and the entire terminology associated with Scrum & Agile, but rather focus on this particular area: writing User Stories. User Stories are probably the most important artefacts of the Agile methodology and the Scrum framework, as any team that applies even some elements of Scrum instead of the full framework (also known as “Scrum But” – eg. We’re doing Scrum, but we’re not doing that retrospective thing… ) are definitely using User Stories to define their requirements. The explanation for this is quite simple: it will be natural for any team to fight change when it comes to process and way of doing things, but when it comes to adding more clarity and simplicity to the requirements, anyone would go “where do I sign up”. In my 14+ years of experience with Agile & Scrum in various teams and organisations, introducing User Stories was always the easiest step towards the Agile mindset we were trying to achieve. What is actually a User Story? As I mentioned before, User Stories are snippets of requirements / specifications, in the context of Agile teams using Scrum (or other) framework. It is just a snippet of the requirements because it focuses on one thing only: the outcome a specific user is trying to achieve when using a specific feature of our application. The obvious question would be then: how are User Stories different from normal requirements? The answer to this question will become obvious if we look at how requirements are usually written. Frequently, any product requirements document gets into tons of details about many areas, explaining what the user will have to do in order to achieve a certain desirable outcome. So any feature can be summarised as: As a <User> I want to do <Action> so that <Outcome>. In this example the User can be a so-called Persona, a role, a user type or any other name you might use in order to be able to categorise your users. The actual format could be widely different, but the gist of it is the same. The persons writing the requirements are perfectly understanding their users, and they will define exactly what they want and how their users will achieve that. There is a tiny little problem with that approach: In 25 years of software development I haven’t come across a single person able to articulate that and continue to believe that all the way to the product’s completion. No matter how smart we are, how well we believe we understand a specific domain and how much our guts are telling us that “we got it, we know our users”, reality will quickly kick us in the face and show us that real users might have different expectations. Therefore, focusing just on the outcome, a perfectly good and valid approach many years ago is no longer valid today (and it hasn’t been valid for many years already). However, there is nothing “inherently” wrong with the above. If we’re able to define any requirement at least in this shape and form, chances are that our product will get a shot at being successful. This way of articulating requirements is still allowing us to build a product that will get at least some of the features right. The entire IT industry has been releasing products using a similar approach for ages, so what can go wrong. Well, many things can go wrong. The world evolved and our customers evolved with it. And their expectations. They expect better products than what you offered yesterday and what your competitors offer. They expect new features to be released often and to wow them on every occasion you have. They expect you to innovate and be ahead of the game. How can you achieve that? What has anything to do with User Stories? Well, it has! A lot! To clarify why, ask yourself this: what is more important? The problem, or the solution? At this point, I really hope your answer was about the problem. Understanding the problem is key in creating products that customers love. The solution has to change as the problem evolves, because the other way around will never happen. If the users are not satisfied with the solution, they will leave, but not because the solution is not the most amazing ever, but because you ignored them. You ignored their needs. You ignored their problem. Therefore, what’s the point of writing requirements focused on the solution, when you should be writing them around the actual problem? So how could we improve the way we write those requirements? We just need to do one thing. Replace the action we would expect our users to do with the reason why they would actually do it. As a <User> I want <Outcome> so that <Reason/Purpose>. Hard to see the difference? Let’s fix that with a basic example. Let’s say your application will require some sort of authentication to allow users to use the app. In most traditional requirements, you would see something like: As an anonymous (not authenticated) user I would like to be able to enter

On the 28th of July, 2022, Nordlogic became part of AROBS Group. This acquisition represents an important milestone for our company, as we are joining forces with a market leader in the IT industry who is also based and founded in Cluj. When choosing a partner that will help us grow, AROBS was a natural choice, considering our strong relationship both on a personal and professional level. AROBS is the largest tech company listed on the Bucharest Stock Exchange. The company offers software solutions and services for businesses in several industries. They currently have over 70 partners in Software Services and over 10.000 customers in Software Products. AROBS has 11 locations in Romania and eight abroad. Our shared goal is to strengthen our presence both at a local and international level and to further expand our team, skills, and client portfolio. We are confident that this acquisition will help our company grow at an accelerated pace. “We are thrilled that a new Romanian entrepreneurial company, also based in Cluj, has decided to join AROBS and contribute to our long-term goal of making the group the largest Cluj-founded international player in the IT industry,” stated Voicu Oprean, founder and CEO of AROBS. AROBS will use a portion of the capital that was attracted by BVB investors during its private placement for shares in October 2021 as well as bank financing to complete the transaction. The acquisition of Nordlogic represents the third transaction made by AROBS since they were listed on the Bucharest Stock Exchange. They also acquired Berg Software Timisoara at the end of 2021 and Enea Software Development Services in April 2022. The management of Nordlogic remains the same, and it will be ensured by Andrei Olariu (CEO), Ovidiu Codreanu (COO), and Ciprian Sorlea (CTO). The future is promising, and we look forward to all the great projects and opportunities this acquisition will bring. We are stronger and more competitive than ever before, and we will continue to maintain the top quality of our products and services. Article by Nordlogic

This article will try to debate the controversial dilemma of hard and soft skills in the Software Testing field. I’m sure that in any field/industry we may perform we encountered this dilemma at least once. So, which one do we think weighs more: hard or soft skills? Software Testing – Basics First of all, let’s take a short journey through the world of Software Testing and its categories. Software Testing, quoting IBM’s definition: “Software testing is the process of evaluating and verifying that a software product or application does what it is supposed to do. The benefits of testing include preventing bugs, reducing development costs, and improving performance.” A very straightforward and comprehensive description, which I agree with. Now that we know what software testing is, we also need to understand what lies under this “wide” umbrella and also the main components and capabilities that need to be covered by software testers. Not all types of software testing are performed by testers and this topic will be covered in the following sections. At the macro-level we have two main categories: Black Box Testing – is a software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure and implementation details. Black Box Testing mainly focuses on the input and output of software applications and it is entirely based on software requirements and specifications. White Box Testing – is a software testing technique in which internal structure, design, and coding of software are tested to verify the flow of input-output and to improve the design and security. In white-box testing, code is visible to testers so it is also called Glass Box testing. Another important thing that we need to know about white-box testing is that it is mostly performed by Software Engineers (aka developers or programmers). Since White Box Testing is mostly performed by developers, let’s stick to the Black Box testing. And here we also have two main categories: Functional testing or “what does the system do?” – verifies that each **function **of the software application operates in conformance with the requirement specification. This involves checking user interface, APIs, database, security, client/server applications, etc; Non-functional testing or “how the system works?” – verifies the non-functional metrics of an application/system such as performance, usability, reliability. Both main categories can be performed in two ways: manually and automatically. How does manual testing work? Manual testing represents the tester’s interaction with the application as an end-user, comparing the expected and the actual behavior and whether the behavior meets the requirements. Manual testing can cover all functional and non-functional types of testing. How does automated testing work? In automated testing, testers write code/test scripts to automate test execution. Testers use appropriate automation tools to develop test scripts and validate the software. Automated testing can cover only partially the functional and even less the non-functional part. The most common testing types covered by automated testing are UI functional testing, Performance, Integration, and API testing. Which team are you – hard or soft? For Automated testing, programming skills are necessary because you will have to write a script in order to “simulate” interaction with the system. Here are a few examples of “nice to have” skills when we talk about automated testing: SQL HTML + CSS (elements & selectors) API & HTTP requests Working with command-line terminals Programming languages (Java, JavaScript, C#, Python… etc) DevOps Agile methodology In addition to this, the skills mentioned above are not a “must” for manual testing, but always a “nice to have” mostly at a basic level. Although we know the importance of technical skills, surprisingly they represent only 50% of the “whole package” that makes a “good tester”. To complete the other 50%, well, we just need to be a little human and show a bit of these soft skills: Empathy (End User and Team) Patience Team player & very good communication skills Adaptability Eagerness to learn Critical & analytical thinking An explorer spirit We may think that in order to fully understand how a software application/system works or how to test it, we need to learn “how to code”. But most of the time we do not have access to the code and perform “black box” testing (no access to the code/implementation) so programming skills will not be very helpful. Look at the bigger picture Circling back to the key question, based on what we learned so far, not all types of testing require a set of “hard technical” skills, at least not the non-functional ones which check how the system works. So in order to verify if a system is performing well or not, if it’s user-friendly, there is no need to write a script or to read one. It only needs a very important soft skill which is “care” or end-user empathy. Didn’t expect that, right? In these difficult times when every “offline” business is forced to move “online”, when our face-to-face interactions are increasingly rare, we need to pay attention to details even more. Let’s not forget about people with special needs that have visual, hearing, mobility, or cognitive impairments who are “forced” to use systems and apps that are not suited for their needs. These needs are usually covered in accessibility testing. This is only a small part of the non-functional testing universe. Another important part is the User Experience, especially if you have an E-commerce application. The user journey needs to be very smooth, fluid, compatible with multiple devices, browsers, and at the same time, very intuitive even for elders, otherwise, your potential customer can be lost in just a second. Considering the context and these new perspectives, have you ever tried to actually see the bigger picture? We are not just stakeholders, POs, PMs, developers, or testers on a project. We are facilitators for those on the other side of the screen. And yes, it is also our job to think and work with empathy, even if this is not written down in our job description. Is writing code enough to be good? To sum up a bit, labeling a tester

Any software development estimate is based on a combination of effort, time, and costs associated with the project scope. The crux is finding a balance between the client’s or manager’s requirements and the team’s ability to address these requirements in estimating a proposed project. The two main parameters that stand at the center of project estimation are the time needed for completion and the costs of development work. Based on that, several techniques for software development estimation could be used, including analogy estimation, expert estimates, bottom-up estimates, three-point estimates, parametric estimates and use case points. Depending on the project stage, different estimation techniques could be employed. For example, analogy estimation and estimates by experienced architects suit best when assessing the feasibility of the project, and at the early project initiation stages. Similarly, bottom-up task-level estimates and estimations based on the historical data from previous iterations work better at the building-time and sprint-planning stages. Source : Medium.com Agile and waterfall projects require different estimation techniques Different management strategies presume different software development estimation techniques. Experts opine that most projects can be assessed based on traditional/conventional (mostly waterfall) and agile methods. Traditional methods are usually based on bottom-up estimation, while agile methods are usually based on top-down assessment. Source : Altexsoft Bottom-up methods require a period from several weeks to several months to define the detailed requirements of the project. Such methods identify tasks and resources required for project completion to estimate the delivery date and budget. The idea is to plan ahead, while the top-down approach is about navigating in the process. In contrast to the bottom-up method, the top-down technique identifies key project points and starts with them. The planning process involves multiple iterations that allow the project to be broken down into smaller subtasks and the assessment to be adjusted during project implementation. Each of these methods has its pros and cons. For example, bottom-up techniques help reduce uncertainty about the project development process but have inbuilt risks of over- and underestimation. Top-down methods allow the team to quickly adjust and change development directions, but bear greater uncertainty for clients and managers in terms of time, costs and effort required to deliver the project. As a result, each of the two methods is suitable for different project types, as shown in the table below. Source : IBM On the one hand, assessment methods and techniques help address, at least to some extent, the uncertainty associated with the development process. On the other hand, there are no one-size-fits-all solutions for software development estimation, as each project is unique, each development team has different amounts of resources available to it, and each client has different requirements based on the available budget and timeframe allocated for project completion. This means that software estimation should be considered as an orientation to the project’s scope that can be adjusted in the development process, rather than a document with final obligations that have to be followed by all means. Effort estimation is a way to make agile projects more predictable Estimation issues we discussed above touched upon the time, costs and uncertainty associated with project delivery. There is another element that is important when assessing projects that follow agile methodology — the effort required to deliver the work. In fixed-price projects, the client pays for the number of tasks that have to be completed by the development team. This works well for projects that use traditional waterfall methods for management, where the specifications are more or less clear and the amount of effort required to deliver each task is more or less known based on analogy or historical cases. However, for innovative projects with unclear input and specifications, the estimation of effort can often not be done right from the start. Such projects possess a greater degree of uncertainty, as additional information only becomes available during subsequent iterations. This lack of information makes it difficult to identify how long it will take to complete each task and how much it will eventually cost. This is where software effort estimation techniques come into play. Agile development is collaborative work, which means that project tasks are usually assigned to a team and divided among team members in the process (in contrast to the waterfall, where individual contributors are identified at the beginning). Researchers identify three main effort-estimation techniques: Planning Poker, Constructive Agile Estimation Algorithm and AgileMOW. Planning Poker is based on a collective assessment of story points by experts who use cards with Fibonacci numbers (1, 2, 3, 5, 8, 20, 40, 100) to represent their estimates. Smaller numbers represent less uncertainty in effort assessment, while bigger numbers represent more uncertainty. The overall effort required to complete a set of tasks is calculated based on the average estimate by all experts involved. If the estimates differ significantly, the marginal estimates are discussed further until a collective agreement on the proposed effort is reached. Constructive Agile Estimation Algorithm consists of early estimation and iterative estimation. Early estimation identifies the initial scope to draw the initial budget, while iterative estimation is done at the start of each iteration to include new requirements and make budget adjustments. The algorithm is based on vital factors (project domain, performance, configuration, data transaction, complex processing, ease of operation and security) that are assessed and used for estimation. Each of these factors is evaluated as low, medium or high using Fibonacci numbers. The final estimate is made by multiplying these evaluations to the story point. AgileMOW was introduced to estimate the delivery of web applications. It uses both expert judgment and an algorithm to estimate effort. This method is based on evaluating the following factors: communication skills, the proximity of team, feedback, courage, management skills, technical ability, reliability, ease of use and early delivery. The algorithm is based on the Agile COCOMO II (Constructive Cost Model) and makes estimations by analogy, which allows cost and effort for the proposed project to be predicted based on previously gathered data about the key factors mentioned above and their weight in the project. The model is

A product owner is a specialist with a strong understanding of the business as well as the vision, goals and mission of a product. The role of a product owner is central to the development lifecycle, and responsibilities vary depending on the product type and specifics of the development process. A product owner’s primary job is to coordinate a product concept, guide a product team to turn that concept into reality and deliver a product that the target audience would be happy to use. In deciding whether or not to hire a product owner, employers might feel confused about the exact nature of the product owner’s role and responsibilities. In different companies, product owners’ responsibilities differ depending on the perspective and definition of the role. Some employers might expect tech-savviness from a product owner, while others could require product owners to be more managers than tech specialists. That makes it difficult to determine a universal set of skills a product owner needs to have, leading to employers’ confusion. This article will discuss what a product owner does and how having one can benefit a company. It will further discuss the reasons for and against having a product owner in the team. What does a product owner do? As stated, a product owner plans the product direction and manages the development team responsible for creating and building the product. The product owner should be a thoughtful decision-maker, charged with making tactical and rational decisions about which features to build and when. Obsessive focus on planning and aiming to get the right product to market at the right time is what allows a good product owner to stand out. In teams that follow the agile methodology, product owners represent both the development team and the client. A person in this role is responsible for managing an extensive group of people and handling a range of activities, typically including the following: Create the product vision and ensure alignment across the board Make strategic, rational decisions about product direction Manage the development process; plan and prioritize features Adjust the product backlog Be a mediator between the client and the team; clarify technical aspects (constraints, drivers, opportunities and benefits) to the client; clarify business requirements to the development team Control the project budget and maximize the delivered business value A product owner is a connector rather than a doer and doesn’t usually write code or manage the internal technology of a product. In theory, the role doesn’t require any obligatory experience with the technology stack. However, having a tech background helps product owners to bridge the gap between technical and business aspects and explain complicated technical issues to the clients. Why does your company need a product owner? As part of an agile team, a product owner is responsible for smoothing the development process and clarifying any misunderstandings that pop up. The product owner should be prepared to resolve any contradictions about what the team builds, gather and share product information with stakeholders and make ongoing decisions. Having someone with those skills on the team provides a range of benefits: An agile software development process gets streamlined under the supervision of a product owner. A product owner is a reliable source of information. The team saves a lot of time by handing over many product issues to the product owner. A product owner acts as a single decision-maker when decisions about the product need to be expedited. The product owner role has its roots in agile development. Product owners set key milestones, guide the team towards them and report directly to the development team. They need to be persuasive coordinators and strong communicators so that they can lead people. But a product owner is not a scrum master, although these roles have common ground. Scrum masters are responsible for the production process, managing teams, planning sprints, communicating with stakeholders and often the handling of customer and product support. In most scenarios, they are external partners to product owners, with whom they collaborate. Efficient product owners understand client needs. They know the audience and the objectives of the product, which enables them to estimate the value a new product feature could bring to users. They also have ideas about what could give a competitive advantage to the product and what would make a client happy. A great product owner needs to be able to understand the clients’ pain points, their motivations and their journey. If a client has issues with the product, the product owner will have to invest more time and effort in monitoring the testing of the current product version by the team. If a client has high expectations for the product, the product owner will be highly motivated to lead the client to an amazing experience. When the product is finalized, the product owner is responsible for getting that product to market. Product owners take a lot of pride in the product they build and are driven by a vision and mission to deliver a valuable product. Pitfalls of hiring a product owner Some employers could decide not to add a product owner to the team because of the vague nature of the role and responsibilities. The confusion starts with the position a product owner occupies in a company. A product owner’s job is mainly to communicate with people of different ranks in a team or a company. However, the product owner title can be a mere formality, since the product owner doesn’t actually own the product. It’s often a case that the product owner has little power, and more often than not has to try to negotiate the agenda with those in higher positions. In addition, employers might delegate to a product owner some tasks that go beyond resolving product issues. Product owners might be engaged in managing budget, creating product vision, sharing responsibility for profit and loss or acting as a product manager. As a result, the roles of a product owner, product manager and business analyst often overlap, so

You might be surprised to find out that Artificial Intelligence (AI) is not that modern, as it has been established as a field of study since 1956 at a summer workshop held on the campus of Dartmouth College (US). Those who attended became the leaders of AI research (John McCarthy and 9 others). Before them, Alan Turing has conducted some research on AI, creating the Turing Test. The Dartmouth College gang failed by underestimating the difficulty of the project, bringing on the so called ‘AI winter’, when progress, interest and investment in the field stalled. But at the beginning of the 21st century investment and interest in AI boomed. This was due to advancements in various fields that are tangent to AI. Innovations in hardware development, including sensors and GPUs, made it possible for AI to have the resources it needs to process huge amounts of data and to interact with its environment. Just like humans, AI needs experiences to learn from. Those experiences for AIs are the data sets, collections of data, whose availability has increased exponentially in later years. The development and refinement of machine learning algorithms and strategies have helped immensely, because these describe how the AI should process and extract information from the data sets or how to learn on its own. Also, Cloud services have made AI solutions available to more customers/businesses. The victory of AlphaGo (a Go playing AI developed by DeepMind) against a professional human player, in 2016, is considered to be the starting point of The Age of AI. This victory was important because it shows that machines can really learn. The nature of the game of Go is such that you cannot use brute force to determine all possible moves, as there are as many as atoms in the universe. Therefore AlphaGo uses reinforcement learning and neural networks to mimic the learning process of a human brain. Our world is currently going through a major transition. AI is progressing faster than you think and is very likely going to revolutionize the world, how we live and how we do things. Let’s see some of its applications in different fields: Military Presumably, whoever masters the AI technology will rule the world, that’s why the first industry to adopt and deploy AI is the military and the greatest powers of the world are in on it (US, China, Russia). Applications of AI in the military include: self-driving vehicles (airborne and land) lethal autonomous weapon systems intelligent surveillance robot soldiers robots that carry heavy loads over rugged terrain robots that can be sent into dangerous environments, like radioactive places, or for search and rescue anti-robot robots kamikaze drones earlier detection of terrorist attacks If you want to be creeped out but also deeply impressed, check out the demo videos for the Atlas and Spot robots from the Boston Dynamics company. Their mobility, agility, speed and human-like movements are remarkable. Healthcare Some of the diseases that humanity has to deal with have too many variables. No human can hold in their head all the information necessary to understand them. But a machine can easily do that. Healthcare is a field where AI will feel at home and it can help make the shift from reactive to predictive care. After studying enormous amounts of patient data and scans collected from all over the world, an AI can see patterns, it can diagnose, it can offer suggestions, predictions, it can detect shades in a scan that humans cannot and it can detect cancer 5 years prior to it being visible to humans. Among the number of patients that undergo surgery for potentially cancerous breast lesions, only some of them actually need these surgeries, and AI would be able to filter out the healthy patients. Bionic limbs are already used with success and they use machine learning to make quicker decisions and improve. They improve the reading and interpretations of the signals from the muscles and also create the sensation that the artificial limb is part of the body by sending feedback to the wearer. Hugh Herr has become the pioneer of bionic legs after losing his legs due to frostbite. Who better to understand the physical and engineering challenges than an amputee biologist mechanical engineer? Parkinson’s disease could be diagnosed earlier by wearing an AI device that detects changes in the voice or unusual patterns in walking and movements. Accessibility devices are developed and available for blind people. These devices and phone applications use AI to interpret and describe the environment to the blind person. Elon Musk’s Neuralink project is trying to resolve spine and brain problems (paralysis, brain damage, seizures, extreme pain, depression, restore eyesight, etc) with a seamlessly implanted device in the brain. The applications of this device are quirkier than that, going towards making new forms of communication between people possible, like telepathy. And offering a brain-machine interface that will allow us to control devices with commands sent directly from our brain and eventually achieve symbiosis with AI. 5G will enable more advanced AI. Remotely performed surgeries need precision and instantaneous timing that can only be delivered by the 1 millisecond latency of 5G. Agriculture Big agricultural machines can be driven and controlled from the living room of the operator. The machines are equipped with sensors and video cameras maximising safety. They can even remember where the seeds were planted, so nothing is left behind during harvest. With computer vision, they can detect weeds, pests, soil defects and defective crops. The localized detection of weeds and pests allows for local and automated treatment, thus decreasing the quantity of pesticide used. A farmer in Japan used AI computer vision and robotics to enable cucumbers to be automatically selected and categorized, saving him hundreds of work hours. The artificial intelligence driving his farm it’s called TensorFlow, it’s open source, and was created by Google. Transport Bicycles and trains were invented in the early 19th century, motor cars in the 1890s, aircrafts in 1903 and next on the list are electric and self driving or autonomous cars. Probably the first greatest and complete achievement in the

The pandemic has forced many workers around the world to shift from the office environment to working from home. In trying to limit the spread of the virus, tech companies like Twitter, Google or Microsoft have encouraged employees to stay at home. Many companies have closed offices and set up remote collaboration, using digital tools to keep in touch, monitor work and communicate efficiently online. According to a Workhuman survey, only a third of the US labor force were working remotely before the pandemic, during which the number of remote working days has doubled and continues to increase. Many workers and teams may feel uneasy adjusting to new realities, but, according to a global poll, 32% prefer to work from home. In this article, we will consider 8 valuable work-from-home tips for remote software development teams and managers. Manage time wisely Have daily check-ins Establish sustainable communication Set tasks clearly and make sure your team understands you Encourage workers to organize their work space Keep up the company culture Focus on the results Give your team more flexibility to get the work done How businesses aiming at remote cooperation may win The diversity of remote teams fosters more unique ideas and solutions and allows senior staff to estimate the development process from diverse viewpoints, ultimately resulting in financial gains. According to Gartner, about 75% of businesses exceeded their financial plans in 2020 while working with diverse decision-makers in global teams. Financial success comes along with other benefits. Let’s look at the key benefits of having remote software development teams. Reduced costs. Reduced costs are perhaps the greatest benefit of remote work. Remote-work statistics say that businesses could save about $11,000 per year for each half-time remote employee. This springs from cutting office maintenance, electricity usage, support staff salaries and everything else needed to create a productive office environment. Recruiting talent from all over the world. Talent acquisition remains one of the largest pain points in the world of software engineering. By hiring teams remotely, employers choose from a larger pool of talent and are able to pick the best specialists for their projects. Work/life balance opportunities. Remote work is not only a great way to spend more time with family and loved ones. It also allows employees to work at a time when they are most productive. Buffer reveals that 32% of global poll respondents name flexible schedule as the primary advantage of remote working, allowing them to choose the most convenient hours for working. This type of working environment benefits both employees and employers. More efficient teams hired in different regions. Many companies try to maintain offices in different countries and regions. Even in the absence of an office, hiring a whole team in a remote region, depending on project requirements, might help bypass time differences and other issues. Eco-friendly remote work. With staff working remotely, employers could make a substantial contribution to environmental protection. Remote work has a positive impact on the environment, as it leads to decreased emissions (no more morning commute), reduced paper usage, energy and space consumption. In addition, the company gets to improve its image as eco-friendly. 8 tips to increase the productivity of remote software development teams Remote work has become more than a trend. Several managing tricks might help keep productivity and team communication high. This list of tips could be helpful in successfully setting up and managing remote teams. Manage time wisely Working remotely, it is useful for employees to set themselves a schedule, and stick to it. It is a great way to avoid procrastination and get the work done. It’s also handy to get the team synchronized on the one hand and create positive individual goals on the other. MIT researchers suggest taking regular 15-minute breaks every 75–90 minutes, which is vital in helping maintain high work efficiency and balance. Have daily check-ins Members of remote software development teams should stay in touch and coordinate progress on project parts. Daily check-ins help keep the community active and connected. Employees would be able to easily track progress, get timely help in resolving issues, and avoid certain mistakes in the future. These meetings may take 5 to 30 minutes, depending on goals and format. This is also a great way to create an environment of trust and empathy among team members. Establish sustainable communication Communication might be the hardest thing in managing remote software development teams, and keeping everyone in sync is mandatory. Different time zones, individual working tempo, linguistic diversity and other factors could complicate communication. Equip your remote employees with communication tools so they can function effectively, and teach them how to use these efficiently. E.g. if after numerous emails the work isn’t moving ahead, they should know it’s time to switch to video conferencing. The array of tools to choose from is quite vast: Google and Microsoft offer complete solutions (Google Chat/Meet, Microsoft Teams), but other good options are also available: Slack, Zoom, Trello, etc. Set tasks clearly and make sure your team understands you Managers are unable to physically approach remote employees for a chat, so it is vital to formulate tasks precisely. Tasks must be set clearly and managers should make sure the team understands them. It is good practice to include a brief description of each task and its scope, and to identify and allocate responsibilities. Specifying deadlines and hours of work for each task is critical as well, and for tasks with no clear deadlines, giving a specific due date will keep employees working on the task. Encourage workers to organize their work space Generally, 80% of what people perceive or experience correlates with their visual environment. Having a disorganized workspace may also affect productivity, as a well-organized space helps reduce stress. Also, having an isolated workspace free from distractions helps workers concentrate and meet deadlines. This is something that managers should encourage. It helps to send an occasional friendly reminder to those employees who still haven’t got their home office set up properly. Keep up the company culture Keeping the human touch within remote teams is crucial. One

Customer service plays an important role in building the brand reputation for your business. Often customers get in touch with this department because they want to address a problem regarding your services or simply ask a question about one of your products. Having an easy way for your customers to reach your staff members is essential, as it will directly impact your reputation. There are multiple ways to make this interaction happen. Nowadays, more people prefer to communicate online via text messages instead of a phone call. They often contact you through your social media accounts or use the online chat available on your website. This approach may seem like a perfect solution, but even then, a staff member would have to manually reply to a customer asking even simple questions such as ‘what are your business hours?’. Dialogflow Agents – engage with your users in a personalized way A chatbot is a computer program that simulates and processes human conversation, either written or spoken. They can intelligently interact with your users, creating very effective conversational experiences when tailored to a specific business need. Google Dialogflow is a platform that allows you to create chatbots (also known as agents) and integrate them into almost every popular service or assistant out there, like Facebook Messenger, Twitter, Amazon Alexa etc. It also allows you to use webhooks (user-defined HTTP callbacks) in order to make your chatbot smarter by gathering information from external APIs. Thinking about asking how is the weather like in a specific region? Chatbots can give you an answer for such a question by relying on Webhooks . How does it work? Dialogflow uses Natural Language Processing (NLP) technology. It translates natural language into machine-readable data by training a machine learning model with your examples. This process can be described as the experience of collecting what the user is saying, mapping it to an intent, taking actions on it and providing the user with a response. Source: Google. Figure 1. Example of how Dialogflow handles a user utterance Utterances are what an end-user would say to invoke the chatbot. These are then mapped to a specific intent, allowing us to collect parameters from the user. Once we know our users intent, Dialogflow can trigger specific logic in your service by configuring actions, while returning a response. Intents – capture the intention of a user who’s interacting with our chatbot User Expressions – each expression gets mapped to an Intent. These are the training phrases Dialogflow uses to train a ML model with many more similar phrases Entity – for each Expression mapped to an Intent, our chatbot has to figure out the thing the user wants information on. This is made possible with the help of Entities Setting up the Chatbot In this section we’ll build a Chatbot based on an open-source template, using the Verily COVID-19 Pathfinder virtual agent template. As the world responds to the COVID-19 crisis, providing your public with accurate timely information is crucial to keep people safe and informed. This template sets up your agent to answer frequently asked questions based on the latest Centers for Disease Control (CDC) guidance. Each Dialogflow agent has two default intents: a default welcome intent – matched when an user begins a conversation with your agent and a default fallback intent – matched when your agent doesn’t understand the user’s query. Head over to the Dialogflow Console and create a new agent, selecting one of your existing Google projects. Proceed to import the COVID-19 template by clicking on the gear icon on the left panel and selecting Import from ZIP under Import & Export tab. Once the import process is finished, you should see lots of intents (besides your existing default intents) and several entities already defined for your chatbot. Let’s take a look at a random intent provided by the template – coronavirus.treatment which has the following training phrases (defined above as User Expressions) : “Should I take antibiotics?” “Treatments for Webhooks” “Is there a cure for COVID-19?” “What do I take for coronavirus” Training phrases are expressions you can expect from users, triggering the intent. The more expressions you add to an intent, the better your chatbot will be able in figuring out what you actually want. Each expression can have an entity that defines the topic the user needs information on. In our case, the highlighted words are linked to the @covid-19” entity. Finally, our Agent needs to respond with something for this intent. We’ll simply provide a static text in the Responses section. Do you want to see this chatbot in action? There is a quick way to test your chatbot directly from the Dialogflow Console, without having to integrate it with a custom service. Just ask a COVID-19 related question using the right panel. NOTE: coronavirus.closure, coronavirus.confirmed_cases and coronavirus.death intents require you to set up the Google Maps and BigQuery APIs, steps not covered by the scope of this article. Facebook Messenger integration There are several steps you need to take before using the chatbot in Facebook Messenger. While I provide the main steps below, feel free to check the official documentation for any additional information. Create a Facebook page Don’t forget to save the Page Access Token, because you will need to use this value when setting up a Facebook App. In case you don’t have this token anymore, use the GraphAPI Explorer to retrieve it. Create a Facebook app and link Facebook Messenger Platform to that application In order to build and manage Facebook applications, you must sign up for a developer account using your regular Facebook account. Head over to developers.facebook.com to get started, then subscribe your app to the Facebook Page you created earlier. Don’t configure the webhook or test your integration yet. Configure the integration from the Dialogflow Console Enable Facebook Messenger service from the Integrations tab in the left sidebar menu. Provide any private token you desire (Verify Token). Enter the access token you copied when creating the Facebook page (Page Access Token). In case you don’t see the Integrations tab, keep in mind that when a non-default region is selected in the Dialogflow Console, the Integrations feature is not available (among other things). Configure the Facebook

Some product development teams might fall into the trap of thinking that all customers need the same thing. However, an outstanding vendor should cultivate a mindset of sharing and exploring which ideas would work well for each particular product, and which wouldn’t. Today, with the growth of agile methodologies and DevOps practices, companies that choose to outsource the development of their software increasingly prefer a product mindset. This allows vendors to individualize their approach to outsourced software product development, deliver results that would best meet market and client needs, and ensure more flexibility throughout the development process. Let’s see how the product mindset differs from the project mindset, and learn how to find out if your potential product development vendor has it. Project mindset vs. product mindset The project-focused approach revolves around a predefined scope of work, strict time frameworks and compliance with the initial plan. In terms of the project, the vendor is mostly concerned with allocating resources more efficiently, spending less while doing more. In this mindset, project managers approach the project as a process that must be followed strictly, and their attention might be diverted from product specifics and actual user needs. In contrast, the product mindset is all about critical thinking, which helps correctly define the product goal and map out steps to success. The approach begins with defining goals and visualizing the customer’s problem or need. Focusing on the customer’s requirements will help the vendor guide the design and development efforts of the team in a way that optimizes time, resources and project outcomes, which is a win for both sides. In product development outsourcing, creating value for the customer and making this value available and easy to tap is paramount, while constant customer feedback can be used to help evaluate the results and estimate the degree to which the results align with the product delivery objectives. As you can see in the diagram shown, development patterns of a vendor with a project mindset are predictable: the whole process is broken down into small chunks, depending on time, budget and resources. A product manager, on the other hand, would take the agile approach, splitting the development process into sprints and focusing on delivering a minimum viable product (MVP) quickly, in order to compare the results with the actual market need and be able to implement changes. 5 components of a product mindset Vendors with the product mindset are in the habit of constantly brainstorming new ideas in search of better ways to achieving their goals. Being creative, they tend to focus on the outcome rather than the process. This approach provides them with a better understanding of how to get things done in a lean way. Here are the core dos and don’ts of a vendor who thinks product. Deliver value, not features A product-centered approach doesn’t welcome adding a feature just for the sake of it. The vendor’s main task is to think of benefits to the customer from using the product. If a product helps handle real problems, customers could return for product updates. Therefore, vendors communicate with the target audience via an MVP and marketing channels, understanding practical customer needs, gathering feedback and amending the product to make it solve acute problems better. Don’t try to get everything right Vendors shouldn’t expect to get a flawless product on the first try. Developing an MVP to test the idea might help determine the target audience and let users test the product. Early adopters could pitch a new feature and provide a concept, and the vendor would need to gather feedback to decide if the idea is worthwhile. User feedback Product creators build initial promotion campaigns to engage more users and entice them to leave feedback or take other action, as planned. Valuable product features and chosen marketing communication methods will determine the number of early adopters and followers. A product-focused vendor will find out the audience’s expectations, identify the pain points of the product and work out methods of solving them. Stay flexible Sudden changes in the market and shifting audience preferences shouldn’t frustrate a product vendor. When a trend, product or competitor changes, a vendor should know how to change tack and adapt the product. An agile approach will help embrace changes smoothly and allow the vendor to come up with new features for the product. They might have to modify their company culture to become agile and adopt the product mindset. Stay consistent Reliable vendors shouldn’t stop delivering value to their clients. They evolve their products, monitor changes and test new ideas of exchanging value with clients and end users. There’s always room to make a change and improve the offer. When a vendor delivers a great product or service, the audience will appreciate it. Check if your product outsourcing vendor has the product mindset You may be wondering how exactly to find out if a potential vendor of outsourcing product development services has a product mindset. The best indication is the questions the vendor asks and the topics they raise. If you can evaluate these questions and their reasons for asking, you would get a good sense of whether the vendor’s priorities are product value and client success, or project plans and limitations. The following are dead giveaways for the product mindset: Vendor enquires about the ways a product could solve real-world user needs. They are interested in the market fit of the product. They try to find out details of the product’s value to prospective users and its potential in the market. Managers might suggest an approach that requires less effort and resources and reduces the number of hours billed. A vendor does a lot of work during the pre-sales phase to understand real customer needs. Digging below the surface of the initial requirements may demonstrate the vendor’s commitment to making the product a success. Vendor’s specialists can comprehend the current status of the product (for instance, problem validation, solution validation, market validation, scale-up) and suggest the best