When we apply Ken Schwaber’s principles of Scrum to Scrum itself, it stops being a process framework. Instead, it becomes a platform. And we are making it.
People define Scrum as a process framework for product development, consisting of a minimal set of immutable roles, artifacts, and events, accompanied by some strict constraints. Five years ago, in his blog post, “What comes after Scrum?” Ken Schwaber listed four principles that will be necessary for any process framework to replace Scrum:
As Ken Schwaber wrote, the people who do complex work are best capable of managing themselves. In my opinion, this includes management of the processes they use. There is no difference between the practices defininga framework and the practices insidethe framework. They are all processes. Why would some of them be “immutable”? Creative workers need easy access to thousands of good practices, from many sources, with which they can grow their own custom-made processes. Self-organization should be applied to the framework itself. This means: everyone is empowered to make a custom framework. With Mind Settlers, we are enabling that.
Creative workers often make better decisions than managers about the work that they do. Work environments are unpredictable. Therefore, nobody can say which processes will be best for the work that must be done tomorrow. So, why would anyone adopt a framework that places strict constraints on the work processes inside it, using assumptions that may not be valid anymore tomorrow? The safest assumption is that everything changes all the time. The evolution of the process framework itself should embrace many twists and turns. In Mind Settlers, we will offer that.
Instead of making bad predictions about the future, it is best when people continuously evaluate what they accomplished and then decide what to do next. This applies to the product that they are building because nobody can accurately anticipate which product features their customers need next. But a process framework is a product too! Why would people strictly define three roles, three artifacts, and five events that every creative team will need in the future? It is best to have work processes emerge using iterations, feedback, and data. We are working on that.
To make good decisions, you need better information. In product development and project management, this means giving everyone access to data about the features that have been delivered, the work that is in progress, and the ideas that are still under evaluation. If transparency works for products, it should also work for frameworks. This means that users want information about results achieved with delivered processes, new processes in development, and ideas for future processes. We can offer that already.
Strangely enough, few people have realized that the Scrum framework is itself just another product. We can (and we should) apply the Scrum principles to Scrum itself. However, when we do so, we inevitably conclude that the framework stops being a static framework. Scrum applied to Scrum means: #NoFrameworks. Rather, it becomes a dynamic ecosystem in which all processes are offered by self-organizing teams, are emerging bottom-up, are subjected to empirical evidence, and are shared among the community with full transparency. The result is a platform, not a framework. We are developing it.
Five years ago, Ken Schwaber wrote that he would welcome any process that can do everything better than Scrum.