We produce
people-centric
digital experiences

 

 

 

The pandemic expedited the implementation of technologieshttps://cleverlance.de/en/blog/Pages/pandemic-expedited-the-implementation-of-technologies.aspxThe pandemic expedited the implementation of technologies<p>​​Petr Štros believes that this year’s technological trends will feature long-distance deliveries, automation and data-driven companies. These will help companies deal with the lack of manpower, says the boss of Cleverlance.<br></p><p>The last two years were, as far as the world of technology is concerned, a bit like “dog years” – each saw as much change as seven normal years. Or, at least that’s how the boss of Cleverlance, a domestic technology company, sees the pandemic’s impact. He believes the during the pandemic it was possible to successfully implement technologies into practice at breakneck speeds – the rate of changes in many companies was previously unforeseen. And so everything is moving ahead at an incredible pace.<br></p><p> <img src="/de/blog/PublishingImages/Articles/CreateIt/45.jpg" data-themekey="#" alt="" style="margin:5px;" />In his commentary for CzechCrunch, the boss of Cleverlance – a company in Aricoma Group which recorded <a href="https://cc.cz/ceske-cleverlance-spadajici-do-kkcg-karla-komarka-hlasi-uspesny-rok-utrzilo-14-miliardy-korun/">1.4 billion Czech crowns</a> in revenue – spoke about the technological trends that we’ll see in 2022 and about what companies should focus on if they don’t want to get left behind or even strive to be part of leaders in technology.<br></p><p>Technology trends accelerated by the pandemic on one hand further deepen the lack of IT specialists on the job market who would be able to help implement new technologies. On the other hand, these can help many companies deal with the lack of experienced employees of many other professions.<br></p><p>Communication technology allows them to “remotely” make use of employees who are outside of the standard geographic range of their branch offices and plants. At the same time, it is possible to for instance “algorithmize” the key expert know-how of the organization which was previously held by now-leaving senior employees, and in this way make it available for the next generation.<br></p><h2>Remote delivery of services</h2><p>Working from home (and long-distance work in general) allowed companies in many professions to also incorporate employees into their teams even if they are from areas that would otherwise be out of the range of their branch offices. This “decentralization” of work is also accompanied with the ability to deliver services and products “remotely”, without the need to be physically present at a customer. IT and tech consultation companies from India, Vietnam, Ukraine, Belarus, Serbia, North Macedonia, Poland and the Czech Republic nowadays commonly provide their services to companies from Western Europe and North America.<br></p><p>The sale of clothing and groceries online is now also common, and based on the Cushman & Wakefield consultation company this is set to even double year-by-year. Car manufacturers as well as used car dealerships are introducing platforms for online sales, allowing customers not only to choose their vehicle but also to take care of financing, signing leasing contracts, paying the first instalment as well as agreeing on the method and location of the handover.<br></p><p>In 2022 the ability to make digital deliveries will also be indispensable for companies where previously one could not even imagine this development. That is why IT suppliers are currently dealing with, among others, a growing customer interest in e-shops connected with client systems and digital-marketing platforms that can customize their offers to specific visitors.<br></p><p>Demand in the area of tailor-made software is also on the rise, since companies need to create customer portals that would allow them to provide their digital services. However, it is well known that the IT job market is by now nearly completely saturated. So, is it possible to meet the growing demand for IT services?<br></p><h2>Automation and artificial intelligence</h2><p>The terms “automation” and “artificial intelligence” are most frequently used in the context of the digital transformation of companies. But another important role of these is the ability to “algorithmize” the key expert know-how of the organization which was previously held by now-leaving senior employees, and in this way make it available for the next generation.<br></p><p>It is worth noting that not only IT may need to deal with a lack of qualified employees. The boomer generation as well as a part of generation X are in the process of retiring. In 2022, the median age of the Czech Republic will reach 43 years (meaning that half of its inhabitants will be younger and half will be older). The rate at which experienced employees are being replaced by their younger colleagues is probably the fastest it has ever been.<br></p><p>Storing the expertise of departing experts and keeping it in the company so that it can be used in the future is something artificial intelligence (AI) and algorithmic decision-making can help with. One advantage of software with AI elements is that it is capable of machine learning. This allows technologies to help companies not only retain their know-how, but also to develop and use it much at a much quicker pace in turn leading to a competitive advantage.<br></p><p>Typical areas where these technologies are used include cross-selling and up-selling, assessing loan requests as well as maintenance planning and management. They are used for instance to flexibly adjust prices for individual groups of customers. In the last two years, they also expanded to other areas and this trend will accelerate further in 2022.<br></p><h2>Data-driven organizations</h2><p>Information systems for decision-making are a well-established concept by now. IT has long provided support for company decision-making through the introduction of ERP systems, management information systems, business intelligence and similar platforms.<br></p><p>In the past, systems for the support of decision-making were used primarily for easy access to data, “drilling down” and breaking down information into details and analysis from multiple perspectives. However, the conclusions were left up to humans.<br></p><p>Nowadays, the trend has shifted to “single-purpose” online dashboards that analyze the entrusted data and use knowledge models to provide users primarily with indicators, conclusions and recommendations based on the obtained values. These are applications that are capable of identifying anomalies, pinpoint them and recommend a suitable reaction without requiring users to search for these anomalies in the data themselves or to analyze their causes.<br></p><p>Examples of such services in 2022 will include, for instance, customer service management, real-time online sales monitoring, productivity tracking, stock management, appraisal of real property values and assessment of the current status of a software product in development based on an analysis of the timeline of results from regular tests. In 2022 the rate at which these cloud-based services start appearing on the market will see a considerable increase. For companies, this means they shouldn’t be afraid of providing their data to trustworthy third parties – parties which are already preparing for this today and are massively investing in IT security.<br></p><p>source: <a href="https://cc.cz/pandemie-zrychlila-zavadeni-technologii-firmam-pomohou-resit-nedostatek-lidi-rika-sef-cleverlance/">CZECHCRUNCH</a><br></p> ​<br>
For DevOps, it is important to completely change one’s mindsethttps://cleverlance.de/en/blog/Pages/DevOps-mindset.aspxFor DevOps, it is important to completely change one’s mindset<p>​​​​The exact definition and delimitation of DevOps is a very difficult question, even for experts who have devoted half of their professional career to the field. In this short article, we will attempt to at least briefly explain what the role entails and on the other hand what it usually avoids. The main focus here lies on developers, system administrators and implementation managers (i.e., the so-called operations area).<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps_title.jpg" data-themekey="#" alt="" style="margin:5px 0px;" />In the early days of technological development, a project team making applications consisted of developers analysts, testers, system administrators, as well as network and hardware specialists. And half of the possible obstacles to success could be avoided by just having a coordinated team. Simply put: The people responsible for development created an application (the developers) and handed it over to system administrators, who then implemented it (possibly using automated tools) on hardware in the server room.<br></p><p>Then, not so long ago, we saw the rise of so-called agile development. This rapidly sped up the whole process, and the communication between developers and operations became increasingly complex. At that point, minor problems could lead to a product (or its update) not being delivered to a client who is anxiously waiting for it. Or, the delivered product (or its update) could have major issues. The reason for this was, and often remains, communication between various parts of the team.<br></p><p>As we said, there’s developers and then there’s operations. These two “camps” do strive to communicate with each other, but in practice it’s very complicated. Each of them speaks, in some sense, a different language or at least a different dialect. What might be simple from the perspective of development might not be implementable on the servers, where one needs to take the infrastructure into account. At the same time, things which are easy to handle on the infrastructure side could be a difficult nut to crack for the developers.<br></p><p>What would happen if we were to take a developer and sent them to study operations? Or, from the other side, if we were to take someone from operations and sent them to scout out what’s happening in development? That is how we get someone who could call themselves a DevOps specialist. But for them to “earn” the title, they need to understand more than just what the product is made of and where it’s implemented. They need to, first and foremost, change their mindset.<br></p><p>Here we’re referring to a whole range of procedures which automate and standardize the processes between the development of software and operations, so that it is possible to build, test and release SW more reliably and quickly.​<br></p><h3>New Mindset + New Tools + New Skills = DevOps​​</h3><h2>You build it, you run it!</h2><p>The basic idea is that DevOps isn’t just about technology – it’s a whole development paradigm. To make sure that a company works as it should, one needs to change not only the applications they use but also the whole approach to development, testing and implementation into production; in fact, the way we think about this general process should change.​<br></p><p>It used to be an utopian dream, but today it is in fact possible to rent whole clusters, including administration and connections to various services such as databases (e.g., PostgreSQL, MySQL and CockroachDB), queues (e.g., Kafka and RabbitMQ), analytical systems (Hadoop), logging and monitoring infrastructure (Elasticsearch, Kibana, Grafana) as well as various IoT services and REST API. And how else to speed up the whole process from the creation of an application to its implementation than by knowing how to run these applications on your own.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps1.png" data-themekey="#" alt="" style="margin:5px 0px;" />​​<br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Hybrid Cloud Archite​​​​cture <br></h4><h2>Virtual Private Cloud</h2><p>If a company is operating an application, the trend nowadays is to use the cloud rather than rely on one’s own on-premise infrastructure. Today, cloud infrastructure can be optimized for high availability, low latency, and it is even possible to set it up in a way where for instance customers fro the Czech Republic will use a data cloud in Germany whole French customers will use one in France. Modern clouds meet high security standards, and another advantage of them is that it is possible to make use of a range of technologies associated with their operation as a service model. In practice this means that companies don’t need to employ their own specialists who would be responsible for infrastructure including its maintenance and installation, since they get all of that as a service. They then operate their applications on this infrastructure in the form of so-called microservices. This leads to savings in terms of both manpower (which is at a premium nowadays) as well as costs. So, it is important to make sure new applications are developed as cloud-native. The most frequently used clouds are Azure, AWS and Google Cloud.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps2.png" data-themekey="#" alt="" style="margin:5px 0px;" />​<br></p><p></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Internet of Things Arc​hitecture<span class="Apple-converted-space"> </span></h4><h2>Microservice architecture</h2><p>Most applications used to be developed as monolithic programs. However, today applications commonly consist of smaller parts which communicate with each other through a single interface. The advantage of this? Monolithic applications might in some cases need, say, fifteen minutes to start up, while smaller apps only take dozens of seconds. For microservice architectures, we always strive to have them implemented in Platform as a Service or Software as a Service modes.​<br></p><p>One popular methodology in this area is the Twelve-Factor App, which is essentially a set of rules that make development significantly easier to track and manage as long as the whole team follows them. It describes how to handle code, where to store configurations, what to do with backups, builds, how to deal with scaling, logs and administration.​<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps3.png" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Caching Cluster Arc​​​hitecture<span class="Apple-converted-space"> </span></h4><h2>Serverless architecture</h2><p>Another highly interesting foundation of the architecture of modern applications is to have them operate as serverless. Basically, one takes part of the code from the aforementioned smaller applications – code which could be more resource-intensive or might not be required to run continuously – runs it through an interface provided either by AWS (AWS Lambda) or Azure (Azure Functions), these then start small subprocesses, compute the results and return them back to the services. Scalability can also be applied on the level of functions which can be run in parallel and independently of each other.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps4.png" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Serverless Applic​​ation Architecture​<br><br></h4><h2>Automation</h2><p>There’s another characteristic of DevOps that we didn’t mention so far: laziness. DevOps strive to maximally simplify their life through automation. And automation is the alpha and omega of today’s DevOps development. We automate implementations, work processes, testing, infrastructure, even the management and revision of user rights and accesses... essentially everything. When to start with automation? As soon as an activity needs to be carried out more than once.<br></p><h2>Automated testing of code </h2><p>In order to expedite development while making sure that we didn’t break anything anywhere, we need to have everything covered by tests prepared by the developers themselves.  Taken ad absurdum, this idea implies that first one should prepare a test and only then the function. After all, Test Driven Development is by now an established notion within software development. And writing tests on your own instead of waiting for testers is part of the aforementioned DevOps mindset.​<br></p><p>In the world of Java, we do that using JUnit, Mockito, MockMvc, Selenium, Sonar etc. So there’s plenty of tools, but the thing that’s sometimes lacking is the willingness of developers to spend time on this.<br></p><h2>Automated workflows ​<br></h2><p>Workflow automation is done using tools such as Jenkins (CI/CD), GitLab, Container Registry, Jira. In practice, this means that a developer puts their code in GitLab, the automated pipeline runs unit tests on that, compiles the program and implements it on the server environment, where it is then continuously monitored. Ideally, everything really runs on its own.​<br></p><h2>Automated infrastructure: Infrastructure as code! </h2><p>An ideal end result is to have everything always run the same on all environments, and to be able to create these environments with just a single click. Nobody ever needs to install operating systems; everything should be scripted using templates. In order to create infrastructure as code, we first need to shield the application from the hardware. This is done by applications such as Docker and Podman. We take a created application and implement it in some ecosystem – most frequently Kubernetes or OpenShift. Everything can also run on-premise, but that’s not really what DevOps is about. Both Kubernetes and OpenShift can be launched in just a few clicks. Kubernetes is hosted by all larger providers (AWS EKS, Azure AKS, and Google GKE).<br></p><p>We have several options for the infrastructure. We can “generate” an infrastructure from the comfort of a web browser or, as the preferred option, create a template that will let the provider create the infrastructure directly through an API layer.​<br></p><p>The most frequently used universal template software is Terraform. It has connections to all larger providers, but it also possible to use on-premise servers. It is easier and often better to write these templates in native scripts (for AWS these are, for instance, CloudFormation in YAML a JSON, or newly AWS CDK, where it is possible to describe the infrastructure for instance in JavaScript, JAVA or Python). This allows us to maximize the provider’s capabilities. The template can then be launched, and can even be used to create an identical environment multiple times (which is good for various dev/test environments). The applications themselves can be delivered into the environments using all the usual tools by Jenkins, Gitlab, Bitbucket.​<br></p><h2>Measurements </h2><p>Our application is now in production, but that’s not the end of it. We need to start evaluating and analyzing it, debugging, and to do so we need continuous metrics and analytical tools. ELK Stack is a bundle of tools that can help us collect logs and visualize them. Kibana is a tool that allows us to browse through the logs in a visualized form all in one place; this is great for determining an application’s performance as well as identifying the cause of problems. Aside from error filtering, it is also capable of displaying CPU metrics etc.<br></p><h2>Methodology </h2><p>While the waterfall approach that rose to prominence in past years and was frequently used then does allow for careful development, it is not as great when it comes to speed and agility. That is why agile methodologies have become so popular nowadays; these allow us to split development into small chunks, which can then be handled independently. if you think about it, that’s basically the foundation for the whole DevOps philosophy – from infrastructure up to methodology and vice-versa. This means we do daily stand-ups and development takes place in short sprints. The standardization of the whole development process is important, and this covers analysis, development, testing, implementation as well as monitoring the performance of the completed application.<br></p><h2>Conclusion </h2><p>The success of a DevOps project requires a combination of expertise from various areas, high-quality technologies, know-how from the field, but first and foremost a change of how a team works and how developers think. But once all of that is done, the results are worth it. A well-setup project allows for faster innovation, can quickly react to business developments and requirements, teamwork is more efficient, the overall code quality is better and we get more frequent releases.<br></p><div><p>Source: SystemOnLine​​<br></p></div>
Why consultants buy creativityhttps://cleverlance.de/en/blog/Pages/droga5.aspxWhy consultants buy creativity<p>​​​At the beginning of May, New Your Times reported that the consulting company Accenture acquired the creative agency <a href="https://droga5.com/">Droga5</a>. This agency, with its 500+ employees, will become a part of <a href="https://www.accenture.com/us-en/about/accenture-song-index">Accenture Interactive</a>.<br></p><p>There are two reasons why this merger is interesting. First off, a business focused on strategy and consulting has joined forces with a creative company. And second, creativity as a tactical tool is experiencing a massive comeback after the era of consulting companies.<br></p><p>Droga5 is currently one of the most famous independent advertising agencies in the US. This company, founded by David Droga, represents creativity in its purest form. And now it is to intertwine with the culture of consulting and technological companies. These worlds could not be farther apart. One produces top-quality products in the form of TV spots and campaigns, the other makes slides with research results that are nowadays often accompanied by technical solutions. Groups of creative people will sit at the table with consultants and together look for the best solutions for the client.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/droga5.jpg" data-themekey="#" alt="" style="margin:5px 0px;" />This combination is definitely good news for creative people who strive to achieve more than a one-off advertisement campaign (even if it’s a successful one), but want to provide a more long-term, comprehensive customer experience. The same goal is shared also by clients who have dreamed for a long time of a supplier who can connect brand and technology via all of the client’s <a href="https://en.wikipedia.org/wiki/Touchpoint">touchpoints</a>. They are aware that after a decade of focusing only on technology and process automation, it is creativity and the communication method with clients that bring it all together and makes everything come to life.​<br></p><p>Whether the approaches and methods for satisfying the customer’s needs will join forces towards a shared goal, or whether these will remain mentally and procedurally divided as it has been in the past, is a big question. What Accenture did, though, is not unique. On the contrary, it reflects the trend of the fast-changing competitive environment. Merging of technologies, brand and creativity, which was pioneered a long time ago by Apple, is slowly but surely becoming a must for survival. This means you can expect more acquisitions of creative teams by consulting and technological companies.<br></p>

 

