What is Scrum Agile?
The term “Agility” defines project management principles that counteract more traditional paradigms, such as “Cycle V” or “Waterfall”, to think more about the “Product” rather than the “Project”.
The Scrum-Agile approach aims to reduce the tunnel effect by making project progress phases clearer and by involving the customer from the start of the project to adopt an iterative and incremental process.
In the “Agile” philosophy, we consider that need cannot be static and that, on the contrary, adaptation must be the keyword to be able to accept and integrate change to be able to offer an adequate response. But not without a few rules
The idea is to set an initial short-term goal and immediately begin developing.
Once the first goal has been achieved, a short break is taken and the roadmap is adapted according to the situation at that time, and so forth until the final destination is reached.
“Scrum-Agile” principles make it possible to define an organisational framework for work that is interesting for all participants. Effectively, the aim is not to tell scrum team members how to conceive things but rather to define an order in which to do them and leaving the initiative of innovation and creativity to each team member, within the limit of the project.
The “Scrum-Agile” principle is also about allowing interaction between individuals and enrichment by sharing experiences, thereby consolidating the notion of team spirit and mutual assistance which are essential to the success of a project.
Let’s discover together below the fundamental principles of Agility.
A. Team and Communication before tools
In the Agile vision, the team is more important than tools. It is better to have a cohesive team, the members of which communicate with each other, rather than experts working on their own.
B. The application / IoT/ Device before documentation
The project needs to work. This is the top priority.
Sometimes it is better to just develop and comment on the code itself and transfer all the skills and knowledge of the work to all the team members.
C. Cooperation before negotiation.
The customer must be involved in development.
The company must not simply negotiate a contract at the beginning of the project and then reject any change in the customer’s needs.
The customer needs to work with the team and provide regular reports on the adaptation of software to its expectations.
Scrum roles definition
- Scrum: Agile Project Management Methodology Framework.
- Scrum-Master: he ensures that the Scrum methodology framework is followed and that the AGILE process is implemented by the team.
- Product-Owner: Represents users and/or the customer and has the vision of the product to be developed under the project.
- Lead Developer: They supervise the development team, coordinate the Dev Team’s work, and verify that user stories are correctly processed.
- Dev Team: Term commonly used to refer to the team developing the product.
- Product Backlog / Backlog: Scheduled (prioritised) list of requirements (usually formulated as Story and / or User Story) for the project.
- EPIC: Notion of entire features or theme with an idea of production which is too vague in the medium-term (large user story).
- User story: Detailed definition of a task to carry out to achieve the result desired by the customer.
- Sprint: Short time interval (2 and 4 weeks max.) during which the team will design, develop, and test new features.
- Iteration Planning Meeting: Project kick-off meeting to develop a global vision of the project and determining the main lines (= Sprint 0).
- Poker Planning Meeting: Product Backlog collective estimation technique generally based on the “Story Point” unit.
- Daily Meeting or Daily Scrum: Daily meeting of no more than 15 minutes allowing the Dev Team to bring each other up to date, identify obstacles, and measure progress on the current iteration.
- End-of-Sprint Review or Retrospective Meeting: Meeting during which the work done by the entire team during the sprints is presented (debriefing of good and bad points, what was complicated or easy). How does Scrum-Agile work?
How does Scrum Agile work ?
There is an AGILE ceremony framework to give vision and rhythm to future deadlines.
This framework also gives visibility on the work done not only to the team but also and especially to the customer.
For this reason, the team working with Scrum Agile principles uses different working times, including “Sprints or iterations” which consist of “Poker Planning Meetings, “Daily Meetings“, “End-of-Sprint Reviews“, and finally “Retrospective Meetings“.
These are short periods of fixed time of between 2, 3, or 4 weeks during which a series of activities (analysis, ergo, design, coding, tests, etc.) are carried out, ending with an external or internal delivery.
Iterative principles refer to the fact that each delivery constitutes an increment, which will be supplemented, refined, modified, and enriched at the next iteration, resulting in the final product after a few weeks or months.
What are the ”User Stories”?
To make the members of a team working with Scrum Agile principles understand the goals to be achieved and the elements to be produced, they need to be broken down into subjects that can be addressed in stages which will be developed incrementally.
As such, it is important to reason in terms of scenarios to keep the project’s final goal in mind. In this way a more or less complex subject can be understood by all.
Each User Story must express the user’s point of view.
The way in which a User Story is written is therefore essential and must always be written from the user’s perspective.
The following format is generally used for this: “Role – Feature – Benefit”
This formulation balances subjects: not only about what the software / app / devices should do but also for whom and for what purpose.
Take the example of a project to build a bridge over a river. This project could be broken down as follows
EPIC (subject or theme): Measurements and dimensions.
- As a technician involved in building the bridge,
- I need to be able to measure the distance between the two banks in meters
- To be able to calculate how long the bridge needs to be.
EPIC (subject or theme): Choice of materials
- As an engineer who knows the constraints of materials,
- I need to be able to choose the right material to build the bridge in
- To have the best solidity possible based on its lenght and the elements.
Until achieving the final goal:
EPIC (subject or theme): Cross the bridge
- As a person driving a car and living in city “Z”
- I need to be able to safely cross bridge “Y’”
- To cross the river “X” and avoid having to drive an extra 20km.
Poker Planning Meeting
This ceremony allows User Stories to be presented to the Dev-Team team which will be asked to estimate the difficulty of development. This estimate is specific to the team. It is determined by a comparison:
the team chooses a representative user story, allocates a reference size to it (e.g. 1), and then estimates the other user stories based on this scale.
In order to avoid talking about cost and time when estimating story complexity, some people like to refer to this as “scaling”. To make things more interesting, we do not use a simple sequence, such as 1, 2, 3, 4, 5, etc. Instead, a modified form of the Fibonacci sequence is used, e.g. 1,2,3,5,8,13, etc.
Choosing between smaller or larger numbers allows us to better measure the difficulty.
If the numbers followed each other (1,2,3,4,5,6,7,8,9), it would be harder to estimate the level of difficulty.
Although this is not an exact science, it is more than enough for the three results mentioned above, and as John Maynard Keynes said, “it is better to be vaguely right than precisely wrong”. However, this means that we need to convert the story points into approximate time and cost.
Each developer has a deck of cards in their possession that contains a range of values between 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and 2 special cards (one with a Question Mark and the other with the infinity symbol). It is important that each developer shows their card at the same time for the sake of fairness so as not to influence other participants.
When estimates differ significantly (card of 2 and a card of 40), each developer needs to justify their estimate. As such, points of view are exchanged and a new estimate can be made.
In this way and depending on the ease or difficulty in which each point is dealt with, it will then be easier to prioritize and plan each User Story in the upcoming Sprint of your scrum agile project method.
Daily Meeting or Stand-up Meeting
This is a short daily meeting of up to 15 minutes to allow team members to bring each other up to date, report obstacles encountered, and measure the Sprint’s progress.
The Daily Scrum is held at a fixed time and place and everyone stays standing for it (to avoid it dragging out).
In this manner, the Scrum Master is immediately aware of any obstacles encountered. They must prioritize them, track them, and, of course, ensure that they are removed as quickly as possible to ensure that the team remains fully focused and productive.
It also helps create team spirit.
End-of Sprint Review
This event is used to inspect the items produced during the Sprint, review Release progress, and adapt the plan and Product Backlog as needed.
The development team presents the new features developed during the Sprint to the Product Owner / customer / end users.
The Product Owner gives feedback to the development team, accepting or rejecting the features presented. The calculated velocity will be used to update the Release progress status and verify that the number of Release Sprints is still appropriate or not. Delivery at the end of each Sprint is not mandatory.
This meeting is facilitated by the “Scrum Master” and is intended for their team. It aims to improve the team’s development process by coordinating everyone’s ideas.
This identifies the positive elements of the Sprint that has just ended, the elements to be improved, and, finally, results in an improvement action plan.
If the team members are comfortable about talking in front of each other, going round the table is enough, however, if this is not the case, post-its can be used (for team members to write their ideas on and then give them to the Scrum Master).
All areas can be retrospectively reviewed: human, organisational, practices, processes, tools, quality of life at work, conflicts, and dealings with the business.