L7 - Process: Why Do We Scrum?

CPSC 310: Introduction to Software Engineering Lecture Notes

Learning Outcomes

  • By the end of this lecture, you will be able to:

    • Understand the importance of process in software development.

    • Identify the processes we use to build software and why.

    • Understand why software is typically built in quick iterations.

  • By the end of this week, you will be able to:

    • Identify the tools we have for implementing effective software team communication.

    • Practice these tools (user stories, specifications, code review).

Importance of Process

  • Software is built by teams of people.

    • Large systems require large teams: Coordinating these teams can be challenging.

    • Process provides clarity: Helps define how decisions are made and how software will evolve.

    • De-risking mechanisms: Processes mitigate risks, facilitating effective teamwork.

Software Project Risks

  • 6 dimensions of risks in software projects:

    1. User Risks: Resistance to change, conflicts, negative attitudes towards projects, lack of commitment, lack of cooperation.

    2. Requirements Risks: Requirements that are changing, inadequately identified, unclear, or incorrect.

    3. Project Complexity Risks: Risks associated with new technologies, high complexity, immature technologies, or first uses of technology.

    4. Planning & Control Risks: Issues due to poor processes, inadequate estimations, poor planning, unclear milestones, inexperienced project managers, and ineffective communication.

    5. Team Risks: Inclusions of lack of experience, lack of training, lack of specialized skills, and lack of experience working as a team.

    6. Organizational Environment Risks: Changes in management during the project, instability of the organization, and ongoing restructurings.

  • Importance of assessing and mitigating these risks during project planning.

The Need for Good Planning

  • Software Process: A structured set of activities for developing a software system, defining who does what, when, and how to achieve goals.

    • Products: The outcomes of process activities.

    • Stakeholders: Individuals with a vested interest in the outcomes of the process.

Software Process Phases

  • Many different software processes exist, each with strengths and weaknesses.

  • All processes include the following phases:

    1. Requirements elicitation/gathering.

    2. Architectural design.

    3. Detailed design/specification.

    4. Implementation.

    5. Integration.

    6. Testing.

    7. Deployment.

    8. Maintenance.

  • Goals of these activities include:

    • Marking out clear steps.

    • Producing tangible items.

    • Allowing for review of work.

    • Specifying actions to perform next.

Value of Process

  • Highlights the importance of early attention to the processes used in projects:

    • Projects neglecting process often result in developers spending excessive time in meetings and correcting defects.

    • Initially, process-oriented teams may seem less productive, but they will operate more efficiently in the long run, requiring less conscious effort to perform processes.

    • Reference to Steve McConnell's analysis of process-oriented vs. process-averse teams.

Failure Rates and Process Inefficiencies

  • Graphical depiction of failure due to lack of planning (referencing waterfall process):

    • Issues in the waterfall process from planning, coding, testing, and implementation.

  • Discusses common waterfall scenarios, emphasizing lengthy timelines due to extensive requirements and the importance of managing risks during those phases.

Transition to Agile Development

  • Agile development evolves from traditional waterfall methods:

    • Agile emphasizes quick iterations, collaboration, and adaptability rather than strict adherence to planning and documentation.

  • Key principles of Agile:

    • Individuals and interactions over processes and tools.

    • Working software over comprehensive documentation.

    • Customer collaboration over contract negotiation.

    • Responding to change over following a plan.

  • Introduction of user stories and test-driven development as part of Agile practices.

User Stories and Agile Requirements

  • Definition of User Stories: Often described in the format of Role, Goal, Benefit.

  • Acceptance Criteria of user stories: Conditions that signify that a User Story is complete, referred to as “Definitions of Done.”

  • Advantages of User Stories:

    • Clear linkage between the problem domain and the solution domain.

    • Reduced risks due to focused definitions and smaller increments.

    • Simplified delegation of tasks among team members.

Agile Software Process Overview

  • Key concepts in Agile software process:

    • Test-driven design: Developing tests before code.

    • Emergent design: Growing from a Minimum Viable Product while targeting duplicates and applying abstractions as necessary.

    • Refactoring code: Refining code instead of a large upfront design, ensuring pragmatic decisions while avoiding poor code quality.

Scrum Implementation in Agile

  • Definition of Scrum: A framework to implement Agile principles.

    • Emphasizing iterative development moving from a working product to another working product.

    • Core ceremonies in Scrum include:

    1. Sprint Planning: Identifying stories from the backlog for the sprint and estimating complexity.

    2. Daily Stand-up: A brief 15-minute meeting to discuss progress, impediments, and commitments.

    3. Review and Retrospective: The team showcases what was accomplished during the sprint, often including demos of new features.

  • Artifacts in Scrum include:

    • Product Backlog: A prioritized list of customer-centric features.

    • Sprint Backlog: Work items selected from the product backlog for implementation during a sprint.

    • Burndown Chart: Measurement of remaining work over time within a sprint.

Summary of Scrum Process

  • Sprint Planning involves:

    • Pulling work items from the product backlog.

    • Committing to implementing the selected items within the sprint timeframe.

    • Conducting a daily stand-up meeting to monitor progress.

    • Closing a sprint with a review and retrospective to evaluate performance and address unresolved work.

Transition from Scrum to Kanban

  • Kanban Model: Another Agile methodology differing from Scrum by:

    • Not employing sprints, allowing a continuous flow of work.

    • Implementing a work-in-progress (WIP) limit for team capacity.

    • Space on the board is only cleared when tasks move between columns, with no specific release dates set by the team directly.

    • Maintaining daily stand-ups but forgoing sprint planning or reviews, leading to quicker releases and flexibility in the process.