During many years of being an outsourcing provider, we’ve explored every work approach. In the 2000s, the “waterfall model” was popular. Many big corporations used it for building products, and so did we. With the waterfall approach, we planned the entire life of a project, wrote down the milestones, and set the final goal: MVP or release. Our milestones were strict and very time-specific: for example, the first milestone is April 22, the second — June 11, the third — August 1, and so on, where everything is planned ahead. However, this can be a challenge if there is no definite scope of work, or if unexpected problems appear.
The waterfall model was effective only when the project was simple and clear and we didn’t have to worry about any unforeseen nuances or new features. These cases are rare, though. Usually, our clients come to us with just a concept, which we then develop a perfect solution for that requires multiple iterations. This is known as the “iterative approach”.
The iterative approach is based on the idea that the human learning process is iterative and consists of numerous cycles of trial, error, and analysis. In software development, this concept works as follows: the project management process is divided into phases (iterations), each with its own cycle of “trials”, “errors”, and “analyses”. If we’re working with an existing product, the end of each iteration could be a new version release. Along with iterative, you also have incremental development, whereby the project is divided into smaller chunks and each one is handled separately.
At its essence, the iterative approach is a practice of continuously building and improving a product. As opposed to non-iterative models, where the final product is the end-goal, the iterative process focuses on the needed results – for example, excellent user feedback. Until the feedback is excellent, the iterative work continues, with the team improving the product with each iteration while maintaining strong performance.
The iterative model is the foundation of the famous “Agile methodologies”.
Agile is a project management framework. The need for Agile methods emerged with the realization that the market is very dynamic, and products need to rapidly adapt while maintaining their focus on the end-user. Agile has its own Manifesto, which contains its principles: teamwork, quality product, customer collaboration, flexibility, and fast response. These principles promote continuous development of the product.
Within the Agile framework there are several important “sub-methods”, including Scrum, XP (Extreme Programming), and Kanban. Let’s take a look at each.
Scrum allows a business to iteratively build separate parts of a product (by “product”, we mean something valuable to the business that solves specific problems) and test them on the market, gathering early feedback and thereby minimizing the risk of releasing unnecessary functionalities. As a result, the company is able to create a better product and achieve its business goals faster.
Unlike Scrum, which immediately defines the rules of the process, the Kanban technique fits into any existing process and can be used not only for uncertain tasks but also for well-defined ones. The main tool used is a “Kanban board”, which depicts all the stages of project development. The board has columns such as “queue”, “selected”, “analysis”, “testing”, and so on. The idea behind the board is to help visualize the processes of the work: how it is going, according to what rules, what tasks are being performed, which ones are stalled, and which ones require response from other departments.
A big advantage of these Agile methods is that they are strict yet adaptable. This means that the “containers” are rigid but the “content” can be anything at all. This makes the Agile approach suitable for projects in all kinds of industries, technologies, and with different goals, and so we try to apply it to as many clients as possible.
Agile is not about “getting it done and meeting deadlines”. Instead, it is about working under conditions of uncertainty, where the results are hard to estimate. For example, if you are creating a new product and do not yet know what it will look like in the end, Agile lets you move forward via small iterations and quick experiments, making informed development decisions based on the data you acquire from the market and users along the way.
Here’s another scenario: let's say you already have a working product but want to improve its conversion (i.e., the number of clicks) from cart to checkout. The answer is not obvious, which means that the task will most likely not be solved with a head-on approach. Experiments are required, and so the team’s work process is divided into iterations/sprints. During each iteration, the team must create a finished piece of the product which can then be shown to users and other stakeholders to get feedback. The team determines in advance the criteria for product readiness, and so everyone clearly understands what needs to be done in order for the product to be considered finished.
Whenever Sibers starts a new project, we estimate the scope of work. This is useful for both us and the client, since it provides everyone with a clear understanding of how much time is needed and how much money will likely be spent. Once the scope of work is estimated, we commence with creating a vision of the project and planning the first iterations.
As experts in the realm of outsourcing, Sibers believes that iterative development is the most universal, risk-free work approach, and suitable for almost any kind of project (except for when a “custom remote team approach” is a better fit).
Iterative development is especially useful for:
Sibers’ Project Managers recommend iterative development because it adds an invaluable flavor of flexibility to the development process. Additionally, iterations promote risk reduction while helping deliver high-value functionality to the user early on in the lifecycle. In fact, the iterative model encourages change through a feedback loop. At the end of each iteration, each piece of functionality is shared with the stakeholders/users so that they can sample it and provide feedback. This is in contrast with non-iterative models that seek to prevent changes, which in turn increases the risk that the finished product will fail to meet the user’s expectations.
Looking for a development team to work on agile principles?
Request a quote