One of the largest
human resource bases
in Central Europe.

Every project starts with people. We are a team of 800+ IT specialists with cultural compatibility and professional approach.

  • Škoda
  • DHL
  • T-mobile
  • NN
  • Societe Generale
  • ING
 

 

 

The Automatic Testing Machinehttps://cleverlance.de/en/blog/Pages/Automatic-Testing.aspxThe Automatic Testing Machine<p>​​​​No universal testing program exists for automated testing. Every project needs its own unique script which is created based on an extensive expert assessment. Before each new project, an exact calculation must be made of which type of testing is optimal, effective, and more economical. Only after this can automated testing and a testing robot enter the picture.<br></p><p> “Generally speaking, testing automation speeds up the process, that’s evident. And thanks to automation, several different scenarios can be tested, the scope of the tests can be expanded, and each of them can be performed identically because robots perform scenarios absolutely the same way each and every time,” says Tomáš Mertin, an automated testing system developer at Cleverlance. As a result, testing and code writing are essentially simultaneous, and developers can fix any errors or inaccuracies within a short period of time.</p><p> “In recent months we’ve witnessed an increase in interest in automated testing, it’s a trend, but everyone’s expecting that it will reduce the number of people involved in development. I don’t think that’s going to happen,“ says Mertin. “Automated testing will definitely speed up development. It also provides us with better knowledge of the state of the application at any given moment. But tests, deployment, operations – someone still has to maintain all that. The human dimension is going to stay,” Mertin explains, adding that he thinks automated testing will not fully replace humans. “But it will save time, which they can then spend on actual development.”</p><p> Automated testing frameworks have proven successful in segments where development is constantly underway. Like the banking sector. “We’ve got a big project in which we’re practically building the entire digital banking framework. One phase has to precisely dovetail with the next one. These days agile management is used for things of this size, which makes it all possible,” says Jan Vajsejtl, who is in charge of testing at Komerční banka, one of the largest banks in the Czech Republic.</p><p> In the past, large companies like banks used waterfall testing. Testers would receive completed sections while work on development would halt because the developers waited to hear what they needed to fix. If any major intervention was needed, it was followed up with another phase of testing, prolonging the work. </p><p> In the past two years, automated testing has been added to conventional, time-tested, and efficient testing methodologies. It’s proven successful wherever development is practically non-stop. The experience with it has been exceptionally good, says Komerční banka’s Jan Vajsejtl.  </p><p> These are cases where automated testing makes a substantial difference. “Our experience is exceptionally good. The automated system my colleagues and I fine-tuned for our own needs allows us to test practically all devices and environments, cell phones, websites, and more,” Vajsejtl says. </p><p> Although the inside of the system is complicated, its use in practice is surprisingly easy. “I think the main advantage is that it’s essentially very simply written. So just a short, half-day training session is enough to be able to start to use it. You definitely don’t need to know how to program or have some deep technical knowledge.” </p><p> “For me it’s a testing success. We’ve put the testing framework to practical use and tried it out; my colleagues at Cleverlance and I tailored it to Komerční banka’s needs and augmented it with additional functionality. Given the amount of development we have, it’s a really efficient thing,” Vajsejtl.<br></p>

 

 

