Scrum for Lay People – Part 1


From the outside, the main goal of Scrum is to delight customers through early and continuous delivery of high value software. From the inside, at the software team level, Scrum is an iterative software development process that empowers teams to self organize their work, while at the same time providing a framework for the team to self improve. Customers to Scrum Teams can be end users, internal users, marketing personnel, or any other person not on the Scrum team itself, who has a stake in the software that is being developed. Scrum is a process that works in short cycles, or mini-projects, of 2-4 weeks, with software deliveries that occur every 2-8 weeks.

Self Organization

While no one member of the Scrum team has authority over any other member(self organization), there are three explicit roles that define specific responsibilities. One might think that self organizing teams might be prone to laziness, lack of direction, or gridlock, but Scrum Teams are still held accountable, as a team, by those (outside of the Scrum Team) who pay their salaries and/or fund their budgets.

Framework for Optimization

Scrum is considered a framework more than a process, meaning that Scrum provides a strong framework of practices, but also leaves a lot of room for team customization and optimization within the framework. The Scrum framework is probably best defined by a document called The Scrum Guide, written by the creators of Scrum. While only roughly twenty pages, the document is extremely dense with principles, rules, and practices. As an aside, many people have successfully “lifted” Scrum concepts for use in places other than software development. While some of the concepts transfer readily, others, like delivering a fully functioning, new version of a product, every 2-8 weeks, do not.

Empirical Process

Many previous software development processes were modeled after large scale construction or manufacturing processes, which are defined processes. Defined processes are ones where the inputs and outputs are generally fairly known and repeatable. Scrum is based on empirical processes like custom made items or research and development, where the inputs and outputs are not as perfectly defined or repeatable(usually due to complexity). As such, often no two outputs look exactly alike. Think of a house that is totally pre-built and ready to move into (known as a Spec House), versus a house that is custom built from the ground up based on customer input. The custom built house is the software features that Scrum teams produce. Moving to an empirical model means that Scrum teams are no longer thought of as assembly lines, but more as teams of creative knowledge workers that produce a custom made software product.

The Name

The name Scrum was picked as a metaphor to symbolize the team effort in the sport of Rugby. This team effort is one where the entire team works closely together, all of the time, to move the ball down the field and score. The team is one where individual positions and specialties matter much less, and the overall team accomplishment matters much more.

The Real Value of Scrum

Because Scrum is based on relatively short cycles that occur dozens of times a year, the Scrum Team has dozens of re-tooling points at which to improve, based on the built-in Scrum feedback loops. As such, there is ample anecdotal evidence that Scrum greatly improves both value delivered to the customer, as well as software team efficiency. Some evidence points to mature, hyperproductive Scrum Teams that achieve 200-400% and even higher productivity gains. Further, many Scrum teams experience much improved morale as team members have full authority over how they work, as well as full authority over how they explore new software approaches and technologies.


4 Responses

  1. Do you have any evidence of projects that used Scrum where the customers were “delighted”?

    Where is your evidence that scrum teams are 200-400% more productive?



    Now, before you go knocking the evidence, I didn’t say it was proof. I said it was some evidence. While anyone can question any metrics/statistics, there is some fairly solid data behind these.

  3. While I can’t vouch for the huge productivity increase I can say the introducing Scrum at my last workplace saved us many times over. After working for years without much of a structured process we would have failed when the pressure and workload increased.

    Scrum gave us the tools to handle the increased work load.

    The increased transparency we developed with Scrum helped create happy customers because for the first time they could look inside and see what was happening in the development team.

    • Yashimii,

      Thanks for the comment.

      I can’t really vouch for the productivity increases either. That’s why I was careful to say “Some evidence points to…” . There’s a pretty big difference between evidence and proof, though.

      Like you, I’ve seen teams reach higher productivity, predictability, customer satisfaction, and team morale.

      It would be very difficult to do an apples to apples comparison of a team’s productivity due to the inherit complexity of software development and customer value. It’s almost like you’d have to do a very scientific (or as scientific as you could get) analysis of features delivered and customer value. For the features, maybe something like a function point analysis could be used. For customer value, maybe customer satisfaction surveys or a calculation of business value ROI. I’m not sure as to the proper technique as this kind of comparison is not my forte.

      Anyway, thanks for the thoughts.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: