Applying an Agile Model
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Software Engineer (agile-focused) | Work iteratively, seek frequent feedback, adapt plans based on real input, deliver working software early and often | Hide unfinished work, delay feedback, or claim agility without observable practice | Product teams using Scrum or lightweight Agile processes |
| Team Facilitator / Lead | Ensure feedback loops happen in person, document decisions, connect Agile values to daily technical work | Reduce Agile to ceremonies without substance | Sprint-based student teams, small product teams |
Affected SDLC Phases
If a team chooses this advanced topic, the planning, implementation, testing, and feedback phases are most strongly affected. Work is expected to evolve based on continuous feedback. Documentation and plans are living artifacts that change intentionally as new information emerges. Feedback must be obtained in person during class and documented (minutes or meeting memo). Retrofitting feedback after the fact is not acceptable.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined features in a lightweight, change-tolerant way and has explicitly stated which Agile Manifesto principles they apply and how these influence feature definition.
Technical Details
Before or during feature definition, the team must select at least 2 Agile Manifesto principles and document them in README.md.
For each selected principle, the team must explain:
- What the principle means in practice for them
- How it affects feature definition or technical decisions during their project
Feature descriptions may be brief, but must clearly express user value and allow change.
Quality
High-quality work shows clear understanding of Agile principles and concrete application at operational or technical level, not slogans.
Features are sorted by priority
Minimum Viable Product (MVP)
Your team prioritizes features based on current understanding of value and feedback, accepting that priorities may change.
Technical Details
Prioritization must be revisited at least once based on feedback received during the semester. Changes must be documented with rationale.
Quality
High-quality prioritization shows responsiveness to feedback rather than rigid adherence to an initial plan.
Features' cost and price are estimated
Minimum Viable Product (MVP)
Your team produces rough, revisable estimates and acknowledges uncertainty.
Technical Details
Estimates must be explicitly marked as tentative. When estimates change due to new information or feedback, this must be documented.
Quality
High-quality estimates are transparent about uncertainty and evolve based on experience.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working system and shows how feedback influenced what was built.
Technical Details
The demo must include:
- Working software
- At least one concrete change made as a result of tutor feedback
Feedback must be obtained by actively asking the tutor in person during class.
Quality
High-quality demos clearly connect feedback to visible system changes.
Bug fixing
Minimum Viable Product (MVP)
During development, your team reports and fixes one bug in an iterative, feedback-aware manner.
Technical Details
The bug report must include:
- When and how feedback was received (in-person discussion)
- How the fix was validated (demo, confirmation)
Trial-and-error is acceptable if learning is documented.
Quality
High-quality bug fixing shows learning loops and responsiveness, not just technical correction.
User documentation
Minimum Viable Product (MVP)
User documentation reflects the current state of the system and may evolve over time.
Technical Details
Changes to documentation due to feedback must be visible in version history.
Quality
High-quality documentation stays aligned with evolving software.
Developer documentation
Minimum Viable Product (MVP)
Developer documentation explains how Agile principles influenced technical structure and decisions.
Technical Details
Documentation must reference selected Agile Manifesto principles and concrete technical consequences.
Quality
High-quality documentation makes Agile practice visible in code and structure.