Scrum smells, pt. 1: Irregular releases—overviewhttps://cleverlance.de/en/blog/Pages/scrum-smells-1.aspxScrum smells, pt. 1: Irregular releases—overview<p>​​​​​​​There's been a lot written about what agile development and scrum should do for a team. After a team has been maturing for some time, it's easy to become blind and insensitive to phenomena that hinder its effectiveness and restrict its potential. Let's call them “scrum smells”.<br></p><p>Some teams are just starting with scrum adoption while others are moderately matured or even experienced in it. Each level brings with it its own smells and scents. This series will focus on both basic and advanced challenges that scrum teams commonly encounter. Today, we’ll talk about the problem of irregular releases.</p><h2>Inability to regularly provide releasable versions</h2><p>One of the basic scrum principles is being able to provide a potentially releasable product increment as a result of each sprint's effort. I personally believe this is one of the most valuable and underrated benefits of the whole scrum world. Scrum says that at the end of each sprint, the development team should produce a piece of software which the product owner can then immediately release and put to productive us, if he so chooses. That means that the software needs to be working, regression-free and without any work-in-progress stuff. Everyone on the team needs to have the feeling that there is no debt—be it technical or functional.</p><p>In real life, however, the production builds are provided quite randomly. Every scrum team has gone through this. At the end of the sprint the team would like to provide a final version, but there are incomplete features or regressions severe enough that this version can not be put out for productive use. So in the subsequent sprint the team attempts to fix the bugs, but continues developing new features in parallel, which introduces a new source of potential problems and uncertainty. Days and sprints go by and there is always something to be fixed in the current version.</p><p>This vicious cycle pressures the product owner to finally release everything that's been implemented so far. There's the always present “almost there” syndrome, the eluding moment of problem-free release. The product owner gets nervous and it's tempting to try to sneak one more “important” thing to the sprint, because god knows when the next release will take place. Long time-to-market is a reality. So-called hardening or stabilisation sprints occur, where teams just try to fix the product into a usable state.</p><p>Aside from the inevitable demotivation and pressure that arise, this also causes problems with planning and transparency. You never know where you truly are until you have no work left on the already developed backlog items.</p><h2>Preparing the ground</h2><p>So how to increase the chance of regular end-of-the-sprint potentially releasable versions actually happening? This is partially about a shift in mindset. Being able to provide a working, debt-free, done software increment must be a top priority for the team during the sprint and all activities need to focus on this one goal.</p><p>It all begins with the backlog refinement. Backlog items must be broken down to pieces as small as possible in order to give the team a high degree of maneuverability during planning. Oftentimes creating really atomic user stories is necessary—that means stripping the user story to the very core of the user's needs and solving it with the most straightforward approach. All the rest just becomes another backlog item, prioritised independently. Keeping the items too big or just being too optimistic about keeping some “easy to do” nice-to-have things attached to the core user story's essence is just naivety, frequently combined with a degree of convenience.</p><p>Then, at sprint planning, the team creates a strategy to steer the risk of discovering a severe problem shortly before the end of sprint with too little time to actually solve it. It helps to start the sprint with the riskiest features first and strive to start testing even separate parts of them as early as possible. This way there's a greater understanding of how much work there is really left to be done. Low risk items (like simple text changes or UI adjustments) can be left for later into the sprint.</p><p>The development team must not plan too much work, hoping that this time “we will manage”. The team must, based on past experience, realistically anticipate extra unexpected work even on “safe” backlog items.</p><p>And of course there is the well-known Definition of Done. Each team member must understand what it takes for an item to be considered done and everyone must understand it in the same way. What is on the DoD checklist? Well, that depends on the particular team, product and technologies being used. But if a team agrees, that DoD of each item consists of code to be written, unit tests or automated tests, documentation, code review, end-to-end test and anything else needed. Nobody can claim an item done until all this work has been done. This helps to create a common standard for quality and for complexity estimates. Strictly adhering to it reduces the risk of debt accumulation. Missing or unused DoD creates a fertile ground for debts and makes planning almost impossible.</p><h2>Day-to-day activities and decisions</h2><p>Frequent end-to-end testing during a sprint is absolutely vital. It is a dangerous illusion to create a single version one day before the sprint's end, test it and expect that all is going to be fine. That's not planning, that's gambling.</p><p>To enable this, new builds need to be created as often as possible, even several times a day. CI/CD pipelines are a must. TDD helps a lot. Automated regression tests are a must. Basically automating as much of the manual hassle as possible removes the reasons why teams usually avoid making builds regularly. This investment into automation is usually well worth it in the long run.</p><p>Adding feature switches (or flags) help. If it's evident that the team is not going to be able finish a certain backlog item (i.e. fulfill the DoD), it is “switched off” and it doesn’t interfere with the rest of the software.</p><p>The team must also understand that one done and delivered backlog item is worth far more than ten items in progress. The daily scrum is an ideal time for the team to evaluate the sprint backlog's progress and mutually collaborate on pushing in-progress items closer to a “done” state as quickly as possible. Team needs to learn to constantly re-evaluate where everyone's present effort lies and decide if there is something more valuable to concentrate on. All sprint backlog items are the whole team's job, not individual assignments. It is all about constant re-evaluation as to where to invest the day's efforts in order to maximise the chance of achieving debt-free software at the sprint's end.</p><p>When a sprint backlog item gets risky and it seems there's not enough time left in the sprint, the team needs to decide whether it wants to invest more energy in it (to increase the chance of getting it done, e.g. putting more developers onto it) or to stop working on it altogether and focus on another item that has a real chance of getting done. Decisions to drop a sprint backlog item must be consulted with the product owner.</p><p>For more about strategies to achieve regular releases, please check out the follow up “Scrum Smells pt. 2” post for more details.</p><br>

 

 

