When I first started using Scrum, I was really excited about all the new possibilities it presented, and I thought that everybody would share that excitement. After some years, I realized that this is not the case. In most of the teams I have been in, it is actually the opposite. The teams had some bad experiences with the framework and refused to continue with it. For those teams that accepted Scrum, it was only a matter of time before they began having more conversations about processes and tools than about the product and customers. At some point our goal became to apply the best Scrum possible instead of focusing on how to satisfy the demands of our customers.
After some time, I realized that the problem might be that even though Scrum is a well-accepted framework, it has been changing for the past several years. For example, in 2011 we got a first draft of Scrum, which changed by 2013
. During that time, people wrote many articles and books but then didn't update them. As time passed, there were a great number of new articles suggesting best practices, tools, methods, etc. There are so many differences even between ScrumMasters that today there are different opinions about what we should do and how. These differences create disagreements among teams, and the risk exists that you will spend a lot of time discussing the framework instead of new ways to bring value to the customer. If this happens, then you will be activating (without noticing) a new process by which your Scrum implementation will slowly die.
To solve this problem, at one of the companies where I used to work we decided to free the team from all these discussions. The idea was to create a new framework based completely on Scrum. Since the framework was "new," there was no way to compare it with other frameworks. And also because it was new, we were safe to modify it and adapt it to our needs. The results were pretty good. We didn’t have any long discussions, and during the retrospectives, we got new ideas to improve our process. We were still using Scrum, but we were thinking about it in a different way.
The framework was called Chef, and it was, as I said, only a layer above Scrum — in fact, you could call it a facade. To start, we imagined that the company was a restaurant, the business owners were people ordering dishes, and product and development were the chefs cooking the food. The process was really simple.
The business owners and product owner (PO) presented a list of the best dishes (those that would bring more customer satisfaction) to the team. The team analyzed them and created recipes, showing how they would solve any problems. The PO, with help of the team, chose the best recipes and placed them in the sprint backlog. Then the team "cooked" for two weeks and presented their dishes in a special "tasting" meeting.
Below is a one-to-one mapping of the "tasting meetings" to the Scrum events:
- Menu meeting (planning meeting in Scrum, part one). In this meeting, the PO presented the dishes.
- Recipe creation (planning meeting in Scrum, part two). During this meeting, developers created recipes (solutions to the problems) and estimated size. When they were finished, they called the PO and started the recipe evaluation.
- Recipe evaluation. PO, developers, and sometimes business owners decided which recipes were the "best" and should be cooked. Based on previous iterations, the developer forecasted how many dishes they could cook in reality.
- Cooking. Developers started developing for one sprint. We also used daily stand-ups.
- Tasting (sprint review in Scrum). When the sprint was over, we showed our dishes to the stakeholders, and we decided whether we were going to go live.
- Meal retrospective (sprint retrospectives in Scrum). During this meeting, the opportunity to change the way we work, even the framework, was emphasized.
- Kitchen clean-up. Developers had time to clean the code or improve things that they had not done so well.
You will notice that the tasting meetings are similar to the Scrum meetings. The main change was that, in our minds, we were thinking about dishes and recipes and not about something abstract like Scrum. This made the exchange of ideas much easier. Moreover, we were confident about trying new things, because there was no right or wrong; it was our method, and we were trying to improve it to get better results.
If you are already on a team that likes Scrum and is performing well and having fun, then you might not need to try this. But if you are having problems and you want to bring Scrum back to life, maybe the best thing to do is to let it die first, and then bring it back to life by using a new name or metaphor. Try something unique that shows the team that it is all about them building products and giving value to the customer, and not about doing "perfect" Scrum.