The following is my understanding of Agile Project Management and Scrum. It has been formed through my participation on projects both waterfall and agile as both a Team Member and a Project Manager, Scrum Master and Product Owner.
Agile is an alternative approach to traditional Project Management. It is an approach that embraces change and collaboration and focuses on delivering a quality product and customer satisfaction. Agile defines a set of values and principles which are outlined in the Agile Manifesto. The Agile values emphasize collaboration, customer relationships, and continuous delivery of business value in a project.
Agile suggests working iteratively, and involving customers to direct product scope throughout the project. It was originally intended for Software Development projects, but can be used on projects with vague requirements, research projects or creative and artistic projects where an exact understanding of the end result is not possible.
Scrum is an Agile Framework, it is one many ways of delivering an Agile Project. It prescribes a set of base project roles, ceremonies and rules. It is a way to execute an Agile project. Scrum is sometimes called a methodology, but it only provides a scaffold. It is expected that additional, team determined processes will be added to it. If you are using Scrum, your project is an Agile project. But, you can have an Agile project and not use Scrum. You might be using Lean, for example. Lean is another way of doing Agile that is very different from Scrum.
I truly believe that Agile is about principles. The agile principles are derived from the statements in the Agile Manifesto:
For me, each of these statements has this basic truth behind it. In order to succeed we need to work together on the important work using our intelligence and creativity. When processes, and contracts and plans are not helping the project, we need to do something else. It is unforgivably foolish to do things in a way that we know is wrong just because of a rule.
Scrum is set of basic project activities designed to guide a project through the principles of the Agile Manifesto. It prescribes 3 roles and 4 'ceremonies' (meetings with specific objectives and different attendees) to support the Agile values.
The Team is a cross functional group of people that have the skills required to build the product. In a software project this would include, Business Analysts, Developers, Technical Writers, Designers, Architects and Testers.
The Scrum Master is the team's servant leader, they facilitate the Scrum ceremonies, remove impediments the team encounters, protect the sprint commitment, monitor team happiness and help the team delivery quickly.
The Product Owner is responsible for the product vision, and scope. They are responsible for the project budget and for prioritizing the list of project deliverables, known as the backlog. The Product Owner may engage other stakeholders to help with product decisions, but they are solely accountable for what is included in the project.
In Scrum, delivery iterations are called 'Sprints'. A sprint duration is chosen at the beginning of a project and can be up to 30days long. At the beginning of a sprint a planning meeting is called to 'pull' work into the sprint backlog. The sprint backlog is the committed work to be delivered in the sprint. All Scrum roles meet in the planning meeting, stakeholders may be present as well.
Once the sprint has been planned, the sprint commences and team members start working on the items in the sprint backlog. Everyday the team gets together for 15 minutes to collaborate on what they plan to accomplish that day and what they need from each other. Any impediments are raised to the Scrum Master. The Product Owner may or may not attend the daily scrum.
At the end of the sprint a meeting is held to review the work completed in the sprint and to showcase the newly built product functionality. This meeting is a celebration of the team's work and anyone interested in the project is invited to attend. Feedback is encouraged and the Product Owner can bring this feedback in to the project as new work.
After the Sprint Review the team gets together to reflect and adjust their work behaviors and processes. This is a collaborative session to identify what is working well and keep those practices and to surface what can be improved and to adjust team processes.
After the retrospective, the next sprint starts with another planning meeting to take on the next batch of work and the cycle continues until the Product Owner decides the project can be closed. Agile vs Scrum then is comparable to Mindset vs Methodology (or methodology framework).
See the Tangent Design and Build Process for more information on how I use agile for Web Site builds.
Traditional project management works under the assumption that every task and deliverable is equally important, and that everything identified in the Work Breakdown Structure or the Scope Document must be delivered or the project is deficient. However, what about technology projects with custom features or research and development that cannot be fully thought through, how can this be locked down? By the nature of creative projects, it is not possible to foresee all the risks and issues and mitigation and tasks required to complete them successfully.
This creates an elongated feedback loop from end customers and adds risk to the project because the business environment is changing as well. The product is already becoming obsolete, and pushing dates forward amplifies this issue.
Agile solves this by using iterations, and Scrum specifically calls these iterations 'Sprints'. Creating something and getting into the hands of the people that need it as early as possible in order to 'think through' the problems by actually solving them, or failing fast. In Waterfall projects, delivery dates are typically pushed forward for any missed task or issue. The Agile vs Scrum comparison here is, Iterate (Respond to Change) vs Sprint.
Everyone like surprises right? Well, Business doesn't really like surprises and revealing a product to stakeholders at the end of a project is extremely risky. Agile reduces the risk of requirements misdirection (unpleasant surprises) by releasing often and early and by involving customers throughout the process. An Agile project is a collaboration between the build team and customer stakeholders. So back to Agile vs Scrum; Agile says collaborate with the customer, Scrum enforces that with the Product Owner role that represents the customer and regular product demos.
The delivery team is empowered to be creative about solving customer problems using their expertise and experience. In Scrum, all stakeholders, including executive leadership are encouraged to attend the Sprint demos. The Sprint demo is a meeting held at Sprint end where the delivery team showcases the work that was accomplished in the Sprint.
Revealing the product as it is being created incrementally helps to socialize project expectations. Change is easier to accept if it experienced in small chunks. Showing the product as it evolves allows the team to make adjustments based on stakeholder feedback. Seeing project progress in the form of a tangible, working end product helps build trust in the project team. Stakeholders are seeing real results.
Customer collaboration is a principle of Agile and Scrum includes a Sprint Review and Demo to ensure customers are part of the process. The Agile vs Scrum comparison would be Agile encourages customer collaboration and working software (or product) and Scrum delivers that with a regular demo to all stakeholders of the recently added working features.
Agile is about change, for me project scope change is Agile's raison d'etre.
Traditional Project Management frowns on scope change, in fact it discourages change. Admittedly, it makes sense to lock down scope in a project as it is one of the triple constraints (Cost, Time and Scope). A change to scope will affect project cost, or time or both. Because 'on time' and 'on budget' are the measures of project success in waterfall projects, the triple constraint is the focus. Agile does not try to eliminate this constraint, it shifts the focus to customer satisfaction by creating additional flexibility in a project. A good product and happy customers takes priority over 'on time' and 'on budget'.
The ability to adjust and change course becomes critical when a good product is the criteria for project success.
In Scrum every Sprint produces a 'shippable product' or viable deliverable with business value. Agile does not prescribe how to handle change except to put focus on 'working software'.
To wrap up, Agile vs Scrum is Principles vs Actions. Agile principles put a focus on customers and the end product ahead of budget, scope and timeline. It encourages collaboration and iteration, product quality, responding to customer feedback and adjusting quickly.
Scrum is a set of agile actions, a way to implement agile. It defines a set of roles, ceremonies and practices to enable agility on a project. Scrum is a framework to build processes and behaviors upon.
Photo by John Duncan on Unsplash