Scrum is a "lightweight framework" for iteratively and collaboratively developing complex products. It is typically used to develop software.
Agile is an umbrella term for all the “lightweight frameworks” such as Scrum, Kanban and XP that share common values but decided they didn't like being called lightweight frameworks.
The Agile Manifesto for Software Development states that we value the following:
Nice try but Agile frameworks value doing as much documentation as you need. They just value working software more!
The name originates from an article published in the Harvard Business Review.
The New New Product Game was a study of innovation in the Japanese manufacturing industry and made the following observation:
Jeff Sutherland, the co-creator of Scrum, says in his book "The Art of Doing Twice the Work in Half the Time" that he read this article and wanted to apply the techniques to software development.
Traditional software development approaches (and by that I mean waterfall methodologies) don’t work so well for many projects in today's fast paced world. The idea that you can perfectly capture and document requirements before handing them over to another team to deliver and then handing over to another team to test before handing over to another team to deploy, eventually delivering exactly what the customer wants months after he asked for it just doesn't fit in a technically fluid environment where requirements can change and change again day to day.
Agile and Scrum recognise these challenges and attempt to solve them by (amongst other things) sharing responsibility amongst the team for delivering business value early and iteratively, establishing a feedback loop with your customer/s.
In 10 years time we might all be working for our new Machine Learning Robot Overlords. But if we're not, then we'll probably still be delivering software using Scrum. Scrum isn't popular because it's trendy. Scrum was introduced almost 25 years ago which is roughly the same age as many of the consultants I work with. But Scrum has its roots in Lean manufacturing which originated in the 1980s. And that had its roots in Bell Labs’ “Plan-Do-Study-Act” cycles of the 1930s. So you could argue that these ideas have been around for best part of a century!
Not at all. For starters there are two Scrum bodies, Scrum Alliance and Scrum.Org which use slightly different terminology. My preference is Scrum.org because it is backed by the creators of Scrum! The rules are updated every now and again, to reflect the growing body of knowledge. For example, Scrum.org last updated The Rules of The Game in July 2016.
Scrum is based on observation and experimentation or more formally the principle of Empirical Process Control. Empiricism means working in a fact-based, experience-based, and evidence-based manner. So yes, it’s based on science!
Agile projects are more successful than waterfall projects. Putting it simply, you have more chance or delivering what your customer wants on time within budget with an Agile approach.
The Standish Group measured CHAOS resolution results of both Waterfall and Agile projects from 2002 to 2010.
The Scrum Framework doesn’t solve your problems, but it does increase transparency and makes your problems more visible. It’s then up to you to solve them!
Absolutely. The Scrum Guide July 2016 is 17 pages long and that includes the title page, contents page and a page of acknowledgements! A good Agile Coach or Scrum Master should be able to explain the basics of Scrum in 10 minutes or less!
Easy to understand but difficult to master, like chess or arm-wrestling an octopus.
Read The Scrum Guide!
In addition, there are lots of training courses out there which give a fundamental understanding of Scrum in two days. And if you work in Business Intelligence or Analytics, Keyrus have a two day “Scrum for Business Intelligence” course just for you! To learn more, register for our next course beginning on the 18th October here.
Duncan Maddox, CSM, PSM II