Five years ago, the term, “Scrum-But” became popular. This phrase pointed out the gap between just using Scrum-and building great products with Scrum. I would ask someone if they were using Scrum. They would respond, “We use Scrum, but we can’t always complete all the regression testing within a Sprint, so we often have regression testing spill over into the next Sprint.” Or, they might say, “Yes, we use Scrum, but we are a dispersed team, so we have the Daily Scrum whenever it works best, and often that is only several times a week.”
I’d like to change this phrase from Scrum But to Scrum And. The new wording might be, “We use Scrum and we are continuously building, testing and deploying our increments every Sprint,” or “We use Scrum and we are collaborating and brainstorming within the Scrum Team to increase Value every Sprint.”
We are developing a Scrum-And framework At the most basic level, the question is: Are you using Scrum or not (as defined in the Scrum Guide (www.scrum.org/guides). Scrum And is then a path of continuous improvement in software development beyond the basic use of Scrum. Equating the Scrum framework with the framework for chess, this is determining how good a product development organization you are just like determining how good of a chess player you are.
In Software in Thirty Days (Jeff and my new book), we map ways in which Scrum can be deployed. These are:
The Scrum And framework is mapped onto this deployment mapping as follows
Starting with the Stacey graph, four threads of improvement beyond the framework are Scrum,Technology, People, and Business (domain). Organizations would probably improve in each thread at a different pace. Improvement in an organization’s skills in each thread would drive them from the basic Scrum usage to further stages. We expect that metrics such as productivity, quality, value, ROI, and total cost of ownership could be measured at each level.
Work is just beginning in Scrum.org and with its partners. When this is done, it should significantly supplement our Implementation Playbook. It should provide a guide for organizations that want to know how to start and how to improve their product and software development skills. This fits with Scrum.org’s mission, “Improving the profession of software development.”.
We will let you know when usable sets of this framework are available.
Ken
Ken Schwaber's Blog: Telling It Like It Is 
Well done Ken. I sometimes use Scrum–, Scrum-, Scrum, Scrum+ and Scrum++ to think of Scrum teams in terms of evaluating them against the Framework. Anyone doing ScrumBut(with a significant But of course) has a minus, and anyone who is doing Scrum but also adding good technical practices has a plus.
Funny, the difference between my way of thinking is more from my development background, and you have wisely chosen to cater to your audience — managers. Good work!
(Note that I’m not in any way suggesting a different “plus” system than what Ken has written about above — just sharing a personal observation/comment.)
@Charles – Interesting… I too have used the Scrum+/- before. VERY cool. 🙂
Cool. Probably just my programmer background…
Hi Ken,
Congratulations to you and Jeff for another excellent book. I can’t wait to read it in the coming days and discuss it with our Agile Vietnamese Community.
Regarding the new phrase, “Scrum And”, I also think about, “We use Scrum And we also combine it with other …”, because Scrum in short is “AWESOME”, but depending on the project, I believe it can also be combined with other Agile practices (e.g. elements from Kanban, etc..) to maximize business value, etc.. An example of that is WIKISPEED (www.wikispeed.com); at WIKISPEED we use Scrum combined with Lean and other Agile practices such as XP to manufacturer affordable road-legal vehicles. I think one of many great examples of combining “Scrum And”… something else :).
Looking forward to your next series of discussions about the new Scrum-And framework.
Sincerely and best regards,
Alex Rosales
Hi Ken,
Nice to read this thought!
I have worked on similar thought and created a decision matrix to identify whether it’s a ScrumBut or ScrumAnd.
Please find below the URL of my paper:
http://ieeexplore.ieee.org/search/freesrchabstract.jsp?tp=&arnumber=6139625
Vinay
What happened to “work?” Nobody collects royalties on it, or can sell rights to “Working For Dummies” I suppose.
I am facing a lot of but as we are a system integrator with always fixed cost projects and very rigid functional roles, also there is a big experience gap between team members that requires someone to for example write the SRS alone then work with another team working in parallel sprint, what do u suggest?
The backlog clearly lasts for the life of the product. There is a reasonable assumption that a product owner will own a product throughout its lifetime (or at least through several releases). Is there a similar assumption about the rest of the development team, that the same team (or largely the same team) would continue to work future releases? Certainly ScrumMasters could (perhaps should) move from team to team to cross-pollinate. In a matrixed project style, sometimes the entire team is new for each project. Different features may require diferent skills. Should the Product Owner generally try to retain the team?
The same development team(s) with the relationship and trust of the product owner would be greatly effective. Switching people, teams, and trust loses a lot, even though it is frequently done.
Best,
Ken
Pingback: Ken Schwaber, an Agile Avenger Fighting Against Waterfall « Indie Code
Love this – using Scrum as the core, then adding or removing layers. I can’t wait to share it! 🙂
Pingback: Minimum Requirements for Agile | Development Block
Nice post, Ken.
I’ve read your book Software in Thirty Days and it’s awesome. Anyway – the concept of Studio looks for me very similar to the concept of PMO (Project Management Office). Providing policies, templates, coaching etc.
Am I right or missed anything?
Hi Ken. The Scrum-And concept is just what I was looking for – because there are some regulations that can`t be met by pure scrum (i.e.: independence of quality assurance).Better to build a Scrum-And than to leave those poor projects to waterfall. I would love to contribute to your work.
Still, I don`t think that Scrum-But is really replaced by Scrum-And. Many Scrum-Buts change Scrum so much that it looses its agile spirit.
Regards,
Markus
I think “scrum, and” has some value but I wouldn’t say you’re replacing, as there is rampant “Scrum, but” meaning the “cherry picking” of concepts that are convenient and palatable. I use a cooking metaphor – you know what lobster bisque is, and if you don’t have a dash of sherry, it’s still lobster bisque. But if we use skim milk, is it bisque? What is we sub crab-flavored white fish? At some point it ain’t lobster bisque anymore regardless of perception
This is the point of Agility. It is supposed to allow cherry picking.
Scrum Agile.
Agile = “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.”
and:
“Individuals and interactions over processes and tools”
and:
“Responding to change over following a plan”
A great idea (a truth) has been commercialized.
My wife makes Reubens with tuna. Always has. Grew up that way. Doesnt know any different. I don’t call that a Reuben, but why do I need to fear her doing so?
Cherry picking or creating one’s own process is okay, if it is done within the spirit (values and principles) of the Manifesto for Agile Software Development and it is not promoted as something that it is not.
One problem that arises is that many organizations make the statement that they are using Scrum which conveys a specific meaning to many people. When reality doesn’t match the expectation, there is discord. The biggest tenant of Transparency in my opinion is “A common language referring to the process must be shared by all participants.” This is lost when you call a flamingo a duck; both birds but quite different. This is often a situation created by the situation described below.
Another problem is that organizations will create their own “Scrum” in order to feel comfortable. They change it fundamentally and have no clue of the value that is being lost. Changing the Daily Scrum event to a standard status report and making it weekly, changing the Sprint Review event to a simple internal demo where the ProJEct Manager (maybe called a Product Owner) signs off on features, changing the Sprint Planning event to be a classic assignment meeting run by a technology manager, not working with customers throughout the process and continuing a quarterly release cycle, etc. So much value is lost through ignorance and fear of real change.
From a technical perspective, ask a .NET developer what would happen if they tried to code in a way that was contrary to the framework that Microsoft has provided. Inconsistent behavior, more errors, less sustainability, more chaos.
Building a product or system is so difficult that you wonder why they spend any time fiddling with a proven, simple framework.
Pingback: Scrum Plus: Agile Heresy No More! » Agile Scout
Pingback: ‘Scrum And’ term coined | Content Presenter
Pingback: Blasphemy! They Call It Scrum! » Agile Trail
Pingback: Scrum . . .A Simple Framework: Barnacles | Software Process and Measurement
Pingback: Cadena de valor, fricción, impedancia y deuda en empresas Ágiles (II) |
Pingback: Post-Agile Age: Proscriptive Norms | Software Process and Measurement
Pingback: Podcast 26 – Agilidade morreu? | Blogs da Lambda3
Scrum always needs the “And” to produce anything; it’s a framework. The problem is that in the corporate environment the word “but” has simply been replaced with “and” in conversation. Management 2.0 includes a false sense of improved collaboration. In conversation, managers are taught to say “and” instead of “but” to put a positive spin on statements. “I like your idea of painting it blue and we should paint it red so that it is brighter.” An attempt at softening the blow while not truly having an open conversation. In the context of Scrum it works similarly. “I like your idea of testing in every Sprint and we should have a hardening Sprint to create quality.” Late to the party, but that’s just my two cents.
Pingback: Lambda3 Podcast 26 – Agilidade morreu? | Lambda3
Pingback: Można modyfikować Scruma. Ale czy warto? Recenzja książki "Successful ScrumButt". | Piotr Wegert
Pingback: Projecten aansturen zonder wendbaarheid te verliezen
Pingback: Authentic 7Lab Pharm
Pingback: The Big Tent of Agility | Craig Smith