Read ONLINE

Scrum Framework

Scrum is a framework for developing, delivering, and sustaining complex products. It all starts out with our stakeholders, customers, and users who have an idea about a product they need and want to be developed. They collaborate directly with Developers to turn this idea into reality. Developers in Scrum are not just programmers. They are part of a self-managing and cross-functional team with all of the necessary skills to take a concept or idea and convert it into a Product. In order to ensure that all the stakeholders are on the same page and are not pulling the Developers in different directions, the Product Owner engages with the stakeholders and Developers to establish a Product Goal and get everyone aligned on the overall vision and roadmap. From this Product Goal, a Product Backlog emerges consisting of Product Backlog Items like hypotheses, features, requirements, and enhancements that help achieve the product goal. Now that there is a Product Backlog, Developers can work by pulling items off of the top of the Product Backlog and build the product iteratively and incrementally. For each Product Increment delivered, the stakeholders and users provide feedback, and based on this feedback, the Product Owner re-orders and updates the Product Backlog ensuring that the most valuable items are towards the top.



How does all this happen? Well, In Scrum, work is done in Sprints. A Sprint is a fixed duration with a specific start time and end time. A Sprint cannot be longer than 30 days. Once a team decides on a Sprint length, all Sprints follow the same length so that the team works on a regular cadence.


The Sprint starts with Sprint Planning where the team plans out their work for this Sprint. In Sprint planning, they establish a Sprint Goal, pull the high-priority items from the top of the Product Backlog that will help accomplish the Sprint Goal, and then task out the activities that they have to do in order to build and develop these Product Backlog Items into a working Product Increment. The Sprint Goal, the Product Backlog Items, and the tasks are known as the Sprint Backlog, or the team’s plan to accomplish the work. From this point on, the team is focused on the Sprint Backlog and collaborates together to complete these items as effectively as possible. Every day the Developers plan their day in what is called a Daily Scrum where they inspect their progress toward the Sprint Goal and adjust the Sprint Backlog accordingly. This continues until the end of the Sprint where the Developers package up what they completed into a Product Increment. The Product Increment is the output of every Sprint. It is a quality, working, useful, and valuable increment that includes all the previously built increments in addition to what was just built in this Sprint. The Product Increment should be at a level of quality as per the team’s agreed-upon Definition of Done.


At the end of each Sprint, the team has a Sprint Review where they collaborate with the Stakeholders and users to get feedback on what they built and what to build next. “Here’s what you asked us to build, and here is what we built. Is this correct? Is this what you were expecting? Is this valuable? Are we on the right track? Here’s what we are about to work on next? Is this still the most valuable thing we can be working on? Based on the feedback, the Product Owner adjusts the Product Backlog accordingly. This ensures that for each Sprint, the team is always working on the most valuable items and are regularly delivering value to the stakeholder in an iterative and incremental fashion.


Next, the team has a Sprint Retrospective to inspect how they are working as a team and see if they can improve. The Sprint Review is about inspecting and adapting the Product, while the Sprint Retrospective is about inspecting and adapting the process of building the Product. Any action items that come out of the Sprint Retrospective get added to the next Sprint Backlog as tasks for the team to work on.


Throughout the Sprint, the team is actively doing Product Backlog Refinement where they refine, clarify, research, estimate, split, and prep the Product Backlog Items so that the items at the top of the Product Backlog are ready to be worked on. There are no breaks in between Sprints. When one Sprint ends, the next one starts, so the product backlog needs to always be prepped with actionable items for future Sprints.


Finally, there is the Scrum Master, who is the team’s leader providing servant Leadership to support the Developers, the Product Owner, and the organization as a whole, ensuring that everyone is working together effectively and making forward progress toward their goals. The Developers, the Product Owner, and the Scrum Master are known as the Scrum team.


This is the Scrum Framework as defined by it’s

5 events: The Sprint, and within the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective

It’s 3 Artifacts: The Product Backlog, Sprint Backlog, and Product Increment along with the 3 commitments of the Product Goal, Sprint Goal, and Definition of Done.

And finally, it’s 3 accountabilities of Product Owner, Developers, and Scrum Master.

Scrum Accountabilities, Artifacts, and Events

In Scrum, there are 3 accountabilities, 3 artifacts, and 5 events.

 

The 3 accountabilities in Scrum are:


