In 2001, seventeen individuals, including Ken Schwaber and Jeff Sutherland (who would later help popularize the Scrum framework), met to discuss the various challenges faced by traditional project management and software development. They developed a set of agile principles that focused on user stories, adaptability, and frequent collaboration with stakeholders and end users (Known as the Agile Manifesto).
Agile, at its core, is an iterative approach to software development and project management. Instead of viewing the development process as a linear path, agile breaks it into several phases, allowing for continuous improvement and frequent assessment.
As Agile became widespread, many organizations attempted to "become Agile" without deeply understanding its values and principles. This led to the term "Agile-washing," where traditional processes were superficially labeled as 'Agile' without substantive change.
Agile isn't meant for any workplace — take the following quote, for example.
Scrum: It emphasized roles are Scrum Master, Product Owner, Development Team and ceremonies such as Daily Stand-ups, Sprint Review, and Sprint Retrospective.
Extreme Programming (XP): This method brought practices like pair programming, continuous integration, and test-driven development into the limelight.
Lean: Originating from Toyota's production system; it emphasized streamlining processes, eliminating waste, and continuous improvement.
Feature-Driven Development (FDD) and Dynamic Systems Development Method (DSDM): This method stresses the importance of tangible, client-valued functions in a structured and systematic way while addressing common failures of IT projects.
The 2010s saw the rise of numerous tools designed to facilitate Agile workflows. Platforms like JIRA, Trello, and Asana became popular tools to support Agile.
Moreover, with the increasing emphasis on DevOps, automation, and continuous delivery, Agile had to integrate with these paradigms, leading to a more holistic approach to product delivery.
Today, Agile is less about strict adherence to a particular methodology and more about a mindset. Companies emphasize building an "Agile culture" of collaboration, adaptability, and continuous learning.
There's also a renewed focus on Agile's "people" aspect. Concepts like psychological safety, inclusion, and diversity have become central to discussions on team dynamics.
The challenge arose with Agile's success in small teams: How do we scale for large organizations and big projects?
Thus, frameworks like the Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), and Large Scale Scrum (LeSS) came into existence. These provided structures to apply Agile principles at an enterprise level.
While the links above will go into more detail for each framework, we'll dive deeper into LeSS as a recommended framework for larger organizations and how your team can get started.
If you're interested in hearing how an engineering manager at Adobe adopted LeSS to significantly increase productivity, you can learn more
LeSS is similar to Scrum but involves coordinating several Scrum teams working on the same product and offers two different large-scale frameworks: LeSS Basic and LeSS Huge
LeSS Basic: Suitable for 2-8 teams.
LeSS Huge: Suitable for 8+ teams.
Here are fundamental aspects of LeSS that help.
Start with the basics of Scrum:
Before scaling, ensure that everyone involved understands the fundamental concepts and practices of Scrum. This includes roles (Product Owner, Scrum Master, Development Team), ceremonies (Sprint Planning, Daily Stand-up, Sprint Review, and Retrospective), and artifacts (Product Backlog, Sprint Backlog). You'll find the defining features of each role.
Adopt Feature Teams Over Component Teams:
Instead of organizing teams around architectural components (backend, frontend, etc.), arrange them around customer-centric features. Feature teams work on any part of the system, promoting flexibility and reducing hand-offs.
Define a Single Product Backlog:
Regardless of how many teams you have, maintain one Product Backlog for the entire product. The Product Owner prioritizes this backlog. A prevalent useful practice is a multi-team Product Backlog Review (PBR), which involves multiple teams convening in a single space to enhance shared learning and coordination.
Synchronized Sprints:
All teams work simultaneously on the same sprint length (usually 2-4 weeks) and start/end to ensure integration happens at least once every sprint.
Joint Events:
Overall Sprint Planning: (Two Parts)
Part 1: what to build and division of Product Backlog Items is decided and self-managed by team members from all teams.
Part 2: how to build and hold independently by each team.
Overall Daily Scrum: Representatives from each team briefly coordinate on dependencies and integration issues.
Overall Retrospective: After individual team retrospectives, a joint retrospective addresses common challenges and improvements.
Communicate frequently:
Regular conversations, code feedback, and adaptation are critical to successfully transitioning to Large Scale Scrum.
Irrespective of the chosen framework, the essence of Agile – delivering value quickly, continuous improvement, and close collaboration – should remain intact.
Agile is an adaptive, collaborative methodology that will drive success in the right scenarios. Before jumping on the Agile bandwagon, assessing if its characteristics align with your project's demands is essential:
1. Requirements are expected to change.
2. When Time-to-Market is Critical
3. The project benefits from regular feedback.
4. The product development requires flexibility.
5. The team is self-organizing and values teamwork and collaboration.
Agile thrives in ambiguity. If you anticipate evolving requirements, the iterative nature of Agile accommodates and even welcomes these changes.
Producing a minimal viable product and then iterating will ensure quicker time-to-market. Agile gives you that edge if beating competitors or capturing market opportunities hinges on speed.
Work is regularly reviewed and refined. Agile is a powerful ally if your project benefits from frequent check-ins, user feedback, and the flexibility to change course midway. It allows businesses to adapt to customer needs quickly, ensuring that the final product is as relevant and valuable as possible.
Agile's adaptive nature allows teams to address issues as they arise without derailing the entire project.
If your project demands frequent communication, teamwork, and a close-knit relationship with stakeholders or clients, Agile's collaborative ethos will drive success.
While Agile offers numerous benefits, it's not a one-size-fits-all solution.
The Waterfall development methodology will be more appropriate for more traditional projects where requirements are well-defined and unlikely to change. Each phase of the development process is completed fully before moving to the next.
Here are some other signs to consider before implementing Agile:
Set-in-Stone Requirements: If the project's requirements are well-defined, unlikely to change, and the pathway to achieving the end goal is clear, traditional methodologies will be more efficient.
Larger, Distributed Teams: Agile emphasizes close collaboration, which becomes challenging with vast, geographically dispersed teams. While there are ways to scale Agile, it requires extra effort and tools.
Regulated Environments: In sectors like aerospace or pharmaceuticals, where there's a heavy regulatory burden, the flexibility of Agile will clash with stringent regulatory requirements.
Agile is an adaptive and collaborative methodology that will drive success in the right scenarios.
But before jumping on the Agile bandwagon, assessing if its characteristics align with your project's demands is essential.
Whether you choose Agile, Waterfall, or a hybrid approach, pick a methodology that fits your goals, team dynamics, and project nature.
Free Resources