The Mighty Manifesto of Agile and its Methodology, Scrum

Photo by Jason Goodman on Unsplash

In this fast-paced life, where everything goes fast and rapidly, the requirements of the business environment are likely to change quickly as well. As that situation happens, the need for frameworks that could accomplish that situation has increased in software development cases. We could have used something other than the former software development approach to overcome that situation, which is a plan-driven approach. A plan-driven approach is suitable only if the requirements evolve until a requirements specification is produced, right before the implementation starts. While in that case, the requirements are likely to develop along the way of the implementation stages. Because of that, there was a new framework called Agile. Agile was born in the 1990s as a response to the traditional waterfall software development model.

So what precisely is agile? Let’s dive deep into it!

What is Agile?

ag·ile (/ˈajəl/) means able to move quickly and easily.

Agile is a way to manage a project by breaking it up into several phases. Agile is also defined as a software development framework that uses an iterative approach that helps developers deliver value to customers faster. The critical points of this framework are:

• An effective (rapid and adaptive) response to change.
• Effective communication among all stakeholders.
• Incremental delivery of software.

From those points, if we want to implement agile, we have to involve customers directly in our project so that everything satisfies them and meets their expectations.

The Agile Manifesto

The agile manifesto was developed in 2001 by a group of software developers that consists of 17 people, Kent Beck, and his friends. They were frustrated with the inefficiencies and inflexibilities of the traditional software development models, waterfall. These are the values of the agile manifesto:

1. Individuals and interactions over processes and tools
   One of the keys of agile methodology is effective communication between stakeholders. As development cycles go by iteratively for a certain amount of time, respect and trust between individuals are the most important thing to be kept. Processes and tools are also essential to note, but communications and interactions among individuals are more important to ensure that we will give value on each iteration.
2. Working software over comprehensive documentation
   Because the customer’s requirements might change unpredictably due to some factors, delivering the current working product to the client is essential to ensure it still meets the current client’s requirements. Hence, writing comprehensive documentation is less critical than outputting functional software.
3. Customer collaboration over contract negotiation
   There’s nothing permanent except change, and neither do the customer’s requirements. Customer’s requirements or needs must be changed as time goes by. We must involve customer collaboration in every project to cope with that situation. On each iteration, we have to ensure whether the output products on that iteration meet the requirements and needs. We also need to ensure that there are any additional requirements we must fulfill to meet their requirements in the following iterations. Because of that, we will more value customer collaboration than initial contract negotiation.
4. Responding to change over following a plan
   As requirements evolve along the way of the implementation, we need to be responsive to changes instead of following an initial plan to ensure that the value of each increment meets the customer’s requirements.

The Principles of Agile

These are the principles behind the four agile mighty manifesto above

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 behavior accordingly.

Types of System that Suitable for Agile Development

After noting agile’s manifesto and principles above, we can list all the systems suitable for agile development. Here it is:

• The product size is small or medium
• A system where there is a clear commitment from the customer to be actively involved in the development process
• A system where that are not a lot of external rules and regulations that affect the software

When do we need to use Agile?

Stacey Matrix (source)

There is standard matrix that used to recognizing the suitable methodology that we can use when implementing a software. It is called Stacey Matrix. The Stacey matrix is a tool used in strategic management and organizational theory to analyze the relationships and interactions between different variables within an organization. It was developed by Ralph Stace in the 1990s.

The stacey matrix categorize situations into four level based on their complexity. These levels are:

1. Simple: Simple levels are situation that there is a high level of certainty, and cause-and-effect relationships are clear and predictable. The problems and solutions are well understood, and there is little ambiguity. Simple situations typically involve routine tasks or well-established processes.
2. Complicated: In a complicated situation, there are multiple interrelated factors and variables to consider. Cause-and-effect relationships may not be immediately apparent, but they can be determined through analysis and expertise. Complicated situations require specialized knowledge and often involve experts or consultants to analyze and provide solutions.
3. Complex: Complex situations are characterized by high levels of uncertainty and unpredictability. Cause-and-effect relationships are not easily discernible and can only be understood in retrospect. Multiple factors interact in nonlinear ways, and there may be a lack of clear patterns or solutions. Complex situations require experimentation, adaptation, and learning through trial and error.
4. Chaotic: Chaotic situations involve extreme levels of uncertainty and unpredictability. There is no clear cause-and-effect relationship, and the situation may be rapidly changing or unstable. In chaotic situations, immediate action is necessary to regain control and stabilize the situation. Once stability is restored, the situation may transition to a different level in the Stacey Matrix.

Based on the Stacey matrix, we can implement Agile methodology if the situation we face is on the complex levels, which is when our requirements are complicated to complex, and changing through the process of implementation and the technology used in the project are also complicated.