The 3 artifacts in Scrum are:


The 5 events in Scrum are:


And that’s the Scrum Framework as defined by

Scrum Team

The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master.


Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing.


Developers are cross-functional to remove bottlenecks and dependencies. Developers on a Scrum team have all the necessary skills to turn a concept or idea into a working product without any hand-offs to another team (concept to cash). All the skills from analysis, design, architecture, data modeling, coding, testing, deployment, etc. are available on the team. To enable cross-functionality, individual team members need to work on their t-shaped skills or m-shaped skills. Each team member has deep expertise in 1 area and works on broadening their expertise in 1 or 2 other areas so that they can help their teammates when needed. Team members won’t be able to do the heavy lifting in areas outside their expertise, but they will be knowledgeable enough to finish something that the expert started so that the team keeps making forward progress toward their goals.


Developers work on small Scrum teams to maintain good interactions and communications. Too few team members and they won’t have all the necessary skills to deliver a Product Increment. Too many team members and they won’t have good team interactions, collaboration, and communication.


Developers are also self-organizing. Developers decide how to do the work, how long it’s going to take, how much of it they can do in each Sprint, and who is going to work on what. Developers determine how best to accomplish the Sprint Goal, task out their work, estimate it, and assign themselves work. Developers are the ones closest to the work and thus know best how to accomplish it.


Developers in Scrum are stable and long-lived. Team members don’t get swapped in and out from Sprint to Sprint. The team members stay together for an extended period of time so that they grow together and develop strong team dynamics, build trust, and become high-performing.


Everyone who builds the product increment is referred to as a Developer. Developer does not equal programmer in Scrum. There are no testers, no analysts, no architects, and no programmers. It’s just Developers with cross-functional skills like testing, analysis, architecture, programming, etc. There are no sub-teams of Developers. Again, it’s just Developers to encourage the idea that they are all in this together. It’s not about the individual and finishing individual tasks. It’s about the team with mutual accountability for accomplishing the Sprint Goal and delivering a quality working Product Increment at the end of each Sprint. What matters is accomplishing goals and delivering a quality Product Increment, and everyone is accountable for that irrespective of their primary skill set.


The Product Owner is accountable for delivering a valuable Product Increment. The Product Owner does that by ensuring that Developers are working on the most valuable items. The Product Owner is 1 person and not a committee. The organization empowers the Product Owner to listen to the market, the customers, the buyers, the users, the developers, and the stakeholders and then make the best decision possible on what to work on next. The Product Owner is the decision maker and collaborates and engages with the stakeholders and Developers to determine the product strategy and business model, provide strategic direction, create product vision, goals, and roadmap, research the market and users to discover opportunities, needs and pain points, analyze the market and competition, determines value propositions, manage, order, prioritize, and refine the Product Backlog, and clarify the work for the developers.


The Scrum Master is accountable for the effectiveness of the Scrum team and the organization. The Scrum Master is the team’s leader providing servant leadership to help the Product Owner, Developers, and the organization make forward progress toward their goals. The Scrum Master educates the team on Scrum, helps establish empiricism, plans and advises on Scrum implementations, leads, trains, and coaches the organization on Scrum adoption, helps remove impediments, empowers the team, enables cooperation and collaboration, increases visibility and transparency, and facilitates as requested keeping events effective, productive, and within the timebox.


The Scrum Master coaches the Team in self-management and cross-functionality. Once a team is empowered to make how decisions (Developers) and is empowered to make what decisions (Product Owner), the Scrum team of about 10 people, can become a self-managing Scrum team that collaborates directly with stakeholders and users to deliver quality valuable Product Increments that meets their needs.


And that’s what a Scrum team is all about. A small self-managing team that can just run with things and regularly delivers a valuable, quality, working product while actively collaborating with the customer. This is very different from the hierarchical approach of most organizations where decisions get made at the top and then trickle down and down from one person to the next to the next until it gets to the team building the product and those team members usually end up having zero interactions with the users of the product.


It’s the Scrum Master who is championing and bringing about this change in how organizations approach work and how organizations and teams are structured, in order to foster high-performing, highly effective self-managing teams that continuously deliver value.


And that’s the Scrum team. A cross-functional, self-managing team that regularly collaborates with the stakeholders and users to build valuable quality products. The team has 3 accountabilities, Product Owner for value, Developers for quality, and Scrum Master for effectiveness.

Product Backlog and Product Backlog Refinement

Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal.

The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side requests. Any work should go through the Product Owner who determines its relevance and importance and places it in the Product Backlog for the team to work on.

The Product Backlog is dynamic, always changing, frequently reordered, and never complete. Why? Because Scrum is all about empiricism. Knowledge comes from doing the work, gaining experience, and then making decisions based on what is learned. Meaning, from the start the team is saying that it does not know everything. This is what is currently known today and what probably should be built. As the work progresses, there is an expectation that more and more will be learned, and based on that, the list is expected to continuously change. The Product Owner is always re-ordering the Product Backlog and ensuring the most important items are towards the top.

At any point in time, if you take a picture of the Product Backlog, it is going to look like this. Towards the top, the Product Backlog consists of fine-grained Product Backlog Items. These are items that have been reviewed, researched, clarified, estimated, and broken down into very small items that are considered “Ready” for the next Sprint and can get pulled into the Sprint Backlog and tasked out in Sprint Planning.


Towards the middle, the Product Backlog Items are less refined, a bit larger, and require clarification before being worked on.


Towards the bottom, the Product Backlog Items are large concepts or ideas that are vague, not yet well thought out, and require a lot of clarification before being worked on.


The Product Backlog will always look like this, with mostly fine-grained items towards the top and coarse-grained items towards the bottom. It will look like this on day 5, on day 25, on day 50, and on day 250. Why? Because as the top items that are “Ready” to be worked on get pulled into the Sprint Backlog, the items below them, move up and get broken down and clarified, and the items below them also move up and get broken down and clarified and so forth, doing this just in time and at the right level of granularity. This happens in Product Backlog Refinement and is referred to as progressive elaboration where the team clarifies the upcoming work as it gets closer and closer to working on it.


This is very different from the traditional “waterfall” development with big upfront plans based on detailed upfront requirements and designs. In Scrum, with empiricism, knowledge of what to do next is gained from building and developing, and that knowledge informs the requirements and designs and allows for continuous feedback and adjustments.


Product Backlog Refinement is an ongoing activity that occurs throughout the Sprint. It is not a time-boxed event. Just as the team dedicates time during the Sprint to build a Product Increment, the team also dedicates time to do ongoing Product Backlog Refinement. Refinement involves the Scrum team, with the key conversation happening directly between the Product Owner and Developers.


The Product Owner decides where a new Product Backlog Item might go, whether it goes towards the top, middle, or bottom based on its relevance and importance, always keeping the Product Goal in mind.


At any point in time, the Product Owner might drop an item deemed no longer important or necessary.


Throughout, the Product Owner regularly re-orders the Product Backlog based on the latest information and knowledge gained.


The Developers seek clarification, research, estimate, identify risks, and break items down into more manageable chunks of work so that by the time the items reach the top of the Product Backlog, they are “Ready” to be worked on.


And that’s Product Backlog Refinement, an ongoing activity that the Scrum team does throughout the Sprint to add, remove, reorder, clarify, research, estimate, split, or merge Product Backlog items to progressively elaborate on them so that the items towards the top of the Product Backlog are always ready for the next Sprint. Because when one Sprint ends, the next one starts. There are no breaks in between to figure out what to work on next. It’s the Ready items on the top of the Product Backlog. 

Sprint Planning

In Scrum, the Sprint starts with Sprint Planning where the Scrum team plans out their work for the Sprint and creates a Sprint Backlog. The Sprint Backlog is the team’s plan to accomplish the work. Sprint planning is timeboxed to 2 hours per week of Sprint, so for a 2-week Sprint it is one event for a maximum of 4 hours, and for a 4-week Sprint, it’s one event for a maximum of 8 hours, and so forth.

 

To plan the Sprint, the Scrum team considers what is still remaining to do from the Product Backlog, what’s already been done based on the Product Increment that’s been built so far, the progress they have made towards the Product Goal, and the team’s historical performance and current capacity.

In Sprint Planning the team covers 3 topics:


The first topic is about the Why? That is, why is the upcoming Sprint important? What is the Goal of this Sprint? Each Sprint has a Sprint Goal that creates focus for the team and results in a Product Increment that gets the team one step closer to the Product Goal.


The second topic is about the What? Now that the Sprint Goal is clear, the team figures out what cohesive set of Product Backlog Items will help accomplish the Sprint Goal which results in a Product Increment that gets the team one step closer to the Product Goal.


