ALM PRELIM

Understanding Agile Methodologies

1. The Core Principles of Agile

• Individuals and interactions over processes and tools

  • People working together creatively solve problems better than relying solely on rigid processes or software.

    Analogy: Like friends working on a group project. Good communication and trust matter more than having fancy planners.

• Working software over comprehensive documentation

  • Deliver small, functional parts of the product instead of spending months writing exhaustive plans upfront.

    Analogy: Rather than talking about baking a cake for weeks, bake one layer, share it for feedback, and then bake more.

• Customer collaboration over contract negotiation

  • Regularly work with the customer to adjust the product to their needs, rather than sticking rigidly to an initial agreement.

    Analogy: A carpenter builds a custom chair, adjusting its size and design after frequent feedback from the customer.

• Responding to change over following a plan

  • Be open to change, even late in the project, if it improves the product.

    Analogy: Like rerouting your road trip because you found out about an exciting detour.

2. How Agile Works: The Iterative Process

Agile breaks work into smaller, manageable cycles called iterations or sprints (typically 1-4 weeks long). Each sprint includes the following steps:

• Planning

  • The team decides what to work on during the sprint based on priorities and customer feedback.

    Analogy: Imagine preparing a single meal for a restaurant menu instead of trying to cook the entire menu at once.

• Execution

  • The team builds a part of the product, focusing only on the tasks assigned for that sprint.

    Analogy: If you're painting a house, you only focus on one room this week.

• Review and Demo

  • At the end of the sprint, the team presents what they’ve created to stakeholders for feedback.

    Analogy: Like showing a partially assembled Lego structure to a friend to see if it’s shaping up as they imagined.

• Retrospective

• The team reflects on what went well, what didn’t, and how to improve in the next sprint.

  Analogy: After a meal service, a chef might evaluate what dishes were popular and which ones need tweaking.

• Repeat

  • Feedback is incorporated, and the process repeats with the next sprint.

1. Frameworks Under the Agile Umbrella

• Scrum

  • Focuses on roles like the Product Owner (decides priorities), Scrum Master (facilitator), and Development Team (builders).

  • Uses time-boxed sprints, daily stand-ups, and a sprint backlog to manage tasks.

  • Analogy: Like a rugby team (Scrum is a rugby term), where everyone works together in short, intense bursts to move the ball forward.

• Kanban

  • Visualizes work on a board with columns like "To Do," "In Progress," and "Done."

  • Encourages continuous flow without predefined sprints.

  • Analogy: Think of a bakery assembly line where you can see which pastries are being prepared, baked, or ready for sale.

• Extreme Programming (XP)

  • Focuses on engineering practices like pair programming, frequent releases, and test-driven development.

  • Analogy: Like mechanics working in pairs on a car, constantly testing each part as they build it.

2. Tools Used in Agile

• Jira, Trello, or Asana

  • Help teams manage tasks visually.

  • Analogy: Like pinning sticky notes on a board to track who’s doing what.

• Version Control Systems (like Git)

  • Allow multiple team members to work on the same codebase.

  • Analogy: Like editing a Google Doc together without overwriting each other’s changes.

• CI/CD Pipelines

  • Automate testing and deployment to deliver features faster.

  • Analogy: Like a self-cleaning coffee machine, which streamlines repetitive tasks.

3. Why Agile Works Well

• Flexibility

  • Agile welcomes changes at any stage of development.

  • Example: If a feature idea changes midway, Agile adapts rather than restarting.

• Customer Involvement

  • Frequent demos ensure customers see progress and can steer the project.

  • Example: A retailer asks for a new feature after seeing how the initial product works.

• Faster Delivery

  • Delivering smaller increments means users benefit from the product sooner.

  • Example: A mobile app releases its chat feature first, then adds photo-sharing later.

4. Challenges of Agile

• Needs Active Stakeholder Involvement

  • Requires consistent input from the customer.

• Harder to Predict

  • Because it’s flexible, estimating timelines and budgets can be tricky.

• Team Commitment

  • Works best when the team is highly collaborative and disciplined.

Scrum and Kanban

Scrum is like running a restaurant where every two weeks, you plan a special menu (Sprint) that your kitchen will focus on.

How Scrum Fits into ALM:

• Requirements Phase: Gather customer requests (Product Backlog).

• Development Phase: Work in focused Sprints to build features.

• Testing Phase: Test during and after each Sprint (continuous integration).

• Deployment Phase: Frequently release updates based on Sprint results.

• Maintenance: Feedback from each Sprint informs the next cycle.

Key Ingredients:

• Sprint (The Daily Special):

  • A time-boxed period (usually 2-4 weeks) where a specific set of dishes (tasks/features) are cooked.

  • Once the special menu is set, you don’t add new items until the next Sprint.

• Product Backlog (Recipe Book):

  • A list of all the dishes you could make in the future.

  • The Product Owner decides what goes into the backlog based on customer preferences.

• Sprint Planning (Menu Planning):

  • The team (kitchen staff) decides what dishes they’ll prepare for the next Sprint.

  • They consider the ingredients (resources) and the chef's availability (team capacity).

• Daily Stand-up (Morning Huddle):

  • A quick, daily check-in.

  • Each chef says:

    • What they cooked yesterday,

    • What they’re cooking today,

    • Any issues (like missing ingredients).

• Sprint Review (Tasting Session):

  • At the end of the Sprint, you serve the dishes to the customers (stakeholders) to get feedback.

• Sprint Retrospective (Kitchen Debrief):

  • The team reflects:

    • What went well?

    • What can be improved?

    • How to cook more efficiently next time?

Kanban is like running a buffet where dishes are continuously prepared based on demand, not fixed schedules.

How Kanban Fits into ALM:

• Requirements Phase: New features or bugs appear as new cards on the Kanban board.

• Development Phase: Developers pick tasks from the "To Do" list when they're ready.

• Testing & Deployment: As soon as a task is done, it moves to testing, then deployment—continuous delivery.

• Maintenance: Perfect for handling ongoing work like bug fixes or support tickets.

Key Ingredients of Kanban:

• Kanban Board (The Kitchen Order Board):

  • A visual board showing tasks in columns like:

    • To Do → In Progress → Done

  • Each card on the board represents a task (like an order slip).

• Work In Progress (WIP) Limits (Kitchen Capacity):

  • You limit how many dishes can be “In Progress” at once to prevent overload.

  • Imagine only allowing 5 orders on the stove at the same time—any more, and the kitchen gets chaotic.

• Continuous Flow (Orders Keep Coming):

  • Unlike Scrum, there are no Sprints.

  • As soon as a dish is done, you pull the next order.

  • It’s a constant flow, like in a busy diner where orders come in non-stop.

• Feedback Loops (Customer Reviews):

  • Regular check-ins to improve the process, but not tied to fixed timeframes like in Scrum.

• Scrum works well when:

  • You’re building new features with clear milestones.

  • The team thrives on structure and time-boxed goals.

• Kanban works well when:

  • You’re handling ongoing work like bug fixes or support tickets.

  • The work is unpredictable, and priorities shift frequently.

Application Life Cycle Introduction

1. Concept and Planning (Seed Stage)

• Requirement Gathering: What do users need? This involves discussing with stakeholders (customers, teams) to clarify the application's purpose and the features it should include.

• Feasibility Analysis:Can we do this with the time, budget, and resources we have?

• Choosing the Methodology:Selecting whether to use Agile, Waterfall, or DevOps as the guiding framework.

2. Development and Deployment (Growth Phase)

• Development: Writing code to implement features.

• Testing: Ensuring the application behaves as expected under different conditions.

• Deployment: Making the application available to users.

1. Operations and Maintenance (Sustaining and Retiring)

• Monitoring: Ensuring the application runs smoothly (like checking the tree for pests).

• Bug Fixes: Resolving issues that arise in real-world usage.

• Updates and Enhancements: Adding new features or improving existing ones.

• Decommissioning: When the application is no longer needed, it’s retired gracefully.

2. Key Features of ALM Methodologies

• Collaboration Tools: Tools like Jira or Azure DevOps help track progress and improve team communication.

• Automation: Testing, integration, and deployment often involve automation.

• Version Control: Systems like Git manage code changes.

• Feedback Loops: User feedback drives improvements.

3. How Methodologies Guide ALM

• Waterfall: Everything is planned upfront, so each phase depends on the previous one being completed.

• Agile: Encourages adaptability and user feedback to guide the process.

• DevOps: Bridges the gap between development and operations, emphasizing automation and continuous delivery.

Waterfall Application Development: A Deep Dive

The Waterfall model was first formally described by Winston W. Royce in a 1970 paper, ironically as an example of what not to do. Royce highlighted its flaws but unintentionally laid the groundwork for what became the dominant software development model for decades.

Phase 1: Requirements Gathering and Analysis

- All the requirements for the project are collected upfront. This includes technical specs, business goals, user needs, etc

Phase 2: System Design

- Architects and designers create the system’s blueprint based on the requirements. This includes both high-level design (overall architecture) and low-level design (detailed logic and data structures).

