The most curious case of the thing called “Scrumble”


Scrumble — a strange event from the Nexus framework for Scrum that not many people know about.

A bit of a backstory:

  • I’ve found the mention of Scrumble on Ken Schwaber’s post on the 28th of September 2015. Strange that it did not get more coverage up to the point when it has been mentioned here, on the Nexus Practices website. Unfortunately, I cannot pinpoint the date when it has been mentioned on the Nexus Framework Scrum Org site.

In short — as far as I understand it — the Scrumble is a type of a STOP event in the Nexus framework that stops the whole Nexus and is supposed to give teams time to think & modify some aspects of their work before getting back to the Nexus rigor.

It… kind of makes sense.

Just think about it — if something is not working then what is the point of pushing forward?

In business, it’s just risky. Every hour in every day of the work month costs money..

Just consider the simple cost of paying the people for the work done or other costs such as the missed opportunity cost because instead of doing Y the people were still pushing X.

Or maybe not, and if that’s the case then unless your surname spells Wayne, Stark or McDuck, which were fictionally superbly rich, then I think there’s a good chance you’d rather ponder deeply about investing resources into a lost cause.

Everything costs and budgets are usually limited to some extent. If one gets lucky or is really good at negotiations, the company, department, or team may get some more funding. Or maybe they have some reserves that they can use.

Of course, in some contexts, this type of strategy might make perfect sense as in working on prototypes, R&D, or trying to push the new experimental product to the market. But let’s put those things aside for a moment as exceptions are not a point of this note.

Thus I’d say — try using the idea of Scrumble mechanism if you feel that things aren’t going right for you and your business. Press “Pause” on the Scrum tape for a moment, reevaluate the next best step and correct your course if necessary.

Take your time, evaluate what is going on, weigh the pros and cons of your current situation and when you are ready — press “Play” on the Scrum tape. Or switch to Flow Management. Or to DevOps. Or to anything else you feel will do the work.

And who knows, maybe after venturing into other approaches lands you’ll find that what you need is Scrum? Up to you.

Scrum advertises inspection and adaptation, transparency, and short feedback loops.

Why not make use of that on a scale smaller than Nexus? Because the Guide tells so?

A document, be it a Scrum Guide or any other manual, telling you what to do with your business and how — that’s funny. No guide of any sort can guarantee success in any type of entrepreneurial activity. Be smart.

OK, so what makes sense right now?

Well, it’s up to you. Your business, Your rules.

Sometimes it may be viable to stop the Choo Choo train on its tracks, regroup, discuss and decide what would be reasonable next steps if the whole process of processes is not working as expected.

Do some calculations, run simulations (Monte Carlo perchance), learn, spread the knowledge and discuss.

After all, any type of business is a unique amalgam of many different factors that are at play. Thus, play smart.

Don’t let the game be over too early because of some rigid guidelines. No one will guarantee that following a document will lead you to success.

That is up to you.

Live long and prosper. Scrum is but a mere tool for you to achieve your goals. It is a means to an end, not the end itself.

Find your own way. Experiment.

And who knows, maybe one day other people would also prosper because of your learnings?

I’d love to see that happen.

I’m a DevOps & Process expert and a business practitioner. I also study into facilitation & collaboration & many things related to science.