Development of multi-platform mobile and web appshttps://cleverlance.de/en/blog/Pages/Multiplatform.aspxDevelopment of multi-platform mobile and web apps<p>​​​Do you want your own mobile app? Nowadays it’s a given that one needs to do one for Android as well as for iOS; one is not enough. And more often than not, one also wants a web interface. However, essentially right from the introduction of mobile devices to the market, we’ve heard it said again and again that developing things separately for individual platforms is expensive. That is why various companies tried to introduce alternatives in the form of multi-platform solutions, however none of these really managed to become widely adopted. They had their shortcomings, were unnecessarily complex and held companies which wanted to develop their mobile apps flexibly in a kind of “cage” with limited possibilities. That is why for B2C apps it is often preferred to develop natively; there are no limitations as far as UX, animations and other details are concerned, and these things can be very important for the target group.<br></p><p>However, in the past years we see corporate mobile apps for which a perfect user interface and design is no longer a priority; emphasis is placed on functionality, utility, expedited delivery and flexible adjustments. And that’s where we can make use of selected technologies that can be used in a multi-platform setting. Of course, assuming we adhere to certain rules.​<br></p><p>At Cleverlance, we found success with three approaches to implementation. To put it in really simple terms, right from the very beginning we need to decide whether there’s a robust back-end with a MOA (<a href="https://en.wikipedia.org/wiki/Microservices">Microservice Oriented Architecture</a>) is available or whether we’d need to create one, and then whether the app will need a lot of business logic or rather will be just a presentation layer. In this case, it is good to use <a href="https://flutter.dev/">Flutter</a>. If we need the app to include synchronization queues, business logic and we’re implementing some kind of complexity and not just forms, we had good experiences with <a href="https://kotlinlang.org/docs/multiplatform.html">Kotlin Multiplatform</a>. And then there’s a third option = PWA (<a href="https://en.wikipedia.org/wiki/Progressive_web_application">Progressive Web Applications​</a>), which makes use of the strong foundation provided by modern browsers.<br></p><h2>Flutter​<br></h2><p>We consider Flutter to really be a multi-channel display layer which allows us to create not just mobile but also web and desktop apps. It’s a flexible solution that allows us to efficiently design B2B, and under certain conditions even B2C apps. One example here is the mobile app for BMW. But if we don’t want to deal with problems, it’s better to rely on the back-end and push all the “thinking” there.​<br></p><h2>Kotlin Multiplatform</h2><p>Kotlin Multiplatform is another option. Its advantage is that it allows you program a native app for Android, and then use a part of it for iOS. This usually applies to business logics and the integration layer, which leads to significant time savings in the QA phase later. The visualization layer is programmed natively for iOS and Android, meaning that one can have the “look & feel” of the platform while making use of just one code base for the part of the application that is not visible for users. For some projects, this allows up to 70-80% of the code to be reused.<br></p><h2>PWA</h2><p>​Progressive Web Applications is one of the latest trends in the area of web application development. To a certain extent, these shatter the boundaries between web and native mobile apps thanks to the ability to work offline, access a device’s hardware and even handle push notifications. They represent a combination of the best of both worlds; we are only limited by the capabilities of web browsers. This opens up a wide range of functionalities; for instance, the use of a phone’s camera or fingerprint reader are among the most basic ones. A request for using deeper device functions can be efficiently handled via a native “envelope” that can make them available. PWA apps can be distributed via all major app stores (Google Play, Apple Store, Huawei AppGallery as well as Microsoft Store) and can run on all Android, iOS and Windows devices.<br></p><h2>Where was this used?</h2><p>As a supplier, we of course want to offer not just standard technologies but also the “new” ones, and that was another reason we were happy to see customers approach us who right from the very beginning wanted a solution based on Kotlin Multiplatform. As an example, we can mention the U.S. based Globstar for which we, as part of the Aricoma Group, deliver mobile apps used to configure and manage modems for satellite internet connections. The use of Kotlin Multiplatform really paid off in this case, because the app was highly demanding as far as data transmission and integration were concerned. Integration additionally takes place via a BLE (Bluetooth Low Energy) interface, which can service dozens of devices simultaneously to, e.g., update their firmware. The technology was not only convincing for the customer, but also for us as the supplier; when developing the app we established a well-working business partnership.<br></p><p>We made successful use of PWA technology for instance in the online self-service app for SAZKAmobile customers. Its main advantage is an extremely short Time-To-Market (i.e., the time required to introduce new functions to the market) and a wide range of developers who already know the technology. In addition, PWA is best applied in areas without a large emphasis on using the device’s components, for instance in internal company apps for employees in the field or in production.​<br></p><div><p>If you’re interested in the technical details, feel free to read <a href="https://www.mobileit.cz/Blog/Pages/kotlin-multiplatform-first-year.aspx">this article</a> on our mobile it blog; it’ll <a href="https://www.mobileit.cz/Blog/Pages/choosing-mobile-app-technology.aspx">tell you ​</a>what to pay attention to when choosing the right technology for developing a mobile app.<br></p></div>

Cleverlance provides comprehensive IT services and end-to-end solutions.

We handle requests from their conception all the way through to analysis, design, development and launch, including project management, security, support or full outsourcing across a wide spectrum of industries.

  • Analysis
  • SW Architecture
  • UX Design
  • Software Development
  • ICT Security
  • Integration
  • Quality Assurance
  • Deployment
  • Support & Maintenance

Whether you prefer remote workers or onsite staff you can meet in person, you will find everything you need here.

Reach out to us. We’d love to hear from you.

 

ARICOMA