Agile Practices

Scrum emerged in the early 1990s through the work of Jeff Sutherland and Ken Schwaber, who formally introduced it at the 1995 OOPSLA conference. Their inspiration came from a 1986 Harvard Business Review paper titled "The New New Product Development Game," which described high-performing teams using rugby-style "scrum" tactics. This is where the methodology got its name.^[1] Extreme Programming (XP), developed by Kent Beck in the late 1990s while working on Chrysler's C3 payroll system, focused on technical excellence.

While Scrum provided structure for organization and collaboration, XP delivered engineering discipline through practices like test-driven development, continuous integration, and pair programming.^[2] Both methodologies responded to the failures of traditional waterfall approaches by embracing iterative development, customer feedback, and adaptive planning. Together, they formed the cornerstone of what would become the Agile movement, ultimately leading to the 2001 Agile Manifesto, which Schwaber, Sutherland, and Beck all helped create.

Scrum is built on 3 pillars of empirical process control:

• Transparency ensures everyone has visibility into the work and process.
• Inspection involves regularly checking progress and results.
• Adaptation means changing course based on what's learned.^[3]

Unlike traditional management approaches that assume work can be fully planned in advance, Scrum embraces complexity and uncertainty. It creates frequent feedback loops through timeboxed iterations (Sprints) that deliver working product increments, allowing teams to learn and adjust continuously. Healthy Scrum teams demonstrate self-organization, cross-functional collaboration, and shared commitment to Sprint Goals. In contrast, "Zombie Scrum" occurs when teams go through the motions without embodying agile values. They hold ceremonies without gaining their benefits, plan without adapting, or focus on output rather than outcomes. The most successful Scrum implementations combine this framework with complementary technical practices like automated testing, continuous integration, and sustainable coding standards that enable rapid, high-quality delivery.

Scrum defines 3 distinct roles that form the Scrum Team, each with specific responsibilities that balance one another.

• The Product Owner represents customer and business interests, prioritizing the Product Backlog to maximize value. They make tough decisions about what to build first, balancing short-term needs with long-term vision. Effective Product Owners remain accessible to the team, provide clear acceptance criteria, and shield developers from shifting priorities mid-sprint.
• Developers (the Development Team) build the product increment. Cross-functional and self-organizing, they determine how to implement features, estimate work, and ensure quality. While specialized skills exist within the team, collectively they share responsibility for delivery.
• The Scrum Master serves as a coach and facilitator, helping everyone understand and apply Scrum effectively. They remove obstacles, facilitate ceremonies, and promote continuous improvement. A good Scrum Master leads not through authority but by influence, focusing on team effectiveness rather than individual productivity.

These roles create a system of checks and balances that prevents common product development problems like scope creep, siloed work, or disconnection from customer needs.

Product Owners bridge business stakeholders and development teams, translating strategic goals into actionable backlog items. Success in this role depends on building trust through consistency, transparency, and responsiveness to both team and stakeholder needs. Effective collaboration starts with clear value articulation. Rather than just describing features, great Product Owners communicate the "why" behind requests and quantify business outcomes. They express user needs through well-crafted user stories with clear acceptance criteria, making abstract concepts concrete and testable.

When working with designers and developers, Product Owners remain available to answer questions and make decisions quickly. They participate actively in backlog refinement, breaking down complex items into manageable pieces and ensuring the team understands priorities. The most successful Product Owners recognize their role as servants to the value stream, not commanders of the team. They facilitate rather than dictate, creating space for developers and designers to contribute their expertise while keeping everyone aligned to customer and business needs.

Development teams in agile environments thrive on autonomy, purpose, and technical excellence. They value clear problems to solve rather than prescribed solutions, and appreciate understanding the context and constraints around their work. Productive collaboration between developers and product/design professionals starts with mutual respect for different expertise. Designers and product managers should engage developers early in the concept phase, before solutions are fully baked. This early involvement helps identify technical constraints, alternative approaches, and implementation considerations that might otherwise be missed.

For designers specifically, pairing with developers during implementation proves more effective than throwing designs "over the wall." Working together, they can adapt designs for technical feasibility while preserving user experience quality.

Similarly, product managers gain valuable insights by attending technical discussions, even if they don't contribute directly. The most successful cross-functional teams develop shared language and mental models, reducing handoffs and miscommunication. They celebrate both technical and business achievements, recognizing that elegant code and user satisfaction are equally important to sustainable product development.

