Agile Programming

Module Tutor/s: Godwin Ogbuabor, Dili Ojukwu

Module Number: SWE6202

Osman Bob Kamara HE19347 SWE6202

Table of Contents
Executive Summary ............................................................................................................... 2
Introduction ........................................................................................................................... 2
Overview of Agile & Conventional Methodologies .................................................................... 2
Agile Methodologies ............................................................................................................... 2
Conventional (Plan-Driven) Methodologies ............................................................................. 2
Comparative Analysis ............................................................................................................ 2
Project Planning and Flexibility ............................................................................................... 2
Client Collaboration and Stakeholder Management ................................................................ 3
Testing and Quality Assurance ............................................................................................... 3
Advantages and Challenges of each Methodologies ............................................................. 3-4
Recommendations for Client Contexts .................................................................................. 4
Future of Software Engineering Methodologies ........................................................... 4
Conclusions .......................................................................................................................... 5
Event Mate Agile MVP Case Study ........................................................................................... 5
Testing and Quality Assurance ............................................................................................... 5
Individual Reflective Statement .............................................................................................. 6
References ........................................................................................................................... 6
Appendix ............................................................................................................................... 6

1
Osman Bob Kamara HE19347 SWE6202

1. Executive Summary
This report gives a critical analysis, by comparing Agile and conventional software
engineering methodologies. The report shows each of their philosophical foundations
and Relevant practices, and also evaluates their suitability across project contexts.
This analysis is formed around planning flexibility, stakeholder collaboration, and
quality assurance. This report is tailored for government systems, start-up
applications, and public sector software.

2. Introduction
A software development approach demonstrates a very crucial role in acquiring the
proposed outcome of a system. Agile and conventional methodology are two opposite
software engineering paradigms. This report aims is to crucially asses these two
methodologies by investigating their core principles, inspecting and comparing their
performance on how well they function across important project aspects, and also
suggesting a suitable application situation.

3. An overview of Agile and Conventional/traditional Methodologies

a. Agile Methodologies
Agile is a gradual iterative methodology that prioritises adaptability, client
cooperation, and speedy delivery, with an agile team delivering working progress
simultaneously in small but potential increments or additional features to the
overall development. It is based on the Agile manifesto in 2001, which mainly
emphasises on responding to gradual change by following a precise plan. Agile
encourages flexible plannings, progressive growth, and early or initial delivery,
instead of the final software development.
Agile well-known frameworks are SCRUM, KANBAN, AND EXTREME PROGRAMMING (XP).

b. Conventional/Traditional (Plan-Driven) Methodologies.

It Approaches Traditional methods, like the Waterfall model, which are sequential
and linear, it usually consisting of stages such as the requirements collection,
the design, implementation, testing, deployment, and the maintenance
(Royce, 1970). These work well for projects with consistent requirements because
they are mainly relying on formal documentation, upfront planning, and clearly
defined deliverables.

4. Comparative Analysis:
a. Flexibility and Project Planning:
• Through brief iterations or sprints, agile enables dynamic reprioritisation of
work, facilitating quick adaptation to shifting requirements (Highsmith, 2009).

• Conventional or traditional models, on the other hand, demand comprehensive

specifications up front, resulting in strict plans that are very challenging to
modify designs, or making any updates during mid-development.

2
Osman Bob Kamara HE19347 SWE6202

b. Stakeholder management and client collaboration:

• Agile ensures alignment with possible expectations by promoting ongoing
client involvement through sprint reviews, backlog grooming, and product
demos (Schwaber & Sutherland, 2020).

• While traditional approaches run the risk of misalignment because they

frequently involve little stakeholder engagement after the requirements
phase.

c. Quality Assurance and Testing:

• Agile encourages for an early bug detection by incorporating testing into all
stages of the lifecycle (continuous integration, test-driven development)
(Crispin & Gregory, 2009).
• However, in Conventional Testing is pushed back by conventional methods,
which can result in high defect costs if problems are found later.

5. Benefits and Difficulties of Every Approach

Agile Benefits:
• Quicker feedback loops
• A higher level of client satisfaction
• Agile simultaneously deliver small and useful results early and most often
• Based on real-world or client feedbacks, Agile continuously learning and gradually improving its
development.
• Agile mainly prioritises people(client) and collaborations(team-work), which makes it more
reliable and secured in term of errors or bug fixings.

Agile Difficulties:
• Scaling is challenging in Agile for big projects, as Agile works in small teams, but it can be difficult
to manage when trying to scale to multiple teams or department.
• It demands a high level of client availability, in order to run the whole software operations
smoothly, with client availability and collaborations, there is an assurance of little or no bugs or
errors of the final proposed software development.
• Team dependency and skill requirements This is one of the difficulties in Agile methodologies, as
Agile requires a high degree of self-management, A cross-functional skills among the team, and
consistent communication between team members.

Traditional Benefits:
• This clearly defined project scope and requirements: Here all functional and non-functional
requirements are defined upfront, minimizing any ambiguity.
• Predictable budget and Timeline: Here a fixed planning phases makes it easier to estimate
the total costs and delivery timetables, which is useful in contractual agreement between
the client and the developers.
• Formal Documentation: With the use of a comprehensive documentations in traditional
methodologies, it facilitates a long-term maintenance, regulatory compliance and project
handover.
3
Osman Bob Kamara HE19347 SWE6202

• A Stable Team Roles and Workflow: In huge or distributed teams, clear roles and
sequential workflows helps to avoid confusion.

