Unit 6: Agile Practices and Organizational Adoption

Introduction to Sprint

A Sprint is the heartbeat of Scrum. It is a time-boxed event of one month or less during which a "Done," usable, and potentially releasable product Increment is created.

Key Characteristics of a Sprint

• Time-boxed: Sprints have a consistent, fixed duration. A typical length is 2 weeks, but it can be anywhere from 1 to 4 weeks. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
• Consistent Duration: The consistency of Sprint length provides a predictable rhythm for the team and stakeholders, making planning and forecasting more reliable.
• Goal-Oriented: Each Sprint begins with a Sprint Goal, a high-level objective that provides guidance to the Development Team on why it is building the Increment. It gives the team some flexibility regarding the functionality implemented.
• Contained Event: A Sprint contains all other Scrum events: Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.
• No Changes Mid-Sprint: No changes are made during a Sprint that would endanger the Sprint Goal. The scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Purpose: The core purpose of a Sprint is to deliver a valuable, finished piece of work (an Increment) in a short, repeatable cycle. This allows for rapid feedback, risk reduction, and adaptability.

Sprint Planning

Sprint Planning is the event that initiates the Sprint. The entire Scrum Team (Product Owner, Scrum Master, and Development Team) collaborates to plan the work to be performed in the Sprint.

Purpose and Structure

• Purpose: To define what can be delivered in the upcoming Sprint and how that work will be achieved.
• Time-box: Typically 8 hours for a one-month Sprint. For shorter Sprints, it is usually shorter (e.g., 4 hours for a 2-week Sprint).
• Participants: The entire Scrum Team.

The Two Parts of Sprint Planning

1. Part One: What can be done this Sprint? (The "What")

   • The Product Owner presents the ordered Product Backlog Items (PBIs) and discusses the objective that the Sprint should achieve (the Sprint Goal).
   • The Development Team works to forecast the functionality that can be developed during the Sprint. They select items from the Product Backlog to include in the Sprint.
   • The entire Scrum Team collaborates on crafting a Sprint Goal.

2. Part Two: How will the chosen work get done? (The "How")

   • The Development Team decides how it will build this functionality into a "Done" product Increment during the Sprint.
   • The selected Product Backlog Items are decomposed into smaller, manageable tasks, often on a daily basis. This collection of PBIs and the plan to deliver them is called the Sprint Backlog.
   • The Development Team should have enough of a plan to confidently start the work, but it doesn't need to be complete down to the last detail. The plan will emerge throughout the Sprint.

Inputs and Outputs

• Inputs:
  • The latest Product Backlog.
  • The latest product Increment.
  • Projected capacity of the Development Team for the Sprint.
  • Past performance of the Development Team.
• Outputs:
  • The Sprint Goal.
  • The Sprint Backlog (the set of PBIs selected for the Sprint, plus a plan for delivering them).

Product Backlog and Backlog Refinement

The Product Backlog

The Product Backlog is an ordered, living list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.

• Owner: The Product Owner is solely responsible for the Product Backlog, including its content, availability, and ordering.
• Content: It contains all features, functions, requirements, enhancements, and fixes. Items in the backlog are typically expressed as User Stories.
• Dynamic Nature: The Product Backlog is never complete. It evolves as the product and the environment in which it will be used evolves.

A good Product Backlog follows the DEEP acronym:

• Detailed Appropriately: Items at the top are detailed and small; items at the bottom are larger and less detailed.
• Estimated: All items have a size estimate (e.g., in Story Points).
• Emergent: The backlog is not static; it is constantly updated with new items and ideas.
• Prioritized: All items are ordered by value, risk, and dependency. The highest priority items are at the top.

Backlog Refinement (Grooming)

Backlog Refinement is the ongoing process of adding detail, estimates, and order to items in the Product Backlog. This is not a formal Scrum event but a continuous activity.

• Purpose: To ensure the backlog is clean, well-understood, and contains items that are ready to be worked on in upcoming Sprints. This makes Sprint Planning more efficient and effective.
• When: It usually consumes no more than 10% of the Development Team's capacity. It can happen at any time but is often done in dedicated sessions once or twice per Sprint.
• Who: The Product Owner and the Development Team collaborate. The Scrum Master may facilitate.
• Activities:
  • Breaking down large items (Epics) into smaller User Stories.
  • Adding acceptance criteria and details to User Stories.
  • Estimating the effort for items (e.g., using Story Points).
  • Re-ordering the backlog based on new insights.
  • Removing items that are no longer relevant.

Sprint Review

The Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. It is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

