Here at LSG Solutions, Scrum is the type of Agile Development we use. It was originally formalized for software development projects, but it works well for any complex, innovative scope of work.
Scrum is the leading agile development methodology, used by Fortune 500 companies around the world. Here’s quick overview of the process:
- A product owner creates a prioritized wish list called a product backlog.
- During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
- The team has a sprint to complete its work, but it meets each day to assess its progress (daily Scrum).
- Along the way, the ScrumMaster keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.
The Agile Manifesto values appled directly to Scrum
Previously, we discussed the Agile Development manifesto. Here’s how it applies to Scrum:
Individuals and interactions over processes and tools
Scrum, like all the Agile frameworks and methods, relies directly on trust in teams, the individuals in the teams, and the way they interact. Teams figure out what is to be done, teams figure out how to do it, and teams do it. Teams identify what’s getting in their way, and they take the responsibility to resolve all the difficulties that are within its scope. Teams work with other parts of the organization to resolve the concerns that are outside their control. This is critical. Trying to do Scrum but undermining this primary focus on team responsibility will generally lead to trouble.
Working software over comprehensive documentation
Scrum requires a working, finished increment of the product as the primary result of every Sprint. Certainly there will be analysis work, design work, testing work, all of which may need to be documented. But it is the working software that allows the organization to guide the project to success. This is critical. Scrum Teams must produce a product increment in every Sprint.
Customer collaboration over contract negotiation
The Scrum Product Owner is the Scrum Team’s prime point of contact with the eventual end users of the product, and with the parts of the organization that need the product. The Product Owner is a member of the team and works collaboratively with the team to determine what needs to be done. In this collaboration, the Product Owner selects the most valuable next things to do, ensuring that the product has the highest possible value at every point in time. This is critical. The Product Owner needs to build a rich collaboration with their team.
Responding to change over following a plan
Everything about Scrum is designed to make sure that everyone has the information they need to make good decisions about the project. The project’s progress is represented by a real, running, product increment. The backlog of things to be done is available for all to see. Progress, both overall and Sprint by Sprint, is clearly visible. Problems and concerns are discussed openly and dealt with immediately. This is critical. Scrum works well for teams that openly “inspect” what’s going on and “adapt” their actions to the reality. It works poorly for those who do not.
Our office uses Jira by Atlassian to collaborate with our clients and team members. We’re found it’s the most effective and efficient way to help our team capture, assign and prioritize our work. If you’re interested in seeing how Jira works, watch this short 4-minute video for a demonstration.