SCRUM is an Agile framework used for working on complicated projects, generally with a close-knit team. Simply, Scrum is a project management system.
A High-Level Overview of the SCRUM system:
- Scrum consists of three distinct roles: product owner, scrum master, and team member
- Scrum works by setting sequential goals that must be completed in a fixed length of time (called a “Sprint”)
- First, the product owner creates a “backlog,” which is a fancy term for a wishlist of tasks that need to be prioritized on a project. This is the set of deliverables needed for the product.
- Second, the Scrum team conducts a sprint planning session where parts of this wishlist are broken into smaller chunks.
- Next, the team creates a sprint backlog, plans for the implementation, and settles on a time duration (usually 1 or 2 weeks) for every sprint
- The team gets together every day for a scrum meeting where they share daily updates and access the progress of the project. This is led by the Scrum Master
- The product owners and stakeholders review the sprint cycle at the end to assess progress
Pros Of Scrum
What Scrum does is bring teams together to create great things. Scrum requires all project members to see the end goal and to work incrementally towards it.
Scrum is focused on creating a workable product that can be brought to market as soon as possible.
Doing sprint cycles and focusing on fixed periods of time where you bite off small bits of the project is a welcome breath of fresh air in stale and non-moving projects. It focuses on making sure the product is deliverable, not that stakeholder’s egos are met.
Having a structured system is a great starting place for getting a project organized, on track, and meeting well thought-out objectives. The product backlog and user story is a great way to avoid scope creep and egocentric decision making.
SCRUM is one of those systems that really requires buy-in from all different aspects of the organization. A quote from Sutherland’s book on Scrum:
“For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.”
At first glance, it seems crazy to believe that anyone in senior management would accept and welcome impediments to any sort of project. This assumes two things, 1., that the impediment is obvious, and not an unforeseen 2., that ego isn’t involved.
I’m sure this doesn’t happen in your organization, but some organizations we’ve worked on have hired 1 – 3 designers and spent months tweaking a design until it was perfect. “Perfect” was only defined by the COO of the organization.
Scrum really requires a revolution of culture, which can be hard for businesses. It can be even harder if there is a larger disconnect between IT and the business teams.
Even if the business understands and buys into the Scrum process, individuals can have issues. This would be someone like a middle-level sales manager or analyst. Now, they have to make User Stories instead of the documents/mock-ups/spreadsheets they were used to.
I knew a developer who took over an extremely dysfunctional engineering team with about 100 people. The first thing he did was implement Scrum. It worked incredibly well for about 2 – 3 years.
Then, it didn’t work anymore. The team had matured, the organization had become much leaner, and the process of doing Scrum was just too much. It was time for a new change.
This is something a lot of Scrum and Agile advocates don’t realize or won’t admit — Scrum is just a tool for specific applications. Scrum is not a be-all-end-all system that will solve all of your organizational issues forever.
I’m reminded of a great quote in reference to Growth Hacker Marketing and Growth Hacking: “You can’t growth hack your way out of a PR crisis.”
These lean and mean systems everyone is talking about work in dysfunctional environments where documentation is lack, communication is poor, and there seems to be no end in sight. The goal, I feel, should be to utilize pieces of these consistently, and only rely on the main systems in specific situations.
Like all systems, Scrum creates zealots too. It creates people who spend more time focusing on how Scrum is perfection, instead of seeing the pros and cons and focusing on the business objectives at hand.
Scrum, and similar systems have a habit of establishing the villainy of the status quo, and as such, a lot of the zealots spend more time refusing to see any downsides of Scrum, rather than looking at it as a useful tool for specific applications.
Another great quote in Sutherland’s book on Scrum:
“Years later it occurred to me that organizations, teams, and people are all complex adaptive systems. The same things that move cells from one state to another are also what move people from one state to another. To change a cell, you first inject energy into the system. At first, there’s chaos, there seem to be no rules, everything is in flux. When you do this to organizations trying to change, people freak out. They can’t understand what’s happening. They don’t know what to do. “
Overall I feel the principles behind Scrum are very solid. When executed properly, it really is a great way to get things done in a short period of time and to get an actual working product up and running.
Think a startup or major overhaul of an existing application. Scrum does a great job of focusing on the core components (what the users will use and need) and rolling out and testing those components. It has little room for the “surprise” meeting where we need to discuss a new offering because the CEO received a sales email from a competitor.
However, with an actual working product or existing project, I think elements of Scrum (the focus on sequential goals and eliminating waste) is a fantastic mindset all organizations should strongly push for. It’s the User stories, weekly/bi-weekly sprints, and similar that create issues.