Agile’s Methodologies or Frameworks

Several methodologies or frameworks implement agile. Some of them are:

1. Extreme Programming (XP)
   Extreme Programming (XP) is a software development methodology that emphasizes teamwork, communication, simplicity, and customer satisfaction. Like other types of agile frameworks, XP is also a customer-centric framework that focuses on delivering working software frequently and quickly adapting to changes in requirements. The unique part of XP compared to other frameworks is a pair programming concept. That practice is designed to improve the quality of the software being developed, increase productivity, and reduce the risk of errors or bugs in the code. XP has been used successfully in many software development projects, particularly those that involve complex and changing requirements.
2. Scrum
   Scrum is an agile development framework that emphasizes collaboration, flexibility, and iterative progress. The development process in scrum operates in time-boxed iterations, called sprint. The output value of scrum — the increment — is delivered to the customer at the end of each sprint. We’ll talk much about this in the following chapter.
3. Kanban
4. Feature Driven Development

There are a bunch of frameworks that implement Agile Methodology. At this time, we’ll talk about a scrum.

What is Scrum?

Scrum process (source)

Scrum, which Schwaber and Beedle proposed, is a type of software development framework with a set of best practices learned over the years. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Scrum also can be defined as a framework that generates value through adaptive solutions for complex problems.

Based on the definition above, there are three main points that scrum has to fulfill:

• Generate value
• Adaptive solutions
• Complex problems

Scrum is founded on empiricism and the lean thinking principle. Empiricism means that knowledge comes from the development process experience and making decisions based on what is observed. This principle asserts that scrum is a beginner-friendly method in which all of the stages of developers, junior-senior, and so forth, will have nothing to worries. The lean thinking principle, on the other hand, reduces waste and focuses on the essentials.

Scrum Pillars

Three pillars of scrum (source)

Scrum developed under the three pillars,

• Transparency

Significant aspects of the process and work must be visible to those responsible for the outcome, both those performing and receiving the result. There are three artifacts for Transparency, product backlog item (with story point), sprint backlog (with possible sub-task), and increment. Artifacts with low Transparency can lead to decisions that diminish their value and increase risk. Therefore, Transparency enables inspection. Inspection without Transparency is misleading and wasteful.

• Inspection

Scrum artifacts and the development progress must be inspected frequently to detect potential issues or variances. Adaptation is needed to occur if there are any issues regarding artifacts or progress. Because of that, Inspection enables adaptation. Inspection without adaptation is considered pointless.

• Adaptation

If the resulting product is unacceptable due to not meeting the client’s requirements, or any aspects of a process deviate outside acceptable limits, the materials being produced and the process being applied must be adjusted. Hence, a scrum team needs to be empowered. They are expected to adapt to any new knowledge through inspection.

Scrum Values

Scrum values (source)

There are five values that all of the stakeholders, especially the scrum team, should pay attention to:

• Commitment
• Focus
• Openness
• Respect
• Courage

Successful use of scrum depends on how effective and proficient people involved in scrum apply those values. Those values give the scrum team a north star regarding their work, behavior, and interaction with others. The combinations of scrum values and pillars will build a solid house of scrum framework that also creates trust among the teams.

Scrum Team

Enough for the values and fundamental definition of a scrum. Let’s move on and get to know anyone involved in the scrum!

The scrum team consists of Product Owner, Scrum Master, and Developers. Within it, there are no other sub-teams or hierarchies. Each of the scrum team members is self-managing, which means that they, itself, decide who does what, when, and how. It is also cross-functional, meaning the members have all the skills necessary to create value in each sprint. They are accountable for creating a valuable increment at the end of every sprint. Typically, the scrum team consists of 10 or fewer people.

• Product Owner

The product owner is accountable for maximizing the product’s value resulting from the scrum team’s work. As someone who represents the client’s interests, the product owner has to ensure the product backlog reflects the priorities and needs of the clients. In the scrum guide 2020, the product owner is accountable for the following:

1. Developing and explicitly communicating the product goal
2. Creating and clearly communicating product backlog items
3. Ordering product backlog items
4. Ensuring that the product backlog is transparent — as one of the pillars of scrum — , visible, and understood.

• Scrum Master

The scrum master is accountable for establishing scrum as defined in the scrum guide and ensuring all stakeholders understand scrum theory and practice. In short, these are the duties of a scrum master:

1. Organize scrum team
2. Manage scrum events
3. Assisting in the development of methods for efficient Product Goal definition and Product Backlog management
4. Planning and guiding Scrum implementations within the company
5. Removing barriers between stakeholders and Scrum Teams

• Developers

Developers are responsible for creating a usable increment or product on each sprint. These are the duties of the developers:

1. Planning the sprint (what will they do, what backlog that they want to choose)
2. Completing each backlog that they have chosen.
3. Modifying their plan every day to move toward the Sprint Goal
4. Adhering to a Definition of Done to ensure quality

Scrum Events

After we know scrum teams better, let’s get deeper into events that the scrum events hold during the development process.

• The Sprint

Sprints are the main and the most important event of the scrum. It has a fixed length, from 1 to 4 weeks long. In this event, the scrum team works to produce a valuable product that meets the client’s requirements. When the sprint has started, there shouldn’t be any changes that would endanger the sprint goal. If there are any updated requirements, all of that will be accomplished in the following sprint.

• Sprint Planning

Sprint planning is the initial event before the sprint starts. It is attended by all scrum teams, Product Owner, Scrum Master, and Developers. The customers or partners might also participate in it, but it is not mandatory. This sprint’s duration depends on how long the following sprint will be. Ideally, for a sprint that has one week long, the period of the sprint planning is 2 hours. For a sprint that will be held in 2 weeks, the duration of the sprint planning is 4 hours, and so forth. So ideally, the time of this event is sprint length*2 hours. Several activities held during this session are creating and determining the sprint goals, choosing the product backlog by the developer teams they want to implement, and breaking backlog into tasks that can be done within a day, or called sprint backlog. The value produced by this session is the sprint backlog defined from the product backlog.

In this PPL class, we held sprint planning together in class. Here’s a picture of it.

Sprint planning of PPL C class.

• Daily Scrum

The purpose of this session is to inspect each scrum team’s progress towards the goal, including analyzing and reporting issues they have encountered during the last work, adapting the sprint backlog as necessary, and adjusting the upcoming planned work. In short, here are the questions that are usually used in the daily scrum meeting, “What did you do since last scrum meeting?”, “Do you have any obstacle?”, and “What will do you do before next meeting?”.

In PPL class, my team and I have agreed to hold this event twice a week, Monday and Friday. Here’s the capture of the last session that we owned.

Daily Standup Kelompok 8 PPL-C

• Sprint Review

This event aims to inspect the outcome increment developed by the team during the sprint and determine future adaptations to accomplish the customer’s needs. Sprint review is timeboxed to a maximum of four hours for a one-month sprint. In this session, the scrum team presents the increments they accomplished from the sprint to the customer, and the customer responds with feedback on those increments. Hence, this session should be attended by the scrum teams and the customer as well. The Product Owner also reviewed the increments at these events and categorized them as accepted or rejected. If the Product Owner refuses the increments due to doesn’t meet the acceptance criteria, those increments will be adjusted in the following sprint.

• Sprint Retrospective

Sprint retrospective is the last scrum event that aims to evaluate the past scrum development process to increase quality and effectiveness in the next sprint. The scrum team discusses what went well during the sprint, what problems they encountered, and how those problems were (or were not) solved.

Scrum Artifacts

Scrum artifacts are the things that represent the work or value of the scrum and are designed to optimize one of the pillars of scrums, which is transparency. Each of the artifacts is committed to ensuring its focus and results can be measured.

• Product Backlog -> commitment: Product Goal

A product backlog is the list of everything needed to improve the product based on the client’s requirements.

The product goal is the scrum team’s long-term objective that must be fulfilled before taking another backlog.

• Sprint Backlog -> commitment: Sprint Goal

A sprint backlog is decomposed of product backlog that scrum teams should accomplish during a sprint.

The sprint goal is the objective that has to be fulfilled by the end of the sprint.

• Increment -> commitment: Definition of Done

An increment is a result developed by the scrum team during the sprint session. Work of the sprint can’t be considered part of an increment unless it meets the Definition of Done.

The Definition of Done is a formal description of the state of the increment when it meets the quality measures required for the product. An increment was born when a product backlog item meets the Definition of Done.

A case study on the Impact of Scrum and Overtime and Customer Satisfaction

According to Mann and Maurer (n.d.), in their case study on the impact of Scrum on overtime and customer satisfaction, the authors found out that scrum gives positive impact on reducing overtime and improving customer satisfaction. The authors examined both qualitative and quantitative aspects of the Scrum process. The case study was conducted over two years to get an understanding of long-term patterns and trends instead of seeing only short-term effects. Here are the results:

• Impact on Overtime

The qualitative results revealed that before the introduction of Scrum, the developers often had to work overtime to meet project deadlines. The software produced during this period was not always satisfactory, and there was a lack of customer involvement in the development process. The customers expressed dissatisfaction with the quality of the software and the limited decision-making power they had.

After the implementation of Scrum, the developers reported a positive impact on overtime. The structured nature of Scrum, with its emphasis on incremental development and timeboxing, helped in better time management and improved planning. The sprint planning meetings allowed the team to determine the scope of work for each sprint, enabling more realistic time estimates and work to be done. As a result, it reduces the need for excessive overtime, leading to a better work-life balance for the developers.