The third topic is about the How? For each Product Backlog Item, the team tasks out the activities needed to complete the item so that the team can accomplish the Sprint Goal which results in a Product Increment that gets the team one step closer to the Product Goal.


The Sprint Goal, the selected Product Backlog Items, and the tasks become the Sprint Backlog. This is the team’s plan to accomplish the work and to deliver on the Sprint Goal.


Parts 1 and 2 are led by the Product Owner with the Developers seeking clarification and providing input. Part 3 is led by the Developers with the Product Owner readily available to answer any remaining questions.


Developers must account for the work needed to accomplish the Sprint Goal as well as all other work that typically happens during the Sprint, like Product Backlog Refinement, continuous improvement initiatives, retrospective action items, technical debt, holidays, vacations, training, etc. In addition, Developers need to account for impediments and distractions like bugs, production issues, all hands-meeting, supporting other teams, and so forth. Developers consider their historical capacity and then assess whether the work is feasible. If not, the Developers negotiate with the Product Owner to reduce the scope while still achieving the goal. Finally, the Developers make a commitment to each other to accomplish the Sprint Goal.


And that’s Sprint Planning, the 1st event of every Sprint in Scrum. It’s a timeboxed event for the Scrum team to create the plan for accomplishing the work taking into account what still needs to be built based on the Product Backlog, what has already been built based on the Product Increment, the direction the team is heading in based on the Product Goal, and the team’s historical performance and current capacity. It’s 3 topics of why? what? And how? to create a Sprint Backlog that consists of the Sprint Goal, the Product Backlog Items, and the tasks that will help deliver on the Sprint Goal that will result in a Product Increment that gets them closer to the overall Product Goal. 

Daily Scrum

The Daily Scrum is a brief daily planning event by the Developers to inspect their work and the progress they are making toward the Sprint Goal that will result in a Product Increment. The Developers created their Sprint plan or Sprint Backlog in Sprint Planning at the beginning of the Sprint. However, this plan is not static. It’s updated as work is completed, and as new information is discovered. The Developers adapt, adjust, and update the Sprint Backlog by adding or removing tasks based on what they learned and what’s needed to accomplish the Sprint Goal and deliver the Product Increment.

The Daily Scrum occurs every day at the same time and is timeboxed to 15 minutes per day. Traditionally, each Developer talks about what they did yesterday to help accomplish the Sprint goal, what they plan to do today to help accomplish the Sprint goal, and what’s in the way that might prevent them from accomplishing the Spring goal. This approach helped the team focus and finish the event within the timebox. However, this format morphed the Daily Scrum into a status meeting instead of its intended purpose.


The Daily Scrum is not a status meeting. Neither the Product Owner nor the Scrum Master is required at the Daily Scrum. It’s a daily planning event for the Developers by the Developers to plan their day and figure out how they are going to collaborate together and support each other to do the necessary work to deliver on the Sprint Goal and produce a Product Increment.


The Daily Scrum is also not the place to raise impediments. Impediments are raised immediately when they arise. The Daily Scrum is the place to make sure that all impediments or blockers are visible and transparent and that someone is actively working on resolving them.


The Daily Scrum is also not the place for deep-dive discussions. Whoever needs to stick around to clarify an issue or help can do so in ad-hoc meetings set up right after the Daily Scrum.


And that’s the Daily Scrum. A timeboxed daily event by the Developers and for the Developers to plan their day and adjust their Sprint Backlog based on the progress they are making towards the Sprint Goal in order to successfully deliver a Product Increment at the end of the Sprint.

Sprint Review 

The Sprint Review is a working session for the stakeholders, users, and customers to collaborate with the Scrum team which includes the Developers, Product Owner, and Scrum Master, and inspect the progress made toward the Product Goal based on the latest Product Increment. The Sprint Review is about getting feedback from the stakeholders and users on the Product Increment and then adapting the Product Backlog accordingly.

In the Sprint Review the team shares with the stakeholders the Sprint goal and the Product Backlog Items the team worked on to deliver on the Sprint Goal and produce the Product Increment. The team might demo the Product Increment or have the stakeholders use it to verify that what they built meets their expectations, that they are on the right track, and that the Increment is useful and valuable. The team verifies that the next items in the Product Backlog are still the most important items to work on or whether they should pivot and work on something else instead. Based on this feedback, the Product Owner adjusts and adapts the Product Backlog accordingly to meet any new opportunities or requirements identified and therefore ensuring that the Scrum team is always working on the most valuable items.

