The Agile methodology is an approach to the software development process that focuses on flexibility, collaboration and incremental delivery of working products. It was introduced to address the limitations of traditional software development methodologies, such as the Waterfall model, which often tend to be inflexible and poorly adaptable to change.

Here are some key concepts of the Agile methodology:

• Iteration and Augmentation: Instead of developing the software in one large iteration, the Agile approach involves dividing the work into small iterations, called ‘sprints’. Each sprint usually lasts one to four weeks and produces an increment of usable functionality.
• Prioritising customer needs: Agile places a strong emphasis on customer involvement throughout the development process. Customer needs and requirements are taken into account continuously and can be adapted during the project.
• Collaboration and communication: Agile promotes regular communication and collaboration between development team members, as well as with the customer. This means that team members work together to address challenges and make decisions.
• Self-organised teams: Agile teams are encouraged to be self-organised, which means that they are responsible for planning, executing and controlling their own work. This fosters an environment in which team members feel empowered and motivated.
• Adaptability to change: Agile recognises that requirements and priorities may change during the course of the project. Therefore, it is designed to be flexible and able to adapt to new information and requirements.

There are several specific methodologies within the Agile approach, including Scrum, Kanban, and XP (Extreme Programming), each with its own practices and tools. In this in-depth look at one of the most popular methodologies: Scrum. 

Agile methodology: SCRUM

The SCRUM methodology is a framework that is used by a team to manage complex projects in order to extract as much value as possible through iterative solutions.

The SCRUM pillars

Scrum is framed within the framework of agile methodologies and is based on flexibility in adopting changes and the cooperation of a group of people sharing their expertise. The strength of this methodology is its empirical approach: knowledge is derived from experience, so decisions are made from what has been observed.

The most important pillars and features of this methodology are :

• Transparency: the whole team involved is aware of the various stages of the project and what happens.
• Inspection: In order to make these elements transparent, progress towards agreed targets must be inspected and evaluated in order to detect undesirable problems.
• Adaptation: If and when there is something to change, the materials produced must be adapted and the whole team adapted to achieve the Sprint objective.

Before going on to define what Sprint is, it is necessary to provide an explanation of the three most important figures of the SCRUM method:

1. The Product Owner is responsible for maximising the value of the product by defining and prioritising the functionalities to be developed, and works closely with the Scrum team and stakeholders to ensure that the product meets the users’ needs.
2. The Scrum Master is in charge of making SCRUM theory and practices understood by all.
3. The SCRUM Team consists of a Scrum Master, a Product Owner and the Devolopers (those who are in charge of creating any aspect of a usable increment at each Sprint). It is a cohesive unit of professionals who evaluate the activities of the Product backlog without any outside influence. Their common thread is shared responsibility.

The stages of the SCRUM process.

Let’s talk about Sprint (Iteration) again. It is the beating heart of SCRUM because everything that happens to give value, happens within a Sprint. The maximum duration is one month as having longer Sprints can result in the loss of valuable customer feedback.

The next phase is Sprint planning, which kicks off the Sprint by setting the work to be done. The whole team must have a goal (the Sprint Goal) and must work together to define its value and/or increase it through discussion.

The purpose of the Daily SCRUM is to inspect the progress towards the Sprint Goal and to adapt the Sprint backlog as needed. It is a meeting that lasts a maximum of 15 minutes and must necessarily be attended by the developers of the Scrum team. The purpose is to improve communication and promote rapid decision-making, eliminating the need for further meetings.

The Sprint Review is the penultimate of the Sprint events and lasts a maximum of four hours for a one-month Sprint. Its purpose is to inspect what has been completed or changed in the context of the Sprint.

The Sprint Retrospective is the last phase of the SCRUM methodology and aims to plan ways to increase quality and effectiveness. It is a great opportunity for the SCRUM team to self-assess what improvements or problems have emerged and how they have or have not been solved.

SCRUM Artifacts

In the context of Scrum, artefacts are documents or objects that are used to facilitate the planning, communication and monitoring of work progress during the course of a project. There are three main artefacts in Scrum:

Product Backlog:

• Description: The Product Backlog is a prioritised list of all functionalities, features, updates and bug fixes that might be needed for a product. It is a kind of ‘queue’ of things to be done.
• Owner: The Product Owner is responsible for the Product Backlog. It is his task to prioritise items according to the value they bring to the customer.
• Priority criteria: Items higher up in the list have a higher priority and need to be better detailed. Items further down the list may be less well defined.
• Updating and Refining: The Product Backlog is continuously updated and refined in response to customer feedback and changes in product requirements.

Sprint Backlog:

