Agile and Scrum in Ncoded Solutions #6

In the dynamic world of software development, adaptability, collaboration, and responsiveness to change are key to success. We are all witnesses of the rise of Agile development, since almost all projects today are based on it. Many tools are used to help manage and implement complex software solutions, breaking them into iterative segments.

You probably ask yourself why? 🧐 What is so special about Agile anyway? Do I have to use it to be a good developer?

Overall, Agile and Scrum have gained popularity because they offer a more effective, efficient, and customer-focused approach to software development, enabling teams to deliver value-driven solutions that meet the needs of today's dynamic and competitive markets.

At Ncoded Solutions, we've embraced Agile and Scrum methodologies as the foundation of our development approach, empowering our teams to deliver high-quality solutions that meet the needs of our clients and end users.

In this blog post, we'll take you behind the scenes to explore how Agile and Scrum simplify a complex development process.

Our dear Project Manager, Jelena Petrović, played a key role in shaping the insights shared here, drawing from her expertise and experience in Agile project management ✨

Agile Methodology

Agile Methodology is a flexible and iterative approach to software development that prioritizes adaptability, collaboration, and customer satisfaction. It focuses on delivering value in short, incremental cycles, allowing teams to respond quickly to changing requirements and feedback.

The Agile Manifesto is a foundational document that articulates the core values and principles of Agile software development. The document now consists of 4 key values and 12 principles.

There are more than a few Agile frameworks, but the most commonly used one is Scrum framework.

Scrum

Scrum is a lightweight Agile framework for software development that provides a structured approach to project management. It defines:

• roles: Scrum Master, Product Owner and Developer
• events: Sprint, Sprint Planning, Daily Stand-ups, Sprint Reviews, Retrospectives
• artifacts: Product Backlog, Sprint Backlog, Increment

All of this is used to guide teams through the development process in short, iterative cycles called Sprints.

Key 4 values of Agile

The Agile Manifesto outlines four key values that guide Agile development practices:

1. Individuals and Interactions over Processes and Tools: It emphasizes the importance of communication, collaboration, and teamwork within development teams. By prioritizing human interactions, Agile fosters a culture of transparency, trust, and empathy.

2. Working Software over Comprehensive Documentation: While documentation is important, Agile encourages us to focus on creating functional software that can be tested and validated by stakeholders. This value emphasizes the importance of delivering value early and continuously throughout the development process.

3. Customer Collaboration over Contract Negotiation: Agile emphasizes the importance of collaborating with customers and stakeholders throughout the development process. By involving customers in the planning, feedback, and validation of the product, Agile ensures that the end result meets their needs and expectations. This collaborative approach fosters a deeper understanding of customer requirements and enables teams to respond quickly to changes in priorities or preferences.

4. Responding to Change over Following a Plan: Agile embraces change as a natural part of the development process. Instead of rigidly sticking to a fixed plan, Agile teams are adaptive and responsive, embracing change to deliver better outcomes. In this way teams can deliver value more effectively and efficiently.

Key 12 Agile principles

Here are the 12 Agile principles as outlined in the Agile Manifesto:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

These Agile principles provide guidance and direction for Agile teams and organizations, helping us prioritize collaboration, flexibility, customer value, and continuous improvement in our development practices.

Scrum Roles

As already mentioned, Scrum framework requires 3 roles to be fully functional and bring the best of this framework. Every role in a Scrum team has a clearly defined set of responsibilities:

• Product Owner (PO) - represents the interests of stakeholders and is responsible for maximizing the value of the product. They prioritize the Product Backlog, define user stories, and make decisions about what features should be included in each sprint. The PO collaborates closely with the development team to ensure that the Product Backlog is refined, updated, and aligned with stakeholder needs.
• Scrum Master (SM) - a leader responsible for ensuring that the Scrum framework is understood and followed by the team. The Scrum Master helps the team maximize its efficiency, effectiveness, and self-organization.
• Cross-functional team - a team of people with a variety of expertise, usually comprising engineers, QA specialists and designers.

Scrum Events

In Scrum, there are five basic events:

1. The Sprint - This is the basis of Scrum. The Sprint is an iteration of project development. It usually lasts for [2 to 4 weeks] and developers are focused on completing their tasks within that time. During one Sprint other 4 events happen.

2. Sprint Planning - The first meeting at the start of each Sprint where the whole Scrum Team plans the work to be done during the sprint. The team selects items from the Product Backlog and creates a Sprint Backlog, which contains the tasks to be completed during the sprint. ⏳ It is usually the most time consuming and the most important event in Scrum framework, since achieving the right goal is determined by the quality of planning. It can last from [1.5 to 8 hours], depending on the complexity of requirements.

3. Daily Standup - A short, time-boxed meeting held every day during the Sprint where the Development Team discusses progress, plans for the day, and any impediments they are facing. The Daily Standup helps ensure transparency, communication, and alignment within the team. ⏳ It shouldn't last more than [15 minutes] no matter the size of team. Participants are developers and the Scrum Master.

The most common mistake inexperienced IT companies do is turning the Daily Standup meeting into a lengthy discussion forum. Instead of focusing on short updates and identifying any blockers, team members may go into detailed discussions about various issues and their solutions, resulting in an exhausting meeting for everyone involved.