Traditional Difficulties:
• It has a Low capacity for change adaptation, which is a huge problem in the future of the
entire development. Once requirements are established, changes in the middle of the
project are very expensive and challenging.
• High Requirement Risk Misalignment: Prolonged intervals between obtaining requirements
and delivering finished goods may cause them to no longer satisfy the client needs.
• Delayed Feedback Loops: It's common for stakeholders to see a functional product only in
the final stages, which limits their ability to influence development.
• Heavy Documentation Overhead: Keeping up-to-date documentation can be time-
consuming and take resources away from real development.
• Bugs discovered in the last stages of testing may necessitate extensive reworking of earlier
stages, which raises the cost of fixing them.

6. Examples of Cases:
• The FBI Sentinel Project improved responsiveness and delivery time by switching from
Waterfall to Agile (GAO, 2012).
• According to Greenhalgh et al. (2009), the UK NHS National Programme for IT suffered
from strict planning and inadequate stakeholder engagement under a conventional model.

7. Suggestions for Customer Situations

Government Systems: Because of stringent regulatory compliance, financial restraints, and
lengthy timelines, conventional approaches are best suited. To add some flexibility, a hybrid
model might be used.
Agile is better for start-up mobile applications because of the need for quick iterations,
customer feedback, and changing product-market fit.
Systems in the Public Sector: A hybrid strategy (like Disciplined Agile Delivery) can strike a
balance between responsiveness and control.

8. Future of Software Engineering Methodologies

As a two-person team, we investigated how Agile and Conventional approaches relate to

actual development workflows in addition to their theoretical distinctions. Our goal was to
determine which approaches are changing, merging, or being supplanted by hybrid
frameworks that better meet the demands of the rapidly changing industry.

9. Conclusion
Agile and Conventional methodologies serve distinct purposes depending on project
complexity, stakeholder needs, and regulatory environments.
4
Osman Bob Kamara HE19347 SWE6202

Agile is ideal for innovation-driven, dynamic contexts, while Conventional models suit
well-defined, high-stability projects. Successful software engineering in the future will
depend on selecting or tailoring methodologies to project-specific needs, often through
hybrid models.

10. Case Study of Event Mate Agile MVP

a. Choosing an Agile Framework

Because of its defined roles (Product Owner, Scrum Master, Development Team),
structured sprint cycles, and emphasis on iterative delivery, our team has decided to
implement Scrum. This structure matched Event Mate development eight-week schedule
and changing needs.

b. Planning and Performing Sprints

Four 2-week sprints were going to be used to deliver the MVP, with each sprint
concentrating on finishing user stories from the backlog that had been prioritised. To
monitor progress and address obstacles, daily stand-ups were held.

c. Product Prioritisation and Backlog

In Scrum, the product backlog is the central repository for all features, enhancements,
bug fixes, and technical tasks that will be implemented.
Backlog items for Event Mate were written as user stories to prioritise end-user value
(for example, "As an attendee, I want to RSVP so I can confirm my attendance"). These
items were prioritised using the MoSCoW technique, which classified them as Must-
haves, Should-haves, Could-haves, and Won't-haves, to guarantee that the most valuable
features were delivered first within the 8-week MVP deadline. Client comments,
technological feasibility, and commercial impact were all taken into account while
prioritising.
d. Charts of Burndown To track sprint progress, burndown charts were kept up to date. As
our team adjusted, velocity increased throughout the sprints.
• Identification and Management of Key risks were monitored using an Agile Risk Board:
• Quick MVP implementation resulted in technical debt.
• The needs of clients are evolving.
• problems with third-party integration (like delayed email services).
• Early integration testing and the addition of buffer tasks were mitigation techniques.

e. Method of Testing
• Unit Testing: TDD was used for important backend components, such as RSVP logic.
• Acceptance Testing: BDD was applied to situations such as when an event is created
by a registered user, it shows up in their dashboard.
• At the conclusion of every sprint, exploratory testing is done to mimic actual user flows.

5
Osman Bob Kamara HE19347 SWE6202

f. Utilising Agile Artefacts

• Logs of Git commits demonstrating incremental delivery
• A Retrospective summary of sprints:
Sprint 1: "More accurate time estimation is required."
Sprint 2: "The RSVP system will be improved with the help of client feedback."
11. Individual-Reflective Statement
I coordinated sprint retrospectives and worked on backend development as a member of the
development team. I took part in sprint planning meetings and put the user registration logic into
practice.

Evaluation: As a team, we will be able to deliver a working MVP on schedule with the help of
Agile, and stakeholders, our team will be requiring regular feedback from clients, with our team
delivering an incremental release to our clients. For a startup with ambiguous and changing
requirements, the approach worked well.

References

1. Beck, K., et al. (2001). Manifesto for Agile Software Development.

2. Crispin, L., & Gregory, J. (2009). Agile Testing: A Practical Guide for Testers and
Agile Teams. Addison-Wesley.
3. GAO. (2012). FBI's Sentinel Project Transition to Agile Development. U.S.
Government Accountability Office.
4. Greenhalgh, T., et al. (2009). The Devil’s in the Detail: Final Report of the
Independent Evaluation of the Summary Care Record and Health Space
Programmes. University College London.
5. Highsmith, J. (2009). Agile Project Management: Creating Innovative Products.
Addison-Wesley.
6. Royce, W.W. (1970). Managing the Development of Large Software Systems.
Proceedings of IEEE WESCON.
7. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
8. VersionOne. (2020). 14th Annual State of Agile Report Available at:
https://www.stateofagile.com/

12. Appendix

• Appendix A: Summary of Agile vs. Conventional Characteristics Table

• Appendix B: Sample Agile Sprint Backlog
• Appendix C: Waterfall Project Timeline Example