• Description: The Sprint Backlog is a selection of items from the Product Backlog that the team commits to complete during a specific sprint. It contains only those items that the team believes can be completed within the duration of the sprint.
• Responsibility: The team is responsible for its own Sprint Backlog. The Product Owner can provide guidance, but the team is free to organise the work as it sees fit.
• Sprint Planning: The Sprint Backlog is created during sprint planning, which is an initial meeting in which the team selects items from the Product Backlog and determines how they will implement them.
• Daily update: During the sprint, the team holds daily Scrum meetings to update each other on the status of the work and to adapt the plan according to new information.

Increment:

• Description: The product enhancement is the result of sprint work. It is an evolution of the product that includes all functionalities completed and ready for delivery.
• Requirement: Each increment must meet the Definition of Done criteria defined by the team and accepted by the Product Owner.
• Presentation and review: At the end of each sprint, the team presents the product increment to the product owner and, if applicable, to the customer for feedback and acceptance.

These artefacts are fundamental to the functioning of Scrum, as they help to define, organise and track work during the development cycle. Each artefact has a specific role in the Scrum process and helps to maintain transparency and clarity in the work of the team.

In conclusion, it is necessary to emphasise how essential it is to clearly define the Scrum or Agile methodology in a written agreement as it provides a solid basis for the project success. A detailed contract establishes expectations, roles, responsibilities and delivery criteria, reducing ambiguities and conflicts. It also fosters collaboration and transparency between the parties involved, promoting a culture of continuous adaptation and improvement. This contractual approach creates an environment of trust and clarity, which is crucial to reaping the full benefits of agile methodologies, where flexibility and communication are central to success.

Basic Elements

What it means to be a start-up today is certainly a simple question, but one that needs a very articulate answer. 

It certainly does not mean having a lot of free time and sleeping soundly, and it certainly does not mean being relegated to unpleasant, underpaid work.

Doing start-ups today has undoubtedly become easier than yesterday, if by start-ups we mean that circle of entrepreneurial activities in their initial phase, whose social object is linked to the sphere of innovation; and, today, doing innovation is easier thanks to the proliferation of public funds, VCs and business angels. Unfortunately, in Italy, we are still a long way from solving the problem of access to credit for this type of entrepreneurship, partly due to the malpractice of some investors in asking little and expecting much (too much) from founders.

In addition to significantly improved access to credit, there has also been a small improvement in the supply of services for start-ups. This is due to the joint action of several incubators and private companies whose services have been improved and tailored to the specific needs of innovative entrepreneurship in its early years.

Beyond the ecosystem that only partly qualifies what it means to be a start-up today, these few lines are meant to give an answer to what are the basic elements needed to create the alchemy of a start-up, postponing in-depth studies on specific subjects related to this topic to other posts on this blog.

The idea

Certainly, in order to even remotely think about a start-up, it is necessary to have an idea. Having an idea does not mean having an intuition. An intuition is “a simple, instantaneous, synoptic cognitive act; it therefore designates a form of immediate knowledge, as opposed to any knowledge of a discursive nature”; whereas an idea is a much more complex term that must be declined within the sector it falls into and, in its broadest and most generic meaning, constitutes the representation of an object in the mind: the notion that the mind receives of a real or imaginary thing, the fruit of its own consciousness.

An idea is something more complex than intuition, it develops from it but constitutes a more evolved state where the intuition is filtered and elaborated on the basis of one’s knowledge and skills, coming out modified and, therefore, improved from its initial state.

Sometimes it is necessary to wait months before an intuition is transformed into an idea, as the elaboration process is repeated cyclically, sometimes enriching it with the contribution of the first embryonic elements of the ‘team’ that we will see later.

Skills

Needless to say, in order for the process of transforming an intuition into an idea to bear fruit, it is necessary to have the necessary skills for the sector one wishes to approach. It will almost certainly be necessary to go into the technical aspects of the chosen sector in greater depth, by virtue of any protocols specific to the topic one wishes to address, in order to prevent them from constituting an obstacle to the development of the business model.

Studying and working on the subject are certainly preliminaries to setting up a start-up, however, it is practically impossible to cover all the specific skills needed for each element related to the business model, and it is here that the need for the next fundamental element, the ‘team’, emerges.

The team

The team sees its value manifesting itself already in the very early stages of a start-up’s development but, in reality, it has only begun its relationship with the start-up because it will be instrumental in every single stage of its development.

Choosing team members is very difficult and there are various schools that more or less agree on the subject; we will therefore avoid going into too much detail by pausing only for a moment to mention one element without which, apart from schools, it is certainly not possible to form a team: trust.

Between team members, it is necessary to go beyond mere respect, there must be trust so that everyone is able to express their value to the fullest, individually and as a team member.

The team is the flywheel of the idea, it amplifies the scope of knowledge and expertise from which the idea is filtered, which emerges from this process greatly enriched and ready to be timetabled in its various stages of design and development, the roadmap.