• Purpose: To showcase the work that was completed ("Done") during the Sprint and get feedback from stakeholders.
• Time-box: 4 hours for a one-month Sprint (pro-rated for shorter Sprints).
• Participants: The Scrum Team and key stakeholders (e.g., customers, users, management).

Activities During a Sprint Review

1. Opening: The Product Owner explains which Product Backlog items have been "Done" and which have not.
2. Demonstration: The Development Team demonstrates the work that it has "Done" and answers questions about the Increment. This is a hands-on demonstration of a working product, not a slide presentation.
3. Feedback & Discussion: The entire group collaborates on what to do next. The Sprint Review provides valuable input to subsequent Sprint Planning.
4. Backlog Adaptation: The Product Backlog may be adjusted based on the feedback received.
5. Future Outlook: Discussion of the market or potential use of the product might lead to the next most valuable things to do.

Outcome: A revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

• Purpose: To improve the process, not the product. It focuses on the people, relationships, processes, and tools.
• Time-box: 3 hours for a one-month Sprint (pro-rated for shorter Sprints).
• Participants: The entire Scrum Team (Product Owner, Scrum Master, Development Team). Stakeholders do not attend.

The Prime Directive

Norman Kerth's Prime Directive sets the stage for a successful retrospective:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

This creates a safe environment for open and honest discussion without blame.

Common Formats

1. What went well? / What didn't go well? / What can we improve? (The classic format).
2. Start / Stop / Continue:
   • Start doing: New ideas to improve the process.
   • Stop doing: Things that are hindering the team.
   • Continue doing: Things that are working well and should be continued.
3. Mad / Sad / Glad: Focuses on the emotional journey of the team during the Sprint.

Outcome

The key output is a list of actionable improvement items. The team should select one or two high-priority improvements to implement in the next Sprint. These are often added to the next Sprint Backlog.

Kanban Board

Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. It uses a visual system, the Kanban Board, to manage the flow of work.

A Kanban Board is a tool used to visualize work, limit work-in-progress (WIP), and maximize efficiency (or flow).

Core Principles of Kanban

1. Visualize the Workflow: See all the work items in context of each other. This is the primary function of the board.
2. Limit Work-In-Progress (WIP): By limiting how much unfinished work is in process, you can reduce the time it takes an item to travel through the workflow.
3. Manage Flow: Measure and manage the flow of work through the system. The goal is to make the flow smooth and predictable.
4. Make Process Policies Explicit: Make the rules for the system clear (e.g., when a card is moved to "Done").
5. Implement Feedback Loops: Use regular meetings (cadences) to review and improve the system.
6. Improve Collaboratively, Evolve Experimentally: Kanban is an evolutionary improvement process.

Components of a Kanban Board

• Visual Cards: Each card on the board represents a single work item.
• Columns: Each column represents a stage in the workflow (e.g., To Do, In Progress, Testing, Done).
• WIP Limits: Explicit limits on how many items can be in a column at any one time. This is a critical feature to prevent bottlenecks and encourage focus.
• Swimlanes: Horizontal lanes used to categorize work, such as by feature, team member, or urgency (e.g., an "Expedite" lane for urgent tasks).
• Commitment Point: The point at which a work item is picked up by the team and work begins.
• Delivery Point: The end of the workflow, when the work is finished and delivered to the customer.

Burn Down & Burn Up Charts

These are information radiators used to track progress over time.

Burn Down Chart

A Burn Down Chart shows the amount of work remaining over time.

• X-axis: Time (e.g., days of the Sprint).
• Y-axis: Work remaining (e.g., Story Points or hours).
• Ideal Line: A straight line from the total work at the start to zero at the end, representing a perfect, steady pace.
• Actual Line: Tracks the actual work remaining each day.

How to Read It:

• If the actual line is above the ideal line, the team is behind schedule.
• If the actual line is below the ideal line, the team is ahead of schedule.
• A flat line indicates no progress is being made.
• A line that goes up indicates that new work (scope creep) has been added.

Burn Up Chart

A Burn Up Chart shows the amount of work completed and the total scope of the project over time.

• X-axis: Time.
• Y-axis: Work (e.g., Story Points).
• Total Scope Line: A line showing the total amount of work in the project or release. This line moves up if scope is added.
• Work Completed Line: A line showing the cumulative work completed to date.

Advantages over a Burn Down Chart:

• It clearly separates progress from scope changes. In a burn-down chart, if scope is added, the line goes up, which can look like negative progress. In a burn-up chart, the scope line goes up, but the completed work line remains unaffected, providing a clearer picture.

Scrum Process and Tools

Scrum Process Overview

Scrum is an agile framework for developing, delivering, and sustaining complex products. It is structured around a series of events, artifacts, and roles.