The Sprint Review happens towards the end of the Sprint, involves the entire Scrum team collaborating with the stakeholders and users, and is timeboxed to 4 hours for a 4-week Sprint or 2 hours for a 2-week Sprint, and so on.

And that’s the Sprint Review. A timeboxed event that occurs towards the end of the Sprint for the Scrum team to collaborate with the stakeholders and inspect the Product Increment and the progress being made toward the Product Goal and to adapt the Product Backlog accordingly.

Sprint Retrospective

The Sprint Retrospective is a reflection event that occurs at the end of each Sprint. It is for the entire Scrum team which includes the Product Owner, Developers, and ScrumMaster to inspect how they are operating and then come up with a continuous improvement plan to adapt and become more effective as a team and as an organization.

In the Sprint Retrospective, the team might consider their team dynamics, relationships, processes, tools, or their Definition of Done, and then come up with action items to take on to improve. There are many types of retrospectives, the most basic is referred to as pluses and deltas where the team looks at what went well and what can be improved and then takes on improvement action items accordingly. The action items from the retrospective go into the next Sprint backlog as tasks for the team to work on to become more effective. This means that in the next Sprint, the team needs to allocate some time for continuous improvement initiatives that came out of the retrospective.

The Sprint Retrospective is the last event of the Sprint and is timeboxed to 3 hours for a 4-week Sprint and 1.5 hours for a 2-week Sprint and so on.

And that’s the Sprint Retrospective. A timeboxed event that occurs at the very end of the Sprint for the Scrum team to inspect their processes and adapt to continuously improve and become a more effective team and organization.

Product Increment and the Definition of Done 

The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and the team establishes a Sprint Goal, the team does not accept change requests that will disrupt the team from accomplishing the Sprint Goal and delivering the Product Increment. Any such changes will go into the Product Backlog to be considered for future Sprints.

The Product Increment is built iteratively and incrementally which means it includes all prior increments plus what was just built. This means the team continuously delivers products from Sprint to Sprint and regularly gets feedback ensuring the team is always working on the most valuable items. The Product Increment is a useful, valuable, and usable Product Increment and must be at a level of quality as per the Team’s Definition of Done.

The Definition of Done is the team’s auditable quality checklist. It is established as part of the team’s working agreement at the very beginning and then gets strengthened over time. The Definition of Done is not established in Sprint Planning because it does not change from Product Backlog Item to Product Backlog Item as it has more to do with how the team operates to ensure quality and less to do with the actual requirement they are building. Over time, the team improves its processes via regular retrospectives and updates its Definition of Done accordingly.

It is important to note that the team does not need to wait until the end of the Sprint to deliver the increment and can deliver multiple increments within the Sprint as long as the increment is a quality increment that meets the team’s Definition of Done.

And that’s the Product Increment, a working, useful, valuable, increment that’s delivered every Sprint, includes all previous Product Increments, and is at a level of quality as defined by the team’s Definition of Done. 

Scrum Values

For teams to succeed with Scrum, team members must become proficient in living the 5 Scrum values of commitment, focus, openness, respect, and courage.

Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal.

Focus: In Scrum, the team focuses on accomplishing the Sprint goal and minimizes any distractions that might prevent them from accomplishing the Sprint Goal. The team works on 1 Sprint goal at a time.

Openness: In Scrum, the team is open to new ways of working. They make sure that the work is visible and they are transparent about any challenges they are facing that will prevent them from accomplishing the Sprint Goal.

Respect: In Scrum, the team consists of members with various skill sets. The team respects each team member based on their capabilities and support and trusts each other to deliver on the Sprint Goal.

Courage: In Scrum, the team has the courage to work through tough problems, speak up when things are not going well, and then do the right thing.  Without the courage to speak up, the team and the organization will not improve.

And those are the 5 Scrum values of commitment, focus, openness, respect, and courage. The way the Scrum team behaves, approaches work, and tackles impediments should be guided by these values.  The decisions that they make and the actions that they take should reinforce these values, not diminish them. When these values are embodied by the scrum team and the people they work with, true empiricism comes to life. 

