Is Scrum only a framework?

Last post 05:45 am July 22, 2013
by Ian Mitchell
6 replies
02:48 pm July 17, 2013


I got introduced to Scrum two days ago and began to read about it.
A question: Scrum is a framework and so it is lightweight. However, isn't it also a methodology because defines events and artifacts in detail?
thank you.


05:49 pm July 17, 2013


A methodology is usually very prescriptive and attempts to cover every situation and every possible decision to be made. A framework literally "forces" the user to make some decisions on their own. If you've ever done any coding, think of a framework as an "abstract method", that *must* be implemented by any concrete subclasses. Methodologies are full of "concrete methods" where you'd have no flexibility of implementation -- unless you override it -- and then you're no longer using the methodology because you've modified it.

More here:

08:23 am July 18, 2013

I suppose Scrum could be described as a methodological framework ;-)

However, I think it's more helpful to consider it in terms of its purpose. For example, the Scrum Primer describes Scrum as a "Development Framework". I can see why, but I'm not entirely happy with that definition. I think of Scrum more as a "Delivery Framework".

09:17 am July 18, 2013

very helpful. unfortunately, the link is not accessible. Is it valid?

04:52 am July 19, 2013

Totally agree with Ian on this, describing Scrum as a delivery framework, getting more value produced, regardless how you defined it.
There are so many abstraction illustrating examples to check out there, including Scrum for non-profits, non-IT, defending that idea. (Even experimenting some kind of diet programme using Scrum myself!)
By the way, yes the link given by Charles is working fine.

08:55 am July 19, 2013

Do not over think the subject. The description by Charles was very helpful. Scrum as a framework provides an environment within which complex work can be done. Thinking beyond that, in lean thinking, is called waste.

Now, get on with the tough job of figuring how to do the work.


05:45 am July 22, 2013

Issues such as this can become significant when agile methods are customized and/or configured, so I'm not sure our musings (in this case anyhow) are tantamount to over-thought or waste. It can be important to some people, and to some organizations at certain stages in an agile transformation.

For example: there are teams who use Scrum in combination with XP. Kent Beck has described XP as "a lightweight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements". This seems reasonable, given that XP is rather more thetic than a framework, and prescribes techniques such as test-first, aggressive refactoring, and pair programming. Hence Scrum can be positioned as a framework within which a methodology like XP can be applied.

That's a comparatively straightforward example. Once processes such as PRINCE2, DSDM, SAFe, and DAD are included in the mix (for whatever reason), the importance of defining and anchoring such distinctions can become critical.