4. Sprint Review (Demo): A meeting at the end of the Sprint where the Scrum team demonstrates the work completed during the Sprint to stakeholders and gathers feedback. The PO reviews the Increment and determines whether it meets the acceptance criteria. The team also discusses what went well, what didn't, and how they can improve in future sprints. As a result Product Backlog may be updated. ⏳ It usually takes from [1 to 4 hours], depending on the complexity of the work done and number of stories completed. The time for this meeting is determined by the team and developers are the ones in charge for this meeting.

5. Sprint Retrospective: A meeting held after the Sprint Review where the Scrum Team reflects on the sprint and identifies opportunities for improvement. The team discusses what went well, what could be improved, and any action items to address issues or make changes in the next sprint. ⏳ Usually, it lasts from [1 to 4 hours]. It is a time dedicated to development team, PO and Scrum Master to review their work, interactions, processes and tools implemented during the Sprint. Scrum Master makes sure that all participants are confident in sharing their problems and suggestions.

Scrum Artifacts

The term artifacts refers to documents that enable Scrum team to gain insights into the development process. There are 3 main artifacts in Scrum framework:

1. Product Backlog: A prioritized list of all desired work on the project that needs to be done to achieve the Product Goal, maintained by the Product Owner. It contains user stories, features, enhancements, bug fixes, and other requirements that need to be addressed. The Product Backlog is dynamic and evolves as new insights emerge or priorities change.

2. Sprint Backlog: A subset of the Product Backlog items selected for a specific Sprint, created during Sprint Planning. It contains the tasks, user stories, or backlog items that the Development team commits to completing within the sprint. The Sprint Backlog guides the team's work during the Sprint and is updated as progress is made or new information arises.

3. Increment: A concrete piece of work done to accomplish the Product Goal. It's the sum of all the completed and potentially shippable Product Backlog items at the end of a Sprint. To be considered as an Increment, the work must be useful to the stakeholder or user and meet the Definition of Done. It is demonstrated during the Sprint Review and forms the basis for feedback and future iterations. Every Sprint has at leas one Increment.

. . .

Well, this is a lot of rules and guidelines to follow up. Right?

🧐 Should we follow those Scrum rules strictly?

No necessarily, while Scrum and Agile offer robust frameworks for software development, many companies tailor them to suit their unique needs and preferences. These adaptations may involve modifying some practices, introducing additional processes, or combining elements from other methodologies.

By customizing Scrum and Agile, organizations can optimize their development processes to better align with their business goals, team dynamics and project requirements.

However, it's essential to maintain the core principles of Agile and Scrum, such as customer collaboration, iterative development and self-organizing teams, to ensure the continued success of their implementation.

Frequently used terms

• Epic - a large high-level requirement that can be broken down into smaller, more manageable pieces. It represents a significant feature or initiative that provides value to the user or business.

• User Story - a concise description of a feature from the perspective of an end-user. It captures who the user is, what they want to accomplish, and why. User Stories help teams understand and prioritize user needs and guide development efforts.

• Task - a specific unit of work that needs to be completed to fulfill a User Story or Epic. Tasks are smaller and actionable items that are typically assigned to individual team members. They represent the steps required to implement a User Story or address a specific aspect of the development process.

• Bug - an error, flaw or defect in the software that causes it to behave unexpectedly or not as intended. Bugs can arise from coding errors, logic mistakes or unexpected interactions between different parts of the system. Identifying and fixing bugs is an essential part of the software development process to ensure the quality and reliability of the final product. Most often, the bug is reported by the QA during testing.

• Story Points - unit of measure used in Agile to estimate the overall effort or complexity of User Stories. They are not based on time but rather on factors such as complexity, risk, and uncertainty. Story Points help teams prioritize and plan their work, allowing them to estimate how much effort will be required to complete a User Story compared to others.

• Acceptance Criteria - conditions or requirements that must be met for a User Story to be considered complete. It defines how a particular feature could be used from end-user's perspective. Its purpose is to help the team to understand what is functionally expected from certain requirement. The developed software must meet the actual business requirements. Acceptance Criteria is usually formed as a set of statements, each with a clear pass/fail result, defined for every User Story.

• Definition of Done (DoD) - a checklist of criteria or conditions that a User Story must meet to be considered complete and ready for release. It ensures that the work meets the required quality standards before it is delivered to customers or stakeholders.

Development Team Responsibilities

Besides attending required meetings, estimation, code implementation, testing, writing documentation and so on, developers should:

• ⏱️ log hours daily
• 🎟️ populate tickets
• 👉🏻 move tickets to appropriate stage

It may seem exhausting, but it's very important to log your hours because it has a huge impact on amount of work that has been completed, it improves client awareness, the value of the feature is clearer, the estimation accuracy improves and bottlenecks are identified easier.

When you finish your work on the ticket or you're facing some issues, your ticket should't be in the same stage for days. There is nothing wrong with having blockers or problems while developing, but your team needs to know what is going on. Maybe someone else from your team is depending on your work or someone should take over your ticket.

Moving tickets to appropriate stage and keeping the board up to date is extremely important for team awareness and coordination, effectiveness and avoiding confusion.