The Scrum Master's primary responsibility is enabling team success by fostering an environment where agile principles flourish. Unlike traditional managers who direct work, Scrum Masters lead through service. They remove obstacles, facilitate productive discussions, and coach both the team and organization on effective agile practices. Effective Scrum Masters demonstrate deep listening skills, identifying unspoken issues and helping the team address them constructively. They protect the team from external disruptions while simultaneously helping them remain accountable to their commitments. When obstacles arise, Scrum Masters take initiative to resolve them or connect the team with those who can help.

Designers and product professionals benefit greatly from understanding the Scrum Master role, even if they never formally assume it. The facilitation skills, systems thinking, and process improvement mindset that characterize good Scrum Masters transfer well to design leadership and product management. Organizations often underestimate the Scrum Master's impact, viewing it as an administrative role. In reality, skilled Scrum Masters transform team dynamics, significantly improving productivity, quality, and innovation by creating psychological safety and focus.

Kanban (看板), meaning "signboard" or "visual card" in Japanese, originated in Toyota's manufacturing system during the 1940s. Developed by industrial engineer Taiichi Ohno, it revolutionized production by creating a pull-based system that minimized inventory and overproduction. This became a key component of Toyota's Just-In-Time manufacturing approach. The system was inspired by American supermarkets, where shelves were restocked based on what customers took rather than through push-based forecasting. Ohno implemented this by using cards to signal when to produce more parts, ensuring production happened only when downstream demand existed.^[4]

In 2007, David J. Anderson adapted these principles to knowledge work and software development. He recognized that software teams faced similar challenges with work visualization, flow management, and matching capacity to demand. Anderson's adaptation preserved Kanban's emphasis on limiting work-in-progress and pulling work based on capacity, while modifying it for creative, non-repetitive knowledge work.^[5] Unlike many agile methods that required significant process changes, Kanban started with existing workflows and evolved them gradually. This made it accessible to teams resistant to dramatic shifts in how they worked.

Kanban revolves around 6 essential practices that together create a system optimized for flow and continuous improvement. Visualizing workflow through Kanban boards makes invisible knowledge work tangible. Teams map their process as columns (e.g., To Do, In Progress, Review, Done) and represent work items as cards moving across the board, creating transparency around status, bottlenecks, and dependencies. Limiting work in progress (WIP) prevents overloading team members and systems. By establishing maximum counts of items allowed in each stage, teams reduce multitasking, decrease lead times, and improve quality through focus.

When a column reaches its WIP limit, team members must help clear the bottleneck before starting new work. Managing flow shifts focus from individual utilization to system-wide efficiency. Teams monitor metrics like lead time (total time from request to delivery) and cycle time (time spent in active development) to identify improvement opportunities. Additional practices include making process policies explicit, implementing feedback loops at multiple levels, and improving collaboratively through models and the scientific method.

Scrum and Kanban represent different approaches to agile work management, each with distinct characteristics suitable for different contexts.

Scrum:

• Structures work in timeboxed iterations (Sprints)
• Teams commit to Sprint Goals and batch work upfront
• Creates predictable rhythms but less mid-Sprint flexibility
• Prescribes specific roles and five ceremonies for the structure

Kanban:

• Employs continuous flow without required timeboxes or roles
• Work items move individually as capacity permits
• Allows changing priorities at any time
• Focuses on limiting work-in-progress and optimizing flow

Scrum tends to work well for product development, requiring cross-functional collaboration and regular checkpoints. Kanban excels for service-delivery teams handling variable incoming work types or teams transitioning from more traditional processes. Some teams create hybrids like "Scrumban," using timeboxed iterations from Scrum while applying WIP limits and flow metrics from Kanban.

Selecting between Scrum, Kanban, or hybrid approaches involves matching the framework to your team's context, culture, and challenges. No single framework works optimally in all situations. Scrum provides a clear structure beneficial for teams new to agile or requiring significant cross-functional coordination. Its defined roles and ceremonies create guardrails that prevent common problems. Consider Scrum when building new products, working with stable teams, or needing regular synchronization points with stakeholders. Kanban offers flexibility and incremental adoption that works well for operational teams or those handling varied work types with different urgencies. Its focus on flow optimization suits support teams, maintenance work, or contexts where interruptions are frequent. Kanban also provides an easier transition for teams resistant to dramatic process changes.

For UX work specifically, Kanban often accommodates research and design activities more naturally than Scrum's fixed iterations. However, designers working directly with Scrum development teams might align their work to Sprint cadences while using Kanban to visualize their specific workflow states. The most successful implementations focus on principles over practices, adapting frameworks to fit the team rather than forcing teams to fit frameworks.