1. Input: The Product Backlog, owned by the Product Owner.
2. Sprint Planning: The Scrum Team (Product Owner, Scrum Master, Development Team) plans the Sprint, creating the Sprint Goal and Sprint Backlog.
3. The Sprint (1-4 weeks):
   • The Development Team works on the items in the Sprint Backlog to create a potentially releasable Increment.
   • The Scrum Master facilitates the process and removes impediments.
   • Daily Scrum: A 15-minute daily meeting for the Development Team to synchronize activities and create a plan for the next 24 hours.
4. Sprint Review: At the end of the Sprint, the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog.
5. Sprint Retrospective: The Scrum Team reflects on the past Sprint to identify and plan process improvements.
6. Repeat: The cycle repeats with the next Sprint.

Common Agile Tools

While agile is a mindset, several tools facilitate the process:

• Jira: A widely used tool for issue tracking and agile project management. Supports Scrum boards, Kanban boards, backlogs, and reporting (burn-down/up charts, velocity charts).
• Trello: A simple, visual Kanban-style list-making application. Excellent for smaller projects or teams just starting with Kanban.
• Asana: A project management tool that supports both list-based and board-based (Kanban) views. Strong in task management and team collaboration.
• Miro / Mural: Virtual whiteboard tools that are invaluable for distributed teams, facilitating collaborative sessions like backlog refinement, retrospectives, and story mapping.
• Azure DevOps (formerly VSTS): A comprehensive suite from Microsoft that includes agile planning tools, CI/CD pipelines, and source control.

Creating a Kanban Board

Here is a step-by-step guide to creating a physical or digital Kanban board.

1. Map Your Workflow:

   • Identify the distinct steps your work goes through from start to finish.
   • Keep it simple at first. A basic board might be: To Do -> In Progress -> Done.
   • A more detailed workflow could be: Backlog -> Ready to Start -> In Development -> In Test -> Ready for Release -> Done.

2. Design the Board:

   • Create columns for each step of your workflow identified above.
   • Use a physical whiteboard, wall space, or a digital tool (like Trello or Jira).

3. Create Cards for Work Items:

   • Write each task or user story on a separate card (or sticky note).
   • Include essential information: a short description, an owner (who is working on it), and an estimate if applicable.
   • Place all current work items in the appropriate columns.

4. Establish Work-In-Progress (WIP) Limits:

   • This is the most critical step for managing flow.
   • For each "in-progress" column (e.g., In Development, In Test), set a limit on the number of cards allowed in that column at any one time.
   • A good starting point is 1-1.5 items per team member in that stage.
   • The goal is to prevent bottlenecks and encourage a "pull" system, where new work is only pulled in when there is capacity.

5. Define Explicit Policies (Rules of the Road):

   • Clearly define what it means for a card to be in each column. For example, what criteria must be met before a card can be moved from In Development to In Test? This is often called a "Definition of Done" for that stage.
   • Define how the team will handle blocked items or urgent requests.

