Our agile development
methodology
In traditional developments, when the requirements are not perfectly defined at a functional and technical level, projects are estimated with a certain margin of error, which is not desirable for several reasons:
- The probability of deviation in times and costs is very high.
- There is a high risk of overestimating or underestimating the Project, jeopardising the finances of the client or the consultancy.
- To fulfil the plan, the necessary flexibility to changes in requirements will not be maintained, which may lead to a final product that does not meet the requirements that the market needs to meet.
- A wear and tear on the team occurs due to constant discussions of scope, times and costs.
Therefore, in order to carry out a development that maintains flexibility in the requirements but without affecting the costs of the project beyond what is effectively necessary, we implement the following agile methodology, based on Scrum.
Project life cycle
Our goal is to deliver a quality product as soon as possible making an evolutionary development flexible to changes, so we use SCRUM implementing the process as follows:
The client, as the main reference and stakeholder, must provide the Product Owner, with all the necessary information (in the form of correctly defined user stories) so that we can transform those user stories into product backlogs that can be processed by the team, which are nothing other than the functionalities of the system to develop correctly defined. In case of not having such a definition level, we will provide support to the client to create the aforementioned technical backlog*.
* The “technical backlog” is not a SCRUM document itself, but an internal document of ours that provides the sufficient level of detail to define the architecture and the technical-functional scope of the product to be developed. The diagrams, structures or definitions it contains will depend on the nature of each particular system. The objective is not to serve as the final documentation of the project, but rather to provide a precise and sufficient technical definition to make an estimate with a low margin of deviation.
Each of these product backlogs will be transformed into sprint backlogs (specific functionalities to be developed in an iteration) in the Planning meeting, which takes place immediately before the start of each sprint. During that, the main stakeholder or customer reference, together with product owner and the scrum team, define what will be built in the next iteration. The iterations could be both weekly and biweekly, depending on various factors.
During that time, various activities are carried out daily in a cyclical and repetitive manner. One of the main ones consists of the process of refinement or Refinement meeting of the product backlogs so that they have all the necessary information so that the team can include it in the next sprint (not in the current sprint). In this ceremony the participation of the client is necessary.
An internal daily meeting is held. In order to provide transparency, we propose to the client to hold a weekly meeting to have a point of contact and progress control.
Each completed iteration produces a more refined deliverable than the previous iteration. This process is repeated until the agreed development is completed. In the Sprint Review, at the close of each sprint, that deliverable is presented to the client.
During the course of the project, the Agile.MyTaskPanel software is used as an online project management tool to provide visibility throughout its development cycle. A user will be given to the client so that they can follow the status of the project on a daily basis.
Payment method
Although, as a consultant, we cannot finance the development of the project, our intention is for the client to pay only for the work carried out. Therefore, we propose the following scheme.
At the beginning of the project, we will make a preliminary, high-level estimate of the project, in a range of man-hours. After the creation of the aforementioned technical backlog, we will confirm that preliminary estimate. In the event of a significant deviation in the previously estimated times, the client may decide whether or not to continue with the development of the project. You will only pay for the technical analysis carried out by our team.
Focused on achieving an agile work modality while maintaining flexibility to changes, we propose to plan and execute weekly or fortnightly iterations with specific objectives to be met. In the first iterations of each new project, the objectives will result in analysis, design and layout, later in the development and implementation of components. In this way, progress will be made in an agile development model, generating deliveries in each iteration, gradually getting closer to the desired final product.
A single monthly invoice will be issued for all the hours spent in the iterations closed in the month. As long as the scope does not vary, the total hours will never exceed the estimated total in each case and will always be proportional to the degree of progress made. In this way, only the work actually carried out can be paid and at the same time there will be a great control of the scope of the project, leaving it up to the client if they wanted to make more changes or not.
Index
Main features
Multidisciplinary and self-organized teams
Agile development
Increases team motivation
Client integrated in the team
Quick feedback of the product in development
Flexibility in incorporating changes
Reduction in the final delivery time of the project
Tell us your idea an we will prepare a proposal
Glossary of Terms and Good Practices
Although we do not intend to explain SCRUM in depth, much less, in this space we will clarify several points that will surely be of use or interest in case of working with our agile development teams.
Scrum definition
Scrum: It is a framework through which people can address complex adaptive problems, while efficiently and creatively delivering products with maximum value.
If you have conceptual doubts or want more information, I suggest going to https://www.scrum.org/ to solve them.
Agile Principles
We found it appropriate to include in this article what for us are the TOP 5 of the 12 Agile principles, so that our philosophy is better understood.
- Deliver Value Faster: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome Changes: Requirements changes are welcome, even at the end of the project. Agile processes take advantage of that change to generate a competitive advantage for the customer.
- Work Together Every Day: The product owner, the scrum master and the entire scrum team must work together daily throughout the project and with the same objective.
- Working Software is Key: Working software is the main measure of progress.
- Simplicity: The art of maximizing the amount of work not done is essential.
Key Roles
The following roles within our SCRUM implementation deserve to be clarified.
Product Owner
This is the person who knows the product, knows what it needs, what is really important and what is not. His key responsibility is to interpret the client (key functionalities, priorities, budget, market, deadlines, etc.) and transmit to the team what he wants to be built, providing all the necessary information to carry out the development.
Scrum Master
In addition to being a “facilitator” for SCRUM to be executed as it should be, he will be the main point of contact with the product owner to help him with whatever is necessary.
Artifacts
The following artifacts are the ones we consider that deserve a detailed explanation.
User Story
It is a very high level definition of a requirement. It must contain enough information so that developers can estimate the effort to implement it.
A good user story should consider the three "Ws" (who, what, why). That is, who will do something, what will they do and why. In addition, you must meet the INVEST criteria:
- Independent: the user story must be self-explanatory; it must not depend on other user stories.
- Negotiable: to avoid including too much detail, so that user stories are flexible and can be modified.
- Valuable: user stories should bring some value to the end user.
- Estimable: you must be able to estimate the resources needed to complete each user story.
- Scalable: make user stories simple, so they can be commissioned and prioritized.
- Testable: explain the verification and approval criteria, so that the team knows and applies them when a story is complete.
Checklist to accept a User Story
- Does the user story contain all three “Ws”?
- Does it meet INVEST criteria?
- Are the acceptance criteria clearly defined?
Example
It is a very simple case, but I think it clarifies the concepts explained above.
As a start-up founder, I want to be able to create an account on the XYZ site, so that I can join the community of investors and mentors.
Criteria of acceptance
- To be able to create an account manually (by completing the sign-up form)
- Create an account via Google
- Create an account via Facebook
Product Backlogs
It is nothing other than user stories transformed into a prioritized list of deliverables that must be implemented through the development process. A product backlog item (PBI) is a single item within that list. It must contain all the necessary information so that the team can eventually include it within an iteration (transformed into a sprint backlog).
It might at first seems like it is the same as a user story, but it is not. The latter goes beyond a particular change or requirement. It puts the user at the center and describes a feature of the system from his point of view.
Sprint Backlog
During the Planning meeting, the PBIs that will be part of the next sprint are selected and divided into one or more sprint backlog item (SBI). Being simplistic, it is nothing more than a PBI within a sprint. Actually, it’s a bit more, because that SBI needs to have a higher level of detail. Furthermore, one PBI can give rise to several different SBIs.
Ceremonies
They are nothing more than meetings with different participants and designed for very specific purposes. To be clear, not everything that takes place in these meetings will be discussed, but the purpose of the meetings will be made clear.
Planning
In this meeting, which occurs prior to the start of a sprint, the PBI that will be developed in it are selected and transformed into SBI.
Refinement
In this meeting, which takes place during the first days of the start of an iteration, the following PBIs to be developed in the next sprint (not the current one) are analysed and refined. That is, they are lowered to a sufficient level of detail in order to be developed later.
Daily
This daily meeting is made to see what was done the day before, what will be done on the current day and the impediments that may exist.
Review
In this meeting, which takes place after the completion of an iteration, the result of the iteration is presented to the client.
