Had to laugh a little bit: Scrum - A process, a framework?
I finally managed to start reading "Software in 30 Days" and just about 2 Minutes in, I came across the "About the Authors" page.
And what do I read:
Jeff Sutherland and Ken Schwaber are the creators of Scrum, a software development process that delivers software functionality in 30-day increments
A little internal laugh occurred, as it is one of the "Key-Mantras" I read over and over again (Scrum Guide, PSM Questions, etc.) that scrum is absolutely not a process, but a framework. My gut feeling also tells me that framework is the more appropriate term.
On the other side in "Scrum - A Pocket Guide" it is stated
If referred to as a process, then Scrum is a servant process
My question:
- As a coach, what are your "official" answers if someone asks you to tell them: What is Scrum?
- And what is your reasoning behind it?
As a coach, what are your "official" answers if someone asks you to tell them: What is Scrum?
It really depends on the context, but I would tend to refer to it as a light-weight framework, where you should (only) add on extra layers/processes if there is good evidence for doing so.
I do this to encourage people to take ownership of their way of working, in the hope that they will understand that Scrum can be useful, but isn't magic; that they will be prepared to throw out the things they don't need; and that they will realise Scrum is probably less bureaucratic than bad organizations, Scrum Masters and Agile Coaches have led them to believe.
I recently just posted an article on my LinkedIn.
https://www.linkedin.com/pulse/award-best-scrum-process-ching-pei-li/
To put it simply,
Scrum is a Framework, not a Process, within which you can employ various processes and techniques. Even for teams in the same organization, the Scrum processes they practice are not exactly the same.
very good practical example @Ching-Pei-Li, nice one !
@Bharath
I am glad that my article is helpful to you.
I usually do this survey for new Scrum Teams.
Take advantage of this simple activity to let them know the difference between the Framework and the Process.
Thank you all for your answers. From my point of view I absolutely agree!
Scrum is a framework providing a set of rules that can be applied. And on top of it you can (may) build a process defining a concrete implementation for a certain team.
The challenge - from my point of view - is to handle the restrictions given by the bigger organization and correctly implement them in a team willing to work in a Scrum environment. Especially in large organisations with a well defined process landscape originally coming from the "industrial era" where the change in the mindset did not fully happen yet.
Me too reading the same book and found at least 3 such different issues so far. Planning to post each of them as a seperate topic.
The challenge - from my point of view - is to handle the restrictions given by the bigger organization and correctly implement them in a team willing to work in a Scrum environment. Especially in large organisations with a well defined process landscape originally coming from the "industrial era" where the change in the mindset did not fully happen yet.
My advice in such a situation would be not to compromise on expressing your views, even if you are tactical in the battles that you pick.
What I mean is, even if the organization doesn't respect Scrum enough to move away from its industrial mindset, you should at least consistently make the case that this approach is competing with, or even invalidating the use of Scrum; and provide as much evidence and transparency around this subject as possible.
That way, it reduces the risk that if Scrum does not deliver the expected results, that everyone within the organization can appreciate that the unsuccessful experiment with Scrum was not the failure of the framework, but of the organization to adapt where necessary.
One of the most powerful, and sadly overlooked statements in the Scrum Guide may help you to spread this understanding:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
@Simon Mayer Thanks for the input!
The statement of the Scrum Guide is very clear in this point and that's why I winch a little bit everytime I hear something like "tailoring" Scrum (and by tailoring I do not mean extending it/defining tools and methods around it, but leaving things out).
Of course you should not dogmatically follow Scrum by the book as it is not the silver bullet fixing all problems (especially as "going agile" on an organizational level often most likely only happens at the point where the "pain" is big enough) and is not applicable everywhere at all.
I assume one should always find the fitting approach for the related situation (maybe Kanban only would fit better, maybe both, maybe something completely different, Lean management or even classical Waterfall) instead of going full Scrum Evangelist and implementing it for the sake of having it.
What is your experience and thoughts regarding "tailored" Scrum?