Quantitatively, the study examined the average number of overtime hours worked by the development team before and after the introduction of Scrum. The results showed a significant reduction in overtime hours post-Scrum implementation. This reduction indicated that the Scrum process effectively helped in managing workload and improving productivity, ultimately leading to a healthier work environment for the team.

• Impact on Customer Satisfaction

Qualitatively, the study found that customer satisfaction significantly improved after the adoption of Scrum. Prior to Scrum, the customers felt disconnected from the development process and had limited influence on decision-making. They expressed dissatisfaction with the software produced and experienced difficulties in visualizing the end product.

With the introduction of Scrum, the customers became more involved in the development process. The sprint planning, review, and retrospective meetings provided them with opportunities to collaborate closely with the development team. The customers appreciated the transparency, consistency, and coordination facilitated by Scrum. They mentioned that they were now able to visualize the product earlier in the process, provide timely feedback, and make more informed decisions. This increased involvement and communication improved customer satisfaction and led to a better understanding of the software’s functionalities and limitations.

While the study did not provide specific quantitative measures of customer satisfaction, the qualitative feedback from the customers indicated a positive shift in their perception of the software produced after Scrum implementation.

Overall, the case study by Mann and Maurer (n.d.) demonstrated the positive impact of Scrum on reducing overtime and improving customer satisfaction. The qualitative findings highlighted increased customer involvement, improved communication, and better decision-making processes. Additionally, the quantitative results showed a significant reduction in overtime hours, indicating improved productivity and a healthier work-life balance for the development team.

Critics of Scrum

Besides all of the positive impact and benefits of Scrum, there also several critics regarding to it. The critics often raise of the following corncern:

1. Overemphasis on Meetings: Scrum can result in excessive meetings, such as daily stand-ups, sprint planning, sprint reviews, and retrospectives. This can lead to a loss of productivity and frustration among team members.
2. Ignoring Qualitative Aspects: Scrum metrics often focus on quantitative measures such as velocity, burn-down charts, or defect counts. Critics argue that these metrics may overlook important qualitative aspects of the product, such as user satisfaction, usability, or innovation.
3. Overemphasis on Velocity: Velocity, which measures the amount of work a team can complete in a sprint, is a commonly used metric in Scrum. Excessive focus on velocity can lead to the team prioritizing speed over quality. This can result in rushed work, technical debt, and compromised product value.
4. Lack of Clear Documentation and Requirements: Scrum’s iterative approach may not suit projects that require detailed upfront documentation or have complex regulatory or compliance requirements. Critics argue that this lack of upfront clarity can lead to misunderstandings and difficulties in meeting project goals.

Conclusion

There’s nothing permanent except change, and neither do the Customer’s requirements. The Customer’s needs change rapidly and unpredictably due to some factors. Agile, a software development methodology, was developed to overcome that situation. With its manifesto and principles, Agile can cope with that issue by delivering quality products faster, enhancing customer satisfaction, and increasing team collaboration and communication.

One of the frameworks that implement Agile is Scrum. Scrum is an iterative framework founded on empiricism and the lean thinking principle that delivers values or increments at each sprint’s end. By adopting Agile principles and the Scrum framework, teams can enhance their productivity, efficiency, and customer satisfaction, ultimately leading to the success of their projects and their business to succeed in the fast-paced, ever-changing business environment.

References

Scrum Guide | Scrum Guides. (n.d.). Scrum Guide | Scrum Guides. https://scrumguides.org/scrum-guide.html

Lecture Week 2: Prescriptive vs Agile Process Models, Requirements Analysis [PowerPoint slides]. Universitas Indonesia. Software Engineering: https://scele.cs.ui.ac.id/mod/resource/view.php?id=121135

Lecture Week 1: The Foundation of Scrum [PowerPoint slides]. Universitas Indonesia. Software Engineering Project: https://scele.cs.ui.ac.id/mod/resource/view.php?id=121135

https://wiki.ppl.cs.ui.ac.id/

Drumond, C. (n.d.). Is the Agile Manifesto Still a Thing? | Atlassian. Atlassian. Retrieved March 8, 2023, from https://www.atlassian.com/agile/manifesto

Haekal, M. M. (2021, July 30). Apa Itu Agile? Pengertian, Prinsip, Metode, dan Kelebihan [Terlengkap]. Niagahoster Blog. Retrieved March 8, 2023, from https://www.niagahoster.co.id/blog/agile-adalah/

Mann, C., & Maurer, F. (n.d.). A case study on the impact of scrum on overtime and customer satisfaction. In Agile Development Conference (ADC’05). Retrieved from https://ieeexplore.ieee.org/document/1609806