6. Implement and Continuously Improve:

   • Start using the board.
   • Hold regular meetings (cadences) like a daily stand-up and a weekly or bi-weekly retrospective to discuss the flow of work.
   • Analyze metrics like Lead Time (total time from request to delivery) and Cycle Time (time from when work starts to when it's finished) to identify areas for improvement.
   • Adjust the workflow, columns, and WIP limits as the team learns and evolves.

Agile Organization

An Agile Organization is a company that has moved beyond using agile practices in just its IT or software teams. It is a network of teams operating in rapid learning and decision-making cycles, guided by a common purpose, to co-create value for all its stakeholders.

Agile Organizational Structure

Agile organizations move away from rigid hierarchies towards more fluid, team-based structures designed for speed and customer-centricity.

Cross-Functional Teams

The building block of an agile organization is the small, persistent, cross-functional team. This team has all the skills necessary (e.g., marketing, design, engineering, finance) to deliver value to the customer without significant hand-offs or dependencies on other teams.

The Spotify Model (Example of an Agile Structure)

The "Spotify Model" is a popular example of how an agile organization can structure itself at scale. It's not a rigid framework but a set of guiding principles.

• Squad: The basic unit. A small, cross-functional, self-organizing team with a long-term mission (e.g., the "Search" squad). They are like a mini-startup.
• Tribe: A collection of squads that work in a related area (e.g., the "Music Player" tribe). The tribe provides a sense of belonging and is co-located.
• Chapter: A group of people with similar skills from different squads within the same tribe (e.g., the "Web Developer Chapter" or the "Quality Assurance Chapter"). The Chapter Lead is a line manager responsible for coaching, mentoring, and skills development. This ensures engineering excellence.
• Guild: A lightweight, organic "community of interest." Anyone can join a guild. It's a way to share knowledge, tools, and best practices across the entire organization (e.g., the "Web Technology Guild" or the "Agile Coaching Guild").

Five Trademarks of Agile Organizations

Based on research by McKinsey, agile organizations exhibit five core trademarks that stabilize them while also enabling dynamic, high-performance operations.

1. Strategy: A North Star Embodied Across the Organization

   • A shared purpose and vision that guides every team and individual, helping them prioritize and make decisions autonomously. It provides alignment without micromanagement.

2. Structure: A Network of Empowered Teams

   • A move from a rigid hierarchy to a flexible network of teams. The structure is flat, with clear, accountable roles. Teams are built around customer journeys or capabilities.

3. Process: Rapid Decision and Learning Cycles

   • The organization operates with rapid iterations of thinking, doing, and learning. Processes are designed for speed and continuous improvement. This includes using agile practices like Sprints and frequent feedback loops.

4. People: A Dynamic People Model That Ignites Passion

   • Leadership empowers and develops its people. Roles are focused on creating value. A culture of entrepreneurship and continuous learning is fostered, where people are encouraged to take ownership.

5. Technology: Next-Generation Enabling Technology

   • Technology is embraced as a core enabler of agility. This includes modular architecture, DevOps practices (CI/CD), and data/analytics tools that enable rapid development and informed decision-making.

Agile Strategic Vision

In a traditional organization, strategy is a top-down, multi-year plan that is executed rigidly. In an agile organization, strategy is more like a compass than a map.

• The North Star: The organization is guided by a clear and compelling vision or "North Star." This vision is stable over the long term and provides direction.
• Adaptive Strategy: While the vision is stable, the path to get there is not. The strategy is broken down into a backlog of initiatives or objectives.
• Quarterly Business Reviews (QBRs): Teams and leadership regularly (e.g., quarterly) review progress against objectives, assess changes in the market, and re-prioritize the strategic backlog. This allows the organization to pivot quickly without losing sight of its ultimate goal.
• Empowered Execution: Teams are given clear objectives (the "what" and "why") but are empowered to figure out the "how." This decentralizes decision-making and increases speed.

Distributed Teams

Agile was originally conceived for co-located teams, but many modern teams are partially or fully distributed. This requires intentional effort to overcome challenges.

Challenges

• Communication Barriers: Lack of non-verbal cues, "out of sight, out of mind" problems, difficulty with spontaneous collaboration.
• Time Zone Differences: Can make synchronous collaboration (like meetings) difficult and cause delays.
• Building Team Cohesion: Harder to build trust and camaraderie without face-to-face interaction.
• Tooling and Infrastructure: Requires reliable technology and tools for everyone.

Best Practices for Distributed Agile

• Over-Communicate: Establish clear communication protocols. Use dedicated channels (e.g., Slack, Teams) for different topics.
• Leverage Collaboration Tools: Use digital Kanban boards, virtual whiteboards (Miro/Mural), and high-quality video conferencing.
• Master Asynchronous Communication: Document decisions clearly, record meetings for those who can't attend, and use tools that support asynchronous feedback.
• Structure Virtual Ceremonies: Ensure virtual stand-ups, reviews, and retrospectives are well-facilitated and engaging for everyone. Use interactive tools to keep people involved.
• Intentional Team Building: Schedule virtual coffee breaks, online games, or other social events to build personal connections.
• Establish Core Working Hours: Define a block of time where all team members are expected to be online and available for synchronous collaboration.

Agile Structures and Leadership

The shift to an agile operating model requires a fundamental shift in leadership style and the role of management.

Traditional vs. Agile Leadership

Servant Leadership

A Servant Leader is a leader who focuses on the needs of the team members and the customers they serve. Their primary goal is to serve, not to command.

• Key Behaviors: Listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of people, and building community.
• Role in Agile: The Scrum Master is a prime example of a servant leader. Their job is to serve the Product Owner, the Development Team, and the organization by removing impediments, facilitating events, and coaching agile practices.

The Evolving Role of the Manager

In an agile organization, the traditional "project manager" or "line manager" role changes dramatically. They are no longer responsible for assigning tasks and monitoring progress. Instead, they become:

• Capability Builders: They are responsible for the long-term growth and skills of their people (like a Chapter Lead in the Spotify model).
• Coaches and Mentors: They guide teams and individuals, helping them improve their performance and solve complex problems.
• Vision Setters: They help connect the team's work to the organization's broader strategic vision (the "North Star").
• Impediment Removers: They use their influence to remove organizational roadblocks that are beyond the team's ability to solve.