Agile & Scrum 101: Navigating the Challenges of Rapid Change in the Digital Age
Agile thinking is becoming more and more applicable to software engineers in this age of fast-paced living. Being able to deliver high-quality product output with restricted time, resources, and cost — often referred to as the Quality/Scope Triangle — is unquestionably necessary to be a software developer. What does Agile Development entail in the context of software development, then? How did Agile Development become so well-liked today?
Agile Development is one of the SDLC (Software Development Life Cycle) processes that is currently being used by software developers. In the process, Agile development is driven by the customer’s descriptions of the required scenarios, followed by short-term planning, iterative development with clear descriptions of activities and targets, producing usable product outputs, and adapting to changes. Finish!
Not yet.
Let’s go deeper into Agile Development. 🏃🏻♂️🚗💨
Based on the word Agility, which is an effective, quick, and change-adaptive quality. Kent Beck and 16 other software developers created the Agile Manifesto values in 2001. These are as follows:
Agile Manifestos:
- Individuals and interactions over processes and tools.
It emphasizes the importance of communication and teamwork in achieving goals over rigid adherence to processes and tools. - Working software over comprehensive documentation.
The values place a higher priority on producing usable software than on wasting time on document writing. Documentation is vital, but functional goods are more crucial. - Customer collaboration over contract negotiation.
It’s highlighting the significance of efficient coordination and collaboration closely with customers and all current stakeholders. - Responding to change over following a plan.
The necessity of adaptability and flexibility in handling changes that occur during development. Planning is a good thing in Agile development, but it must be flexible enough to modify if the original plan diverges from the project goals.
Fyuh..😮💨.
Interesting enough, right? Let’s move on.
It’s time to brush up on our knowledge of the 12 Agile Principles. Let’s begin!
The Agile Principles are, in brief, as follows:
- Customer involvement. Customers should be included in the development process at every stage, from planning to testing. This ensured that the finished product satisfies the client’s requirements and meets their expectations.
- Incremental delivery. It produces usable product output at each iteration. Prioritizing delivering software in small, incremental iterations rather than attempting to deliver a fully-featured product all at once. (Also, ensures that the product is constantly improving).
- People, not process. The development team is the most crucial component in delivering a successful product, and its abilities and knowledge should be fully utilized.
- Embrace change. This calls for adaptability, flexibility, and a desire to try new things and iterate.
- Maintain Simplicity. emphasizing simplicity in software development and design, to create the Minimal Viable Product (MVP) that satisfies user needs. (Avoiding needless complexity and emphasizing user experience and ease of use.)
12 Agile Principles:
1. Our highest priority is to satisfy the customer through the 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 for a 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.
Fyuh.. (2) 😮💨. A lot, huh?
Focus, and stay with me. Let’s go!
After understanding those principles, we recognize that the principles of Agile Methods encourage a cooperative, adaptable, and customer-centric approach to software development, placing a high priority on providing customers with value as quickly and effectively as possible while upholding strict standards of quality and simplification.
It should come as no surprise that many software developers and larger organizations prefer Agile development when working on projects.
Agile in Scrum Framework
We’ll talk about Scrum right now.
Have you heard that before? Scrum Framework?
In modern software development, Agile and Scrum are two concepts that are closely related. Agile approaches can be implemented using the Scrum framework. Agile is a method of developing software that emphasizes adaptability, teamwork, and customer happiness; Scrum is a particular set of procedures that aids teams in implementing agile.
See the difference and their correlation? Ok. Move on.
Scrum
Scrum is not just a methodology, but a popular framework. Ken Schwaber and Jeff Sutherland proposed and created the Scrum framework, which offers practices and guidelines that assist individuals, groups, and organizations in generating value by finding adaptable solutions to complex problems when working cooperatively and iteratively to create software products that satisfy client needs.
⚠️ Notes these 3 keys of Scrum definition: Generate value, Adaptive solutions, and Complex problem.
Click to Read: Scrum Guide 2020 by Ken Schwaber and Jeff Sutherland
Scrum is based on the principles of empiricism, which is a theory of knowledge that emphasizes the importance of experience, experimentation, and evidence in the process of learning and problem-solving. With empiricism, it helps teams to continuously improve and adapt their processes based on feedback and experience.
In brief, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat
At the core of Scrum are 3 key pillars that provide a solid foundation for successful implementation:
3 Key Pillars in Scrum
- Transparency. Artifacts on the project should be highly transparent and accessible to both individuals doing the work and those receiving it (all stakeholders involved). Low transparency in artifacts might result in choices that reduce value and raise the risk.
- Inspection. Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.
- Adaptation. Processes that wander too far from accepted parameters, or when the end product is subpar. It is necessary to modify the method being used or the materials being created. To reduce further sway, the correction must be made as quickly as feasible.
🔑 Keys to take:
Transparency enables Inspection → Inspection without Transparency is misleading and wasteful.
Inspection enables Adaptation → Inspection without Adaptation is considered pointless. Scrum events are designed to provoke change.
Adaptation becomes more difficult when the people involved are not empowered or self-managing.
5 Scrum (Important) Values
Besides its pillars, 5 Scrum values need to know:
1. Commitment. Team members commit to the project goals and complete the work required to achieve those goals.
2. Focus. Team members must be fully engaged and concentrated on the task and not get easily distracted by external factors so that the quality of work will maintain.
3. Openness. Team members must be open to feedback and have a willingness to listen to others. Actively seeking out feedback and not being defensive or closed off to criticism will create a culture of trust and collaboration.
4. Respect. Team members must treat each other respectfully, regardless of their roles and positions. It also means no hierarchy in the team.
5. Courage. Team members are willing to take risks, and challenges, also be brave to speak up for something wrong and against the goals.
Now you know more about Scrum pillars and Scrum values. Interesting, right?
Take your time and stay with me.
Next, we’re gonna seek out what is inside Scrum Framework. Go!
Scrum Event
Essentially, every Scrum event consists of applying the inspection and adaptation pillars’ values to the artifacts produced by the Scrum process. All of these actions, of course, are done promptly and are transparent.
1.The Sprint.
— Description: the main activity/heartbeats of Scrum that transforms needs and ideas into values within a certain period that is consistent. Carry out predictability by ensuring inspection and adaptation to achieve the product backlog
— Time/Duration: During the Scrum lifetime process/minimum 1-week length until 4 weeks(1-month length) → And the time is fixed to be consistent. The new sprint starts if the previous one is finished.
— Event:
1. Doing the Sprint cycle starts with Sprint Planning, Daily Scrum Meetings, Sprint Review, and Sprint Retrospective (discussed later in this article).
2. Develop a product to achieve the Sprint Goal and product goal that has been planned on Sprint Planning
3. Notes on development:
→ Don’t let any changes/development wander from the Sprint Goal.
→ Don’t let quality decrease
→ Adjust the product backlog as needed, also it can be negotiable
Implementation in PPL Class 2023, we held sprints which has 4-weeks or equals to 1-month length for each sprint, and in total, we should develop our project in 3-sprints.
Implementation in PPL C06 will be updated, soon. (We’re in progress right now..)
2. Sprint Planning
— Description: Planning activity to run a sprint.
— Time/Duration: The first day of the Sprint/maximum 8 hours for 1 month of sprint planning (shorter sprint, shorter sprint planning)
— Events:
1. Decide “why the Sprint is valuable?” → Produce Sprint Goal
2. Decide “what can be done?” → Selecting Product Backlog
3. Decide “how will the chosen work get done?” → Decompose selected product backlog into backlog items (smaller parts)
— Lead & Attended By:
1. Led by Scrum Master,
2. PO contributes, PO describes the product goal and answers questions from development teams about the execution and acceptance criteria of the product
3. Attended by all Scrum Team (Scrum Master, PO, Development Team)
4. Other people are optional (allowed to give feedback).
3. Daily Scrum Meeting/Daily Standup Meeting
— Description: Brief meeting was conducted to evaluate the daily work (mostly) of the scrum team to inspect progress against the sprint goals being faced and adaptive to the sprint backlog.
— Time/Duration: Ideally held every day (Monday to Friday) for 15 minutes.
— Events:
1. Brief discussed “what have you done today?”, “any obstacles in doing your tasks?”, and “what is your to-do tasks tomorrow?”
2. The goals is to improve communication, promote quick decision-making, and accordingly eliminate the need for other meetings.
— Lead & Attended By: Development Teams (If Scrum Master includes on develop the product, then Scrum Master involved).
In PPL 2023, we may held daily standup meetings for minimum twice in a week or 4 times in 1 sprint. The day to do daily standup meeting must be decided from beginning of the sprint and fixed for every week and also has 2 days gap between the daily standup meeting.
4. Sprint Review
— Description: Incremental inspection of sprint results carried out by the scrum team together with stakeholders to determine the process of future adaptation.
— Time/Duration: Each at the end of the sprint for maximum for 4 hours for 1 month of sprints.
— Events:
1. PO presents the product goal and current Sprint Goal, also the backlog items that were selected on this sprint
2. The Scrum Team presents the results of their work to the stakeholders and the progress toward the Product Goal is discussed
3. The Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment and discuss what to do next (adjust, et al)
— Lead & Attended By: Scrum Team (PO, Scrum Master, Development Team) + Stakeholders
Implementation in PPL Class 2023, we will have sprint reviews at the end of each sprint. Sprint review will be attended by Scrum Team (PO, Scrum Master, and Developers also the representative of organization’s stakeholder (representative of Universitas Teknokrat), our lecturer, and our teaching assistant.
Implementation in PPL C06 will be updated, soon.
5. Sprint Retrospective
— Description: Short meeting for a more relaxed review, to improve quality and effectiveness. Sprint Retrospective also as a closing agenda for each sprint.
— Time/Duration: Each at the end of the sprint for maximum for 3hours for 1 month of sprints.
— Events:
1. inspection of how the last sprint (in each individual opinion)
2. Inspection of the definition of done in the last sprint
3. Inspection of what should be stopped, started, and continued on the next sprint.
Implementation in PPL Class 2023, we will have sprint retrospective immediately after the sprint review session, it means also at the end of every sprint in PPL. Maybe we will use platform to sprint retrospective or maybe we just take a notes from it. It will be attended by all Scrum Team (PO, Scrum Master, Developers) and out teaching assistant.
Implementation in PPL C06 will be updated, soon.
Scrum Artifacts
1.Product Backlog. It’s a list of all the features, functions, and requirements of the product that want to produce. Product backlog must be transparent and in the future (Sprint Planning) will be decomposed into smaller items.
Product Goal:
Term to mention future state or long-term goal commitment of Scrum Team’s target that also listed in Product BacklogUser stories:
Description of feature from end user’s perspective to say “As a [user role], I want [goal] so that [reason]”.Tasks:
The specific action that needs to be taken to complete user stories to implement the feature.
2. Sprint Backlog. It’s a list of selected Product Backlog items for one Sprint consisting of Sprint Goals (why it’s valuable?), selected Backlog items (what?), and an actionable plan to deliver increment/backlog items (how?). This Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint to achieve the Sprint Goal.
Sprint Goal:
Description of goal for each Sprint. Sprint goal created during sprint planning and added to the sprint backlog.
In the implementation, each person in Development Teams should only take 1 Backlog item to do on Sprint. So, if there are any Backlog Items that have not been taken, it’s alright. After they finished with 1 backlog item, the developers can take the rest Backlog Items.
3. Increment. The number of Product Backlog items that can be completed in each Sprint and the total value of the increments in all previous Sprints. The increment is a concrete stepping stone toward the Product Goal.
Definition of Done & Acceptance Criteria:
Definition of when tasks are marked complete. Group of requirements for user stories that can be marked complete.
Role in Scrum/Scrum Team
The small team consists of 1 Scrum Master, 1 Product Owner, and Developers. No sub-teams or hierarchies. Typically 10 or fewer people in Scrum Team. Smaller teams communicate better and gain more productivity. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
- Product Owner (PO). PO is an individual (person, not team) who represents the needs of stakeholders in the product backlog and has a responsibility to maximize the value of the products created by the Scrum Team. The PO is willing to decide how to set the backlog’s priorities, prepare it, and inspect it during the incremental sprint review.
The following are the PO’s duties:
1. Manage the product backlog more efficiently.
2. Making and sharing product backlog items
3. Priority-ordering the backlog of products
4. Ensure that the complete product backlog is visible, transparent, and understandable.
2. Scrum Master. An individual who understands Scrum framework the most and acts as a leader who helps and guides Scrum teams and organizations go through the Scrum process.
The following are the Scrum Master’s duties (towards Developers):
1. Maintain the effectiveness of the scrum team (removing barriers and helping to focus on creating high value)
2. Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
3. Ensuring communication between the scrum team and stakeholders.Scrum Master’s duties (towards Product Owner/PO):
1. Help define product goals and effective product backlog management
2. Help the Scrum Team understand the needs/goals of product backlog items (brief and clear).Scrum Master’s duties (towards Organizations/Stakeholders):
1. Facilitating stakeholder collaboration upon request or need.
2. Lead, train, and mentor organizations in Scrum implementation to help plan and advise Scrum implementation within the organization and remove bottlenecks.
3. Development Team. People in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The following are the Development Team’s duties:
1. Creating a plan for the Sprint, the Sprint Backlog
2. Instilling quality by adhering to a Definition of Done
3. Adapting their plan each day toward the Sprint Goal
4. Holding each other accountable as professionals.
Stacey Matrix
The Stacey Matrix is a technique for implementing agile. The Stacey Matrix is a method for measuring project uncertainty. The uncertainty in question is confidence in our decisions or actions.
This graphic is an example of a Stacey Matrix, which is frequently used in agile methodologies. On the x- and y-axes, respectively, uncertainty is separated into two categories.
The required uncertainty is represented on the y-axis. Where we can evaluate whether a condition is clear or not in this part. We can also think about if there will be additional work to be done on these needs in this section.
Technology-related uncertainty is represented by uncertainty on the x-axis. We can gauge our level of skepticism towards the technology or method that will be applied to a project’s tasks in this area.
A Stacey matrix, meanwhile, divides the categories into four groups, namely:
- Simple Task
These are jobs that we can already be certain how to perform. Adding a button that, when clicked, displays the phrase of some words. - Complicated Task
In this case, the task already contains specifications, but we are still unsure of what those specifications are. In terms of technology, we are pretty accustomed to the tools that will be employed in this role. - Difficult Challenges
This is the case for the majority of software projects. when the initial requirements are unclear and the requirements themselves are subject to change. Also, the technology that will be deployed is unknown to us at this time. - Chaos Task
The hardest category in the Stacey matrix is this one. We know nothing about the specifications or the required technology in this category.
Expand Knowledge: Scrum for One
The Scrum framework is usually integrated into the methodology to assist in how well teams collaborate when developing software. Actually, the Scrum framework may be used to develop personal projects, but only after making some modifications to the main Scrum idea (which was previously discussed).
Agile methodology’s personal Scrum encourages individual productivity through observation, adaption, gradual elaboration, setting priorities, monitoring progress, and strict deadlines.
Dustin Wax, executive director at Burlesque Hall of Fame, found the term of “Scrum for One” as the principle for personal Scrum framework implementation for individual productivity. For Wax, the idea of Scrum is very applicable to our personal lives. The point that describes “Scrum for One” in are:
- Through a process of constant self-awareness,
- Identify what’s holding us back,
- How we can work around it, and
- Where the next few days or weeks should take us.
Wax wrote his opinion about Scrum individual methodology adaptation modified basic principles as below:
- Do What You Can with What You Have:
Wax suggest that we don’t need to wait until we have everything we need to start a project. Instead, we have to use what the resources that available surround us to start working on our project to achieve our goals. We can acquire additional resources or tools to help you along the way. - Constant Self-Reflection:
Wax recommends us to reflect on our progress regularly (the same value as daily scrum meetings in Scrum team framework) to reflect in which state are we and determine what things we need to do to move forward. Guess it’s still need the same question as daily scrum meeting that ask questions like “what I have done?”, “what tasks to-do”, “what’s the obstacle and what could I do better next week?”. By constantly reflecting on our progress, we can make adjustments to our approach and stay on track toward our goals. - Work Towards Clearly-defined, Short-term Goals:
Wax suggests to break-down every larger goals into smaller one and achievable tasks. The tasks should be clearly defined and focusing on achieving short-term goals. It helps to avoid overwhelmed and can make steady progress to the whole larger goals. - Plan and Work in Sprints
Using sprints is also recommended from Wax so we can work towards specific goals. It helps to maintain focus and work efficiently. These sprints should be short-term and should have clearly-defined goals.
Scrum Personal Level Implementation in Real-Life Example:
Mike Cohn, founder of Mountain Goat Software, tend to use Scrum at a personal level to make him stay highly productive. He shared his methodology to tend to work in one-week sprints and will start each sprint on Saturday or Sunday.
He agreed that scrum with personal level helps to focus with personal work, able to block out a number of hours every day and use them to focus strictly on one project — no distractions, no knocking off early, no nothing until he reaches his goal.
Mike uses an online task manager called “Things” to manage his to-do list and reviews it every weekend, tagging items with specific days of the week to manage his workload in a one-week sprint cycle.
While intended for big, collaborative projects, there were a lot of elements of Scrum that could be adapted pretty well to individual productivity.
Scrum is Effective, But, Is it Increase Customer Satisfaction?
Scrum framework as the methodology of Agile tends to be an effective methodology in software development because it allows for a flexible and iterative approach to development that emphasizes collaboration, transparency, and continuous improvement.
In the previous section, we discussed about the customer orientation and close collaboration. But is the effectiveness in Scrum methodology has significant effect to customer satisfaction?
The Impact of Scrum on Customer Satisfaction: An Empirical Study, a conference paper study produced by Bruno Cartaxo, et al., which includes a study of performance analysis of software development with adaptation of the Scrum approach for customer satisfaction analysis.
The study which used a cross-sectional survey and a sample size of 156 developers and 19 real-life software development, was done to assess numerous speculative factors of whether the adoption of Scrum has an effect on customer satisfaction.
The software development technique with Scrum (an agile method) and without Scrum (any traditional methodology) are the independent variables that are compared in this study model from the viewpoint of the clients. There are 7 hypotheses that are crucial components of customer happiness (the dependent variable) are chosen. The hypothesis are as follows:
- Time. Hypothesis 1: Scrum-based projects provide increased customer satisfaction from the time perspective
- Goals. Hypothesis 2: Scrum-based projects provide increased customer satisfaction from the goals perspective
- Quality. Hypothesis 3: Scrum-based projects provide increased customer satisfaction from the quality perspective.
- Communication and Transparency. Hypothesis 4: Scrum-based projects provide increased customer satisfaction from the communication and transparency perspective.
- Agility. Hypothesis 5: Scrum-based projects provide increased customer satisfaction from the agility perspective.
- Innovation. Hypothesis 6: Scrum-based projects provide increased customer satisfaction from the innovation perspective
- Benchmark. Hypothesis 7: Scrum-based projects provide increased customer satisfaction from the benchmark perspective.
The chart below, which shows the results of exploratory data analysis (EDA), lists the survey’s findings as follows:
- The projects using Scrum produced superior outcomes when time, communication and transparency and agility.
- The projects that did not use Scrum had superior outcomes in terms of quality, goals, innovation and benchmark aspects.
The preceding EDA results show that it is not possible to assume that either group (Scrum or Non-Scrum) has a clear advantage. According to early findings from the exploratory study, there were no changes in the data behavior for the two groups (Scrum and Non-Scrum), when taking into account various characteristics including central tendency, position, and dispersion. Additionally, due to the aforementioned results, there are no notable benefits.
Therefore, the study paper above indicates it was not possible to establish any evidence that using Scrum may help to achieve customer satisfaction and increase the success rates in software projects.
This has contrast opinion with Scrum’s advocates that make general claims about Scrum’s ability to increase success rates in software projects. In my opinion, there may be limitations to Scrum’s ability to increase success rates in software projects, and that these claims may not be entirely accurate or applicable in all situations.
Here, Let’s Sum Up!
In this age of fast-paced living, Agile methodology and Scrum Framework are widely adopted in software development since it’s very useful to deliver high-quality products rapidly.
The Agile Scrums, where Agile places a strong emphasis on cooperation, continuous delivery, and customer satisfaction, while Scrum Framework is structured well to approach Agile principles, including events, roles, and artifacts that let teams manage work efficiently.
Agile Scrums calls for a change in perspective when it comes to accepting change, appreciating feedback, and being receptive to customer needs. It increases the team culture of openness, transparency, and trust so that the team can exceed customer expectations while fostering innovation and continual improvement by implementing these techniques.
References
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
Cartaxo, B. (2013). The Impact of Scrum on Customer Satisfaction: An Empirical Study. In Research Gate. Retrieved April 14, 2023, from https://www.researchgate.net/publication/271430457_The_Impact_of_Scrum_on_Customer_Satisfaction_An_Empirical_Study.