Phase 3: Implementation (or Coding)

- Developers start writing code based strictly on the design documents. There’s little to no room for creative deviation because everything was defined earlier.

Phase 4: Testing

- Once the product is fully developed, it’s passed to the QA (Quality Assurance) team for rigorous testing. Testers identify bugs, errors, or requirement mismatches.

Phase 5: Deployment (or Delivery)

- The final, tested product is delivered to the client or released to users. The software should be fully functional at this point.

Phase 6: Maintenance

- After deployment, bugs might still appear, or new user needs emerge. Maintenance involves fixing issues, but making significant changes is difficult because the whole structure was designed rigidly.

Key Characteristics of the Waterfall Model

• Linear and Sequential:

Each phase flows into the next, and there’s no going back. This rigidity can be a strength (clear structure) or a weakness (inflexibility).

• Documentation-Heavy:

Every phase produces comprehensive documents, which guide the next phase. Think of it as detailed architectural blueprints.

• Emphasis on Planning:

Since changes are costly, a lot of time is spent upfront planning every detail.

Best Suited For

• Projects with Clear, Unchanging Requirements:

E.g., Government contracts, aerospace software, hardware firmware—where requirements are fixed from the start.

• Regulated Industries:

Where detailed documentation and strict processes are legally required.

• Short, Simple Projects:

If the project scope is small, the rigid process isn’t as much of a burden.

Challenges and Drawbacks

• Inflexibility:

If a requirement changes mid-project, adapting is expensive and time-consuming.

• Late Discovery of Issues:

You don’t find out if the software really meets user needs until the very end.

• No Early Prototypes:

Unlike Agile, where you get working versions early, Waterfall gives you nothing to "play with" until it's nearly done.

Waterfall = Blueprint Before Building:

- Plan everything upfront, then build.

Agile = Learn and Adapt While Building:

- Build small parts, get feedback, adjust, and improve iteratively.

The Essence of Waterfall

• Sequential Phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance.

• Rigid Structure: Hard to go back to earlier stages once you’ve moved on.

• Heavy Documentation: Each phase is well-documented before the next begins.

• Best for Predictable Projects: Works great when changes are unlikely or risky.

Story Points

Story Points Represent

1. Effort

• The amount of work required to complete a task. For example, a simple UI tweak might have fewer points than implementing a complex API integration.

2. Complexity

• Tasks with more variables, dependencies, or unknowns will generally have higher story points. For example, building a new feature from scratch is more complex than fixing a minor bug.

3. Risk and Uncertainty

• Story points consider potential unknowns, such as technical challenges or unclear requirements. The greater the uncertainty, the higher the points.

4. Skill Requirements

• A task requiring specialized skills might have higher story points compared to tasks that are routine for the team.

How Story Points Are Used

1. Planning and Prioritization

• Teams use story points during sprint planning to decide how much work they can take on in a sprint. This ensures the sprint is achievable without overloading the team.

2. Velocity Tracking

• Story points help measure team velocity—the average number of story points a team can complete in a sprint. This historical data allows teams to predict how much work they can handle in future sprints.

3. Relative Estimation

• Story points focus on comparing tasks rather than defining precise time estimates. For example:

  • Task A (1 point) is simpler than Task B (5 points).

  • Task C (8 points) is about twice as complex as Task B.

4. Facilitating Discussions

• When estimating story points in sessions like Planning Poker, team members discuss what goes into the effort and complexity of tasks, aligning everyone's understanding of the work involved.

Key Factors to Consider When Assigning Story Points

• Effort: How much work is involved?

• Complexity: Are there multiple moving parts, integrations, or dependencies?

• Risk: Are there any unknowns, potential blockers, or uncertainties?

• Skill Level: Does the task require specialized knowledge?

Step-by-Step Process for Assigning Story Points

1. Break Down the Task

• Ensure the story is small enough to be estimated (e.g., should fit within a sprint).

• Split complex stories into smaller ones if necessary.

2. Define a Baseline Task

• Choose a small, simple task as a "baseline" and assign it a value of 1 story point.

• Compare all other stories against this baseline.

3. Evaluate Relative Effort

• Compare each task to others already assigned story points.

• Ask questions like:

  • Is this task twice as complex as the baseline? → Assign 2 points.

  • Is it significantly more complex? → Assign 8 or 13 points.

4. Account for Uncertainty

• Increase the estimate if there are unknowns or risks.

• For example, a task with unclear requirements might go from 5 to 8 points.

5. Finalize with Team Consensus

• Discuss discrepancies and ensure the entire team agrees on the estimate.