The Roadmap

Fundamental from the very first moments following the definition of an idea is the creation of a checklist of actions necessary for the progression in the design and development of the idea and the scheduling of each action. 

The roadmap plays a pivotal role in relation to the distribution of the various actions, as it also constitutes a connecting element in the event that an action requires the intervention of different actors than originally planned or, in the event that several actions converge for a subsequent joint phase. Needless to say, it is necessary to respect the timeframes set in the roadmap and their eventual re-scheduling in the event of unforeseen and/or unexpected events.

It is easy to see how the roadmap is not a rigid document but, rather, an extremely fluid one that must be able to adapt to unforeseen events, slowdowns and pivots, right down to the various branches that the idea might take and that might not converge on a single business model.

Advisors

The last basic element in the creation of a start-up is the Advisors. Advisors have the function of guiding the action of the founders and that of the team in general; they differ from the latter in that their competences are fundamental but at the margins of the development of the core business; they constitute a conditio sine qua non for its setup but are extraneous to the process of providing the service or selling the good.

The rationale for the need for their presence is obvious, as are the immediate benefits that start-ups reap when they are able to include professional advisors in their network for each of the basic needs of a start-up: legal, fiscal, financial, project, technical.

Making start-ups today

To be able to do start-ups today, these elements are extremely crucial: The idea, The skills, The team, The roadmap and The advisors. Without these essential elements, it is difficult if not impossible under normal market conditions to make it through the initial stages that characterise the life of a start-up.

Once these elements have been aggregated, after taking the first steps in the development of the core business, it will be possible to proceed with a financing round of the start-up, i.e. its pre-seed. This eventuality is excluded in the event that the start-up plans to pursue the initial stages of design and development of the core business with its own economic means or through possible financiers who have entered at the only previous moment, i.e., those of validation of the idea.

The ethical issues arising from the use of data augmentation, or synthetic data generation, in the field of medicine are increasingly evident. This technique, which is also called synthetic data generation, is a process in which artificial data are created in order to enrich a starting data set or to overcome certain limitations. This type of technology is particularly used when AI models have to be trained for the recognition of rare diseases, on which there is little data available for training. By means of data augmentation, further data can be artificially added, while still remaining representative of the starting sample.  

From a technical point of view, data augmentation is performed using algorithms that modify existing data or generate new data based on existing data. For example, in the context of image processing, original images can be modified by rotating them, blurring them, adding noise or changing the contrast. In this way, different variants of an original image are obtained that can be used to train artificial intelligence models. The use of this technology makes it increasingly effective to use AI to recognise diseases, such as certain types of rare cancers.

However, there are several ethical issues that arise from the use of data augmentation in medicine. One of the main concerns relates to the quality of the data generated. If the source data are not representative of the population or if they contain errors or biases, the application of data augmentation could amplify these issues. For example, if the original dataset concerns only Caucasian white males, there is a risk that the data augmentation result will have a bias towards these individuals, transferring the inequalities present in the original data to the generated data.

Replication bias is certainly the most critical issue with regard to data augmentation. If the artificial intelligence model is trained on unrepresentatively generated data or data with inherent biases, the model itself may perpetuate these biases during the decision-making process. For this reason, in synthetic data generation, the quality of the source dataset is an even more critical issue than in artificial intelligence in general.

Data privacy is another issue to consider. The use of data augmentation requires access to sensitive patient data, which might include personal or confidential information. It is crucial to ensure that this data is adequately protected and only used for specific purposes. To address these concerns, solutions such as federated learning and multiparty computation have been proposed. These approaches make it possible to train artificial intelligence models without having to transfer sensitive data to a single location, thus protecting patients’ privacy.

Federated learning is an innovative approach to training artificial intelligence models that addresses data privacy issues. Instead of transferring sensitive data from individual users or devices to a central server, federated learning allows models to be trained directly on users’ devices.

The federated learning process works as follows: initially, a global model is created and distributed to all participating users’ devices. Subsequently, these devices train the model using their own local data without sharing it with the central server. During local training, the models on the devices are constantly updated and improved.

Then, instead of sending the raw data to the central server, only the updated model parameters are sent and aggregated into a new global model. This aggregation takes place in a secure and private manner, ensuring that personal data is not exposed or compromised.

Finally, it is important to note that there are many other ethical issues related to the use of data augmentation in medicine. For instance, there is a risk that synthetic data generation may lead to oversimplification of complex medical problems, ignoring the complexity of real-life situations. In the context of the future AI Act, and the European Commission’s ‘Ethics Guidelines for Trustworthy AI’, the analysis of technologies as complex, and with such a broad impact, as AI systems in support of medical decision-making is becoming increasingly crucial.

The Log4j Vulnerability and its Impact on Minecraft

Minecraft, the wildly popular sandbox video game created by Mojang Studios, has captivated millions of players worldwide with its limitless creativity and expansive virtual worlds. However, in late 2021, a vulnerability in a widely used logging library called Log4j threatened the game’s stability and, more alarmingly, the safety of the entire Internet. In this blog post, we’ll dive into the details of the Log4j vulnerability, explore how it affected Minecraft, and discuss the lessons learned from this cybersecurity crisis.

The Log4j Vulnerability: A Brief Overview

Log4j is an open-source Java-based logging utility developed by the Apache Software Foundation. It is widely used by developers to record system events and monitor software applications. In December 2021, a critical vulnerability known as Log4Shell (CVE-2021-44228) was discovered in Log4j. 

This vulnerability allowed attackers to remotely execute arbitrary code on the affected systems by merely sending a specially crafted string to the vulnerable application.

The severity of the Log4j vulnerability stemmed from its widespread use and the ease with which it could be exploited. Within days of its discovery, the vulnerability had been weaponized by malicious actors, leading to widespread attacks on various organizations, including government agencies and private businesses.

Minecraft and the Log4j Vulnerability

Minecraft, which runs on Java and utilizes Log4j for logging purposes, was one of the most high-profile targets of the Log4Shell vulnerability. As soon as the vulnerability was made public, hackers started targeting Minecraft servers, exploiting the Log4j flaw to execute malicious code, steal sensitive data, and disrupt server operations.

The situation was further complicated by the massive scale of Minecraft’s player base and the sheer number of community-hosted servers, many of which were run by hobbyists with limited cybersecurity knowledge. This made it challenging for Mojang Studios and the broader Minecraft community to respond quickly and effectively to the threat.

How Minecraft Responded to the Threat

Mojang Studios, the game’s developer, and Microsoft, its parent company, took immediate action to address the Log4j vulnerability. They released a series of patches for both the official game servers and the client-side software to mitigate the risk of exploitation. Additionally, they provided clear guidance to the community on how to update their servers and protect their users.

However, the response was not without its challenges. Due to the decentralized nature of Minecraft servers, many community-hosted servers were slow to apply patches, leaving them exposed to ongoing attacks. In some cases, attackers took advantage of this lag by creating fake patches laced with malware, further compounding the problem.

The Fallout and Lessons Learned

The Log4j vulnerability in Minecraft serves as a stark reminder of the potential consequences of a single software vulnerability in our interconnected digital world. Although there were no reports of widespread destruction resulting from the Log4j exploit in Minecraft, the incident highlighted the importance of robust cybersecurity practices in gaming and beyond.

Here are some key lessons we can take away from the Minecraft Log4j crisis:

1. Regularly update software and apply security patches: Ensuring that software is up to date with the latest security patches is critical in preventing vulnerabilities from being exploited. In the case of Minecraft, applying the official patches released by Mojang Studios would have prevented many of the issues faced by community-hosted servers.
2. Increase awareness of cybersecurity best practices: Many server administrators and users may not have been aware of the importance of applying patches or the potential dangers of downloading unofficial patches. Raising awareness of cybersecurity best practices can help mitigate the risks associated with incidents like the Log4j vulnerability.
3. Strengthen collaboration between developers and the community: The Minecraft Log4j incident underscored the need for better communication and collaboration between software developers, like Mojang Studios, and the broader user community. By fostering a strong relationship with users and encouraging feedback, developers can more effectively address security issues and provide timely support during crises.
4. Emphasize the importance of layered security: While addressing the Log4j vulnerability in Minecraft was crucial, it’s essential to remember that no single security measure is foolproof. Adopting a layered security approach, which combines various defensive measures, can help protect digital assets and systems against potential attacks.
5. Encourage open-source software audits: The Log4j vulnerability remained undetected for years, despite the library’s widespread use. Encouraging and funding regular audits of open-source software can help identify and remediate vulnerabilities before they can be exploited by malicious actors.
6. Foster a culture of responsible vulnerability disclosure: The timely public disclosure of the Log4j vulnerability by its discoverers allowed developers and organizations to take swift action in addressing the issue. Encouraging a culture of responsible vulnerability disclosure, where security researchers and organizations work together to remediate vulnerabilities before publicizing them, can help prevent the weaponization of such flaws.

Conclusion

The Log4j vulnerability in Minecraft demonstrated the profound impact that a single software flaw can have on the digital world. While the incident did not lead to the destruction of the Internet as we know it, it highlighted the importance of robust cybersecurity practices and the need for collaboration between developers, users, and the cybersecurity community. By learning from this experience and taking proactive steps to secure our digital assets, we can hope to mitigate the risks associated with future cybersecurity threats.