Scrum Foundations and Theory

Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses the Scrum events to regularly inspect and adapt the 3 Scrum artifacts.

Scrum is founded on Lean thinking and empiricism. Lean thinking reduces waste and focuses on essentials. Empiricism asserts that knowledge comes from experiences. That is, do the work, see how it went, and then decide what to do next based on what was just learned. The 3 pillars of empiricism are transparency, inspection, and adaptation. Transparency into the work is necessary in order for the team to properly inspect the work and adapt accordingly. Regular timeouts are also necessary for the team to stop what they are doing, pause, look back at what just happened, and then decide how to move forward. In Scrum, the Product Increment provides transparency into what has been built so far. The Product Backlog provides transparency into what still needs to be built. The Sprint Backlog provides transparency into what is currently being built. The 4 events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective within the containing Sprint event provide the opportunity for the team to regularly inspect and adapt based on the transparency provided by the updated artifacts.

The events in Scrum are time-boxed. Once the end of the time-box is reached, the event ends and the team moves on (irrespective of whether the work to be done is completed or not). Based on the size of the Sprint, each event has a recommended maximum time limit. For a 1-week Sprint, Sprint Planning is timeboxed to 2 hours, Daily Scrum to 15 min/day, Sprint Review to 1 hour, and Sprint Retrospective to 45 min. The timebox limits increase proportionally for longer Sprints.

When the team has a short period of time to do something, the team prioritizes and figures out what’s most important to work on right now. The team breaks down large and complex work to fit in the timebox. The team focuses on finishing and delivering the work within the timebox. The team gets the opportunity to get feedback at the end of each timebox. With frequent feedback, the team adjusts and continuously improves to become more effective. These are all benefits of timeboxing.

Scrum is just a framework, which means it is purposely incomplete. It is not a prescriptive methodology with detailed instructions. Instead, it is just a lightweight guide that provides guard rails to keep teams heading in the right direction and prevents them from falling off. The Scrum rules, team structure, way of working, accountabilities, artifacts, and events, are set up to keep the team on track by regularly inspecting and adapting. If Scrum is only partially implemented, the guard rails might crack, and the team will not realize the benefits that Scrum delivers.

Based on a team’s context, organization, type of product being built, unique challenges, and their latest observations and learnings, a team may employ additional practices and techniques within the framework. What works for 1 team in 1 organization might not work for another team in another organization. It’s all contextual and there is no 1 best way of using Scrum. For those reasons, Scrum is said to be lightweight and simple to understand, yet difficult to master. Lightweight and simple to understand because the Scrum Guide is less than 20 pages and just lays out Scrum theory along with the Scrum accountabilities, artifacts, and events. It’s difficult to master because Scrum requires a change in how organizations and teams are traditionally structured and how they approach work, and many are resistant to change and find the necessary changes too disruptive.

And that’s Scrum. A framework used for solving complex adaptive problems. There is no hiding in Scrum. A team has a short period of time to deliver value. If they can great! If they cannot, it will be obvious and transparent as to why. Scrum on its own, will not solve the team’s problems, but instead, Scrum shines a bright light on the team and organizational impediments. It’s up to the team and the organization to decide what to do about those impediments and how to address them for continued success.

Scrum and Agile

Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products.

The participants shared and learned about each other’s frameworks, including Scrum, eXtereme Programming (XP), Feature Driven Development (FDD), Adaptive Software Development, Crystal, Dynamic Systems Development Method (DSDM), and others, and summarized the essence of their work by publishing the Manifesto for Agile Software Development consisting of 4 value statements along with 12 principles.


Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiations

Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

 

The 12 principles behind the Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 

Scrum’s influence on crafting these values and principles is clear with its focus on team composition, self-organization, regular communication and collaboration between team members and customers, working in Sprints to maintain a sustainable pace, frequently delivering a working valuable product at the end of each Sprint, focusing on customer satisfaction and customer value, regularly adjusting to new requirements, and continuously inspecting and adapting to become more effective.

Scrum is a framework that organizations and teams can use to become Agile and live by these values and principles. Scrum is never the goal. It’s just a tool to help you deliver value.


Appendix: Additional Reading

Copyright © 2023 by Fadi StephanAll rights reserved.No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except as permitted by U.S. copyright law. For permission requests, contact us at Kaizenko.com or https://www.kaizenko.com/contact/.