This could be your sales team wanting new features to help them sell product. It could be your leadership team wanting to realize their vision for the product or company. And, of course, it could be your customers, who are usually the most demanding – and important – stakeholders of all.
The trouble with most software development is that stakeholders and development teams don’t often communicate well.
Stakeholders often have thoughts like these regarding the development team:
- What are they working on now?
- I didn’t know it was going to take that long!
- They’re not producing what I need.
- There’s no accountability.
- We’re not speaking the same language.
Meanwhile, here’s what the development team is thinking about the stakeholders:
- They’re not clear about what they want.
- They keep changing their mind.
- They’re trying to tell me how to do my job.
- They expect miracles.
- We’re not speaking the same language.
This represents a fundamental divide between your business and technical resources. All too often, it can also create a cloud of tension, and even mistrust, within the company.
But what if…
- Business stakeholders could clearly communicate needs to the development team?
- Stakeholders could set the team’s priorities?
- The development team delivered new features quickly?
- There was a way to create a predictable schedule?
- There was a way to respond rapidly to shifting needs and change?
These are the questions which Scrum set out to answer.
What is Scrum?
Scrum grew out of a 1986 Harvard Business Review paper that envisioned a software project operating more like a rugby team. Where traditional projects acted more like football teams (with plenty of handoffs and passing around and people moving every which way), a rugby team typically moved down the field together, as one cohesive unit.
At its core, Scrum is an iterative development process. It employs a closed loop system, starting with a stakeholder need. This is passed to the development team, which builds the feature. The feature is then delivered to customers. Feedback is collected from those customers. And then – based on the feedback received – the next stakeholder need is prioritized and enters the loop.
What makes Scrum different, however, is the way this loop is implemented. Previously, this loop could represent the entire project (or a large portion of it) and could take years to complete.
Scrum revs this loop up into much shorter, faster cycles. It also allows more efficient and fluid reactions to changing business conditions.
Four Key Components of Scrum
A successful Scrum project will consist of these four key components:
- The Product Backlog: a prioritized to-do list that includes all the features requested by the stakeholders.
- Production Sprint: a 2-4 week cycle where the development team selects the top priorities from the Product Backlog and works exclusively on those features.
- Daily Scrum Meeting: a daily feedback and update session that keeps the team cohesive and working on the same page, while identifying and addressing any issues or obstacles.
- Shippable Product: each production sprint results in a “potentially shippable product increment” that is complete, tested, and ready for use by customers – whether the business decides to actually ship it or not.
Scrum Teams in Action
While your development team will need a variety of skills and expertise, there are only three true roles in Scrum: the Product Owner, the Scrum Master, and the development team members.
The Product Owner acts as a liaison with the business team and is in charge of prioritizing the product backlog. The Scrum Master supports the team and makes sure the process is being followed.
The development team does the heavy lifting.
First, they take the top priority item from the product backlog and break it down into the tasks they’ll need to accomplish. Then they decide how much of that they’ll take on (and how they’ll do it) in the next production sprint.
This is an important distinction in Scrum, because the development team sets their own workload and commits to their own work. The results are much more effective than when management simply tells developers what they should be able to do. Their estimates are more accurate. Their morale improves. Their productivity increases. And the accountability issue is solved.
Changes in Business Environment
Consider the following statement and response…
Statement: “I just heard last week that if we produced this feature, Company A would spend $500,000 on our product.”
Response: “Too bad, we’re already tied up developing features for the next 12 months.”
While this may sound like an extreme case, it’s not too far off what actually happens in many long-term projects. Scrum solves this problem, because with Scrum, your development team can adapt quickly to new changes or requirements.
During a sprint, the development team’s activity is locked down. No new features can be inserted. But since each production sprint consists of a 2-4 week cycle, you can start addressing those needs in the very next cycle.
For example, say your business has a sudden need to accept coupons in your software. That need is entered into the product backlog and the Product Owner prioritizes it at the top. As soon as the current sprint cycle is complete, your development team can begin working on the next production sprint – including the new coupon feature.
