Agile, Scrum, Kanban and XP for digital project development

The success of a digital project may depend on the architectures used to develop it and the working method chosen.

When it comes to developing a digital project, as in any other field, it is crucial to choose a method and tools that are best suited to the objectives we pursue and the way we intend to achieve them. We have to determine how our workflow will unfold, how we want to create the final product, and how much flexibility to allow ourselves within this path.

‍Project control: planning and managing a project

Before starting work on a project, it is necessary to analyze it thoroughly in order to be able to determine how to approach the work. Project control consists precisely in determining to which type the incoming project belongs. We can mainly distinguish three types of project:

Defined project, when we already know the resources, the development time and the processes required to achieve the desired result: a good example would be an assembly line, which involves a standardized production process.
Empirical project, when we know at most one of the three variables – time, processes and resources to be employed – while the other two will have to be determined in the course of the project, as in the case of the development of a completely new software.
Statistical project, which concerns projects for which we know at least two variables between time, resources and processes because we have had experience of similar projects, which help us to make a realistic estimate of project development.

Each project brings with it different objectives and needs, but experience, as is often the case, is fundamental in transforming an empirical project into a definite one, as it allows us to go through a statistical phase thanks to the study of previous projects.

In addition, an Agile approach is of great help in optimizing costs and timescales and at the same time enhancing the creativity of those working on the project, because the Agile methodology favors teamwork, continuous collaboration and constant evolution, without imposing rigid stakes and deadlines fixed a priori.

Let’s look in more detail at the application of the Agile methodology.

‍The Agile world

The Agile methodology is based on flexibility and continuous and rapid deployment, as well as on a set of values that guide the way work proceeds. In other words, software and its modifications are delivered in small doses released within a short time frame in order to involve the customer at every stage of the project.

Furthermore, the Agile methodology uses teamwork as a tool for continuous improvement, preferring real-time communication to the production of extensive documentation. Changes can thus be integrated at any stage of the software life cycle.

The Agile manifesto

Established in 2001, the Agile manifesto today represents one of the most followed and effective models for managing digital transformation projects. Its fundamental principles are as follows:

Individuals and interactions rather than processes and tools.
Working software rather than exhaustive documentation.
Customer collaboration rather than contract negotiation.
Responding to change more than following a plan.

While valuing the items on the right, the items on the left are considered more important. It is therefore not just a method for developing sites and applications, but an all-round approach, covering both the practical aspects of software development and the ultimate goal of customer satisfaction.

Frequent and short delivery times guarantee greater flexibility and the possibility of perfectly shaping the project to the client’s requirements, which may evolve over time. However, the fact that needs may change does not mean starting from scratch every time; on the contrary, the customer’s needs are placed at the center and thoroughly understood to avoid wasting resources. In fact, one of the operative strategies of the Agile methodology is the so-called Lean Thinking, aimed at eliminating waste of time and resources, increasing process efficiency.

Lean Thinking

Derived from the Toyota production system, Lean Thinking is based on continuous improvement through the contribution of all people working on the project with a common goal.

All Lean methodologies aim to reduce or eliminate waste related to irregularities, overloads and activities with no added value (the Japanese terms “Muda, Mura, Muri” are used to indicate this waste). Determining whether or not a certain activity brings value to the project is therefore fundamental to making the best use of available resources. Lean Thinking is based on five fundamental principles:

Define value.
Identify the value stream.
Let the flow go by.
Let the customer drive the flow.
Strive for perfection.

Once the activities that bring value or are absolutely necessary for the development of the project have been identified, it is necessary to map the flow of these activities, with the aim of streamlining processes and identifying any waste. At this point, the project must go on in a continuous flow, smoothly and distributing the work among the various resources so that no bottlenecks are created. In addition, again with a view to avoiding waste, it is a good idea for the customer himself to make precise requests so that the project corresponds perfectly to his needs.

Push vs. Pull

As we have said, a Lean project starts with the customer’s requirements, to avoid wasting time and energy on activities that are not indispensable for the success of the project. This approach is known by the term “pull”, as opposed to a push approach in which one ‘pushes’ a particular solution because it is considered appropriate, regardless of the customer’s specific needs.

The pull approach focuses on communication, shared responsibility and collaboration with the customer: this allows time and resources to be optimized without having to make predictions that may turn out to be wrong. For it to work, the pull approach must necessarily be based on a constant flow of information exchanged with the client.

Iterative and incremental

In order to solve the customer’s problem as quickly and inexpensively as possible, the Agile methodology involves releasing a product in short, iterative work cycles, so that the project is built together with the customer, one iteration after another, constantly reassessing priorities and requirements. Each iteration is a self-contained phase, comprising analysis, design, implementation and testing.

Frequent feedback allows the project to be built incrementally, starting with a ‘base’ product that possesses the fundamental characteristics to meet the customer’s needs, and then improving it at each step, also to adapt to rapidly changing situations. The dialogue between the development team and the customer is continuous, thanks to the short work cycles.

In the Agile methodology, the software released in the first work cycles is already usable, but will be improved in subsequent cycles thanks to customer feedback.

Scrum: values, roles, artifacts and events

Scrum is an Agile work management framework designed for small teams that divide each project into portions to be completed within a certain time frame, called ‘sprints’, as per the Lean concept of process optimisation (Muri, Mura, Muda).

With Scrum, a large task is divided into sprints of 2-4 weeks in order to obtain feedback loops that are analysed to adapt and implement any changes. In simple terms, we could say that Scrum is a system that helps teams to work together: the Scrum framework encourages learning from previous experiences, organizing and analysing the results obtained in order to constantly improve.

This framework is based on 5 core values:

Commitment: each team member ensures that they are fully committed to the common goal.
Concentration: in order to work best, it is good to focus on a few elements at a time.
Openness: dialogue is essential to know what other team members are doing and what problems, if any, need to be solved together.
Respect: since it is a team work, it is essential to respect one’s teammates and one’s role within the team.
Courage: team work and the support of colleagues make it possible to face even the greatest challenges.

In the Scrum framework, the team manages itself: the so-called Scrum Team, within which there are no hierarchies, takes charge of every aspect of the project. Responsibilities are shared and everyone can make full use of his or her potential: this leads to greater involvement of all members, resulting in increased productivity and personal satisfaction.

However, there are also some fundamental roles within a Scrum Team:

Product Owner: his main responsibilities are to maximize the return on investment, define priorities and identify long-term goals, constantly interacting with the other team members.
Scrum Master: helping the team to effectively achieve the objectives, he is a facilitator. His main task is to remove obstacles that may compromise the success of the project.
Developer: he builds the product requested by the customer or the Product Owner (sometimes the two figures coincide).

A Scrum Team has all the skills necessary to complete the project: once the Product Owner has set out the priorities, the team establishes autonomously which activities to engage in and how to work towards the objective, also giving suggestions to the Product Owner himself in order to arrive together at the best possible product.

In order to visualize all the information useful for developing the project, the Scrum Team uses so-called ‘artifacts’: these are tools that provide in-depth data on the performance of each work phase. In particular, a distinction is made between:

Product Backlog: a list of priorities, functions, requirements or improvements needed to develop the product.
Sprint Backlog: a work plan comprising a set of tasks to be addressed in the next product increment.
Product increment: each sprint includes an increment, i.e. a product component that constitutes a recognisable value for the customer and is added to the previous increments.

For each artifact, there is then a commitment through which the team’s progress can be measured:

The Product Backlog commitment is the Product Goal, i.e. the future state of the product, a long-term goal.
The Sprint Backlog commitment is the Sprint Goal, i.e. why a given iteration adds value to the product, it is therefore a short-term goal.
The Increment commitment is the Definition of Done (DoD), which defines when the product is ready to be released to the customer.

Another fundamental aspect of Scrum are Events, meetings between team members with a defined duration and a clear objective. It is thanks to events that team members can regularly compare and evaluate what has been done so far in order to evolve or correct it. The main events are:

Sprint Planning: it opens each sprint and its objective is to decide what to do in the sprint that is starting, establishing what value will be added to the product and how to achieve it.
Daily Scrum: this is a short daily meeting of maximum 15 minutes, during which the developers assess where they stand with respect to the objective of the sprint and if necessary reschedule the work to be done (according to the inspect & adapt philosophy, i.e. study the current conditions and if necessary correct the course).
Sprint Review: in this phase the customer is shown what has been done and their feedback is solicited in order to evaluate the increase achieved and decide on the evolution of the product.
Sprint Retrospective: this is the event that closes a sprint; in this phase the product itself is not analyzed, but rather the working method, in order to define any opportunities for improvement. This is a fundamental tool for improving the effectiveness of the team’s actions and achieving the desired results.

When we talk about Scrum, we therefore mean a set of tools, roles and values that support the team in managing their work, and thanks to the short release cycles of the software it helps the team adapt to the constantly changing needs of customers.

‍Kanban

Some tools considered Agile predate the drafting of the methodology manifesto, but are still considered Agile because they respect its values: this is the case with Kanban, whose principles date back more than half a century. The inspiration always comes from Toyota and the Lean principles Muda, Mura, Muri: reduce excess without sacrificing productivity.

A Kanban team focuses exclusively on the work it is doing at the moment. Once one phase is completed, the team chooses the next: if the product owner reprioritizes, the work does not stop, because any change requests are only taken into account when the team is working on that specific phase. Kanban is a tool often used in various applications of the Agile methodology to visualize certain aspects of the work in progress.

The elements of the work are in fact visualized on the so-called Kanban board, so that team members can check the status of the work at any time, with the aim of optimizing the workflow. The virtual board, an indispensable part of this method, allows the traceability of each individual action, facilitates collaboration within the team and is accessible at any time from different locations. The simplest board consists of only three columns: to-do, in-progress and completed, but each team can create the scheme that best suits its needs.

Once the workflow is visualized on the Kanban cards, the board cards dedicated to each individual task, the Kanban team will aim to limit the amount of work in progress (WIP), concentrating only on the tasks that are currently needed. In this way, the pace of work is optimal, faster; it is also easier to identify any blockages in the process and there is no risk of exceeding the team’s work capacity.Using a tool such as Kanban within a working method that already includes Agile principles can be useful to manage the workflow in such a way that the process criteria are made explicit, so that all team members are aligned, since the success of each project is a joint responsibility.

‍Scrum vs. Kanban

Both Scrum and Kanban are used within the Agile methodology and both involve the division of work into smaller units, with the aim of optimizing processes and delivering the product as quickly as possible. Both are based on a pull logic, but they also have some substantial differences:

The Scrum Team is completely autonomous, it chooses how to develop the project and is committed to meeting deadlines; there are no tasks imposed ‘from above’ but there are very precise roles (Product Owner, Scrum Master and Developer), whereas in Kanban there are no defined roles a priori but the tasks are tackled in a precise order.
Scrum involves a series of successive sprints or iterations aimed at improving processes and their planning; in Kanban, on the other hand, the development process is continuous, although there is a limit of elements that can be included in each WIP.
Scrum is based on iterations of fixed duration: since the time is predetermined, in each sprint there may be a variable number of elements to complete; in Kanban, on the other hand, before moving on to the next task, one must have completed the current one, which may take more or less time.
With Scrum, the work board is reset at the end of each sprint; the Kanban board, on the other hand, is used continuously.

Every project is different, which is why there is no one approach that is clearly better than another: both Scrum and Kanban are useful tools for organizing work in an Agile manner.

‍XP: eXtreme Programming

Another Agile methodology for software development, which was very popular especially in the late 1990s and early 2000s, is Extreme Programming or XP: its objective is to improve code quality and increase productivity. Being an Agile methodology, it involves releasing software in short cycles and with frequent feedback. The term ‘extreme’ refers to the fact that this approach takes certain practices considered useful in software development.

The main values of this methodology are communication between all team members and the customer, simplicity (only the problem that has been posed needs to be solved; complications are to be avoided), verification (the code is tested from the beginning) and courage (if changes are necessary, they should be implemented without fear of changing course to achieve the goal).

XP includes a set of 12 practices for software development: let’s look at some of the most interesting ones:

Pair Programming: each workstation is occupied by two people, one in the role of ‘driver’, who physically writes the code, and the other in the role of ‘navigator’ or observer, who identifies any errors or problems. The two figures have the same skills and frequently exchange roles.
Test Driven Development: tests are written even before the development of the functional part begins, so that every last component of the software is checked before it is implemented.
Continuous Integration: continuous integration involves changes to the code being integrated very frequently in order to prevent future problems.
Refactoring: software undergoes continuous revision with the aim of making it as simple and clean as possible, without adding functionality that is not strictly necessary.

These and other extreme programming practices aim to respond quickly to change requests from the customer, releasing frequent product increments and aiming for simplicity.

In a team working with XP, all members of the development team have equal responsibility and set their own schedule. The link between the developers and the customer is the manager, who ensures that the established agreements are adhered to and that the discussion between the parties is constructive. Similar to the Scrum Master, the presence of a coach can be envisaged to facilitate compliance with XP practices within the group.

The XP also actively involves the customer at every stage of programming, which is why it requires considerable effort, but this methodology, if well applied, guarantees excellent results thanks to continuous testing and practices such as pair programming, which reduce the possibility of errors. In addition, its minimalist approach makes it possible to always have clear code and to make the necessary changes in good time, avoiding implementing unnecessary functionalities.

Scrum vs. XP

Extreme Programming predates Scrum, but both are Agile approaches based on short, incremental iterations, aiming at team autonomy and transparent communication.

Unlike Scrum, however, XP provides a set of well-defined practices for software development and thus has a more technical approach, whereas in Scrum it is the developers who choose, on a case-by-case basis, how to approach the work and which practices to use.

The emphasis in Scrum is therefore on self-organization, whereas in XP the team must comply with what is defined ‘from above’: whereas the Scrum Team identifies priorities together with the Product Owner (or customer), in extreme programming it is the customer who sets them and the team cannot question them.

On the other hand, XP admits that not all practices need to be adopted in every single project, whereas the Scrum approach is more rigid, iterations have a fixed duration, and the Scrum Master makes sure that everyone follows the same Scrum principles.

‍Each project its own method

In conclusion, within the Agile world, it is possible to choose different tools, frameworks and working methods depending on those that best suit the project at hand. However, it is essential that all team members work with the same values and do not create conflicts or misunderstandings that would jeopardize the success of the project.

The methods and frameworks to be applied when the objective is the digital transformation of a company therefore depend on the client’s needs, the type of project, the skills required and the team spirit involved, but also on previous experience if similar projects have already been undertaken.

If a company does not have the necessary knowledge to develop a digital project on its own, the ideal solution is to rely on a partner who can provide personalized advice on the best solution for each individual case: Hermes has the expertise to offer talents, teams and services to companies according to their needs and the project to be developed.