Many developers perceive Agile as a stand-alone methodology (framework) for working on projects. In reality, Agile is more of a philosophy, a common approach that unites a whole group of agile methodologies (Scrum, Lean, Kanban and others).
In addition, methodologies can be non-agile. For example, Waterfall. The best practices for project management can be found in our Top 10 list.
Let’s focus on a different question — what are the steps in the agile project development cycle?
About the principles of Agile
As mentioned above, Agile is not a methodology, it is a paradigm or a general model. Therefore, it does not have specific steps or detailed documentation. It is a set of principles, of which there are only 12, and they were approved in 2001 by a group of independent developers.
The official version of the principles can be found at agilemanifesto.org.
- The highest priority is to satisfy the customer.
- Welcome changing requirements, even late in development.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Only motivated professionals should work on the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity – the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The key ideas of the Agile manifesto:
- The most important thing in a project is people and their interaction.
- The main goal is a working product, not detailed documentation.
- Readiness to change always comes first.
- Direct co-operation with the customer is more important than detailed agreements or contracts.
If you look at these principles from the outside, you can easily trace the presence of key management functions: planning, communication, project control (in the case of Agile methods it turns out to be end-to-end and continuous due to the presence of a customer representative in the team), performance analysis and process optimisation.
Many of these principles can be interpreted in different ways, with different technical details and peculiarities. This is probably why there are so many Agile methodologies and frameworks.
Agile methodologies (agile project management methodologies)
Let’s look at binding to cycles in the most popular Agile methodologies.
Kanban and project development cycles
The following principles are adhered to: leadership should be encouraged; all participants agree that the project will constantly evolve and improve; new cycles should start from what is currently available (as a variant of sequential project development); processes, roles and responsibilities should be respected.
Many people like the Kanban approach because of the simple and clear visualisation of tasks, it is a so-called Kanban board, which is divided into column-states. Tasks move sequentially from one state to another until they are completed.
Technical features related to development cycles:
- Iterations in Kanban are optional.
- Planning rates and cycles can be set based on tasks and other circumstances.
- There is no rigid attachment to release cycles or fixed development cycles.
- However, the minimum cycle time (development iterations) is a basic metric to estimate the total time spent on a project.
- KPIs and any estimates at all are optional.
- There are no clear requirements for development priorities.
- New requirements can be put forward by the customer at any time.
- All tasks (backlog) can be put on the Kanban board at once and their statuses can be tracked throughout the life of the product.
- There are no rules for the volume or complexity of tasks.
While there are no explicit requirements for the cyclicality of meetings and other internal activities, many Kanban teams develop their own private practices:
- Standard progress meetings are held daily, usually at the beginning of the working day. You can define your cycle and combine it with a schedule that is convenient for the client or customer representatives, e.g. once a week.
- Operations reviews (continuous improvement meetings) are held as needed, for example, when problems or best practices are identified, when projects are completed, or after important functions have been implemented. But you can set your own frequency — fortnightly or monthly.
- Problem analyses (identifying the causes of downtime) are done continuously. According to the principles of the Kanban approach, there is no room on the board for solving problems, there is only room for tasks. Therefore, downtime is quickly identified and eliminated just as quickly — as needed.
Scrum and development cycles
Scrum adheres to firm cycles in project work, here they are called sprints. This is also an agile methodology, but with detailed documentation and principles. Please note that if you use a similar approach in your work, but have changed something in it to suit your needs, it can no longer be called Scrum, these are the rules of the developers of the standard.
As with the Kanban approach, Scrum control is continuous through collaboration and discussions with customer representatives.
The project backlog can be general (list of customer’s wishes or tasks) and only for one sprint.
As for the technical nuances of Scrum development cycles:
- Iterations are always of standard (same) duration. It is set at the start of the project in agreement with the client and all team members.
- Metrics (KPIs or analogues) are always used to evaluate the project progress.
- Each sprint has a specific goal and objectives. These cannot be changed before the end of the sprint, only in a new iteration (new sprint).
- The requirements for the tasks are such that the scope of work must necessarily fit within the time frame of one sprint.
- The roles of the team members (scrum master, product owner and other team members) are strictly defined.
- Sprint backlogs are only valid for each individual sprint. After the end of a sprint its log is deleted. Only the general backlog of the project can be called cross-cutting.
- Each backlog item must be prioritised.
Now let’s talk about the development steps.
Agile development cycles and steps
Agile project development cycles do not and cannot have specific steps. Here we use such a concept as events. For example, a planning event that precedes the development stage inside a sprint in the Scrum approach. Daily Scrum meetings are also events.
In SCRUM the order of events is strictly defined. They must occur in the following sequence (within one sprint):
- Sprint Planning.
- Daily Scrum — a daily 15-minute meeting before you start working on the tasks in the sprint backlog.
- Sprint Review — the penultimate event of the sprint, needed to inspect the results.
- Sprint Retrospective — An analysis event, the last event of the sprint.
The Kanban approach uses meetings as events. But the essence does not change. There are no specific development steps in agile methods. Nevertheless, no one prevents you from combining the sequential development model with any agile approach.
What it might look like.
- Since any software product or project has its own life cycle, you can use the principles of the sequential development model (Waterfall): gathering and systematisation of product requirements, analytics, architecture (design), code implementation, testing, implementation.
- In order not to spread your energies in all directions and to realise all tasks at once, it is logical to start with a minimum viable product (MVP). The list of functions and tasks should include only those items without which the product simply cannot work.
- When the MVP is realised, you have something to give to the customer for implementation. Now you can switch to Agile methodologies. For example, Scrum.
- Next, a general backlog of tasks to be implemented is compiled, and the highest-priority features are assigned to each new sprint.
- The customer representative actively participates in the events and can update the list of project tasks before each new iteration.
