November 23, 2017 at 11:30Scrum is not only in development - we use a flexible methodology in organizing an IT festival for children and parents
Probably, on Habré there will not be a person who has not heard about Scrum - the most popular methodology for managing software development in our time. The abundance of publications from "coaches", companies that are just starting to work on the principles of Agile, or have already tried them in practice, project managers and ordinary developers, satisfied and displeased, loving and hating Scrum with all our hearts, we have read them all more than once.
Usually, when speaking about Scrum, people only talk about software development, but today Kodabra will tell you something unusual, we will tell you our experience of using a flexible methodology to “develop” a real offline event with live people instead of code, venues instead of servers and most demanding audience - children. This is a story about an unusual approach to organizing the largest digital technology festival for children and adolescents in Russia - Digital Fest 2017 .
A reasonable question that comes to the mind of an inexperienced reader - why do we need Scrum in such a remote question from the development of the event? And why are there any methodologies, principles, frameworks here? It would seem that he leased the site, agreed with the speakers, sold tickets - and the thing is in the hat, sit count the money. But not so simple. People who at least once tried their hand at organizing something more than a home party will not let us lie - if more than 3 people plan to attend your event, then everything will go wrong and you will have to change all your plans on the go . And the more the idea, the more chaotic the tasks of its implementation take on. Just like in the development of a complex product - there is only a goal and its global vision, but nobody knows how it will be achieved, even the author of the idea. The farther, the more there are analogies with product development. We also thought so and decided to dig deep into.
Contrary to established stereotypes, Scrum is not necessarily about writing software. Yes, this is the most common, demanded and best-studied field of application, but it is far from the only one, it’s enough to recall the story, because Scrum began as a way to increase the efficiency of the production of copy machines. In fact, this methodology has infinite variability of application due to its moderately abstract, but at the same time sufficiently precisely formulated terms and strict principles. Needless to say, if Jeff Sutherland himself, one of the founders of the methodology, in his book “ Scrum. The revolutionary project management method", Presents it precisely as a universal solution for managing projects, from the weeding of beds to the colonization of Mars. In Codabre there are beds only with talents growing on them, and our duty is to open the whole universe to them, so we fit perfectly into the world of Jeff Sutherland and tell you how to use Scrum, even if you are not an IT company and do not do software.
Romance is romance, but like any business, our goals should be purely pragmatic. For us, Digital Fest is one of the most important sources of attracting a new audience and an ideal platform to demonstrate our capabilities. That is why we are so serious about the organization - we are making our real product. This product has a fixed release date and, perhaps, this is the only thing that distinguishes it from the classic project developed as part of Scrum.
We draw the remaining analogies.
Scrum is based on a sprint. From 2 to 4 weeks in the classical paradigm for software development, 1 week maximum in our case. This sprint length was chosen both because of the limited time for the sale of the product, and because of the excessive dynamics of the process caused by the human factor and the great involvement of third parties in the process.
Custom Stories aka “user story” are the real goals of your sprints. Scrum strongly discourages development for the sake of development and “tech. duty "as such. Fortunately, in real-world problems such concepts are almost completely absent, so we can focus exclusively on solving problems related to the needs of visitors to our event, one at a time.
The team is our "developers". They do not write in C and do not scale databases under high loads; they talk with people. When you are organizing a festival, 99% of your tasks begin with the word “agree”. Only areas in which you need to agree on something with someone vary, but the essence, as a rule, remains unchanged. An agreement is equated to a solved task. The speaker agreed to speak or hold a master class - a sticker in the “done” column, agreed with the contractor in price - another sticker in the coveted column, and so on. Your team can and should be good in itself, but it is Scrum that will make its work as efficient as possible.
Each sprint of our team is based on one or several main user stories that represent the needs of each group of festival visitors - children, parents, adolescents. We classify these three main groups into subgroups and describe in stories what they want to receive from the festival. For example, consider our classic group of children.
Children who come to the festival can be divided into several groups:
1. “Gamers” - are fond of games and want to learn more about them, including how they are made.
2. “Enthusiastic" - these guys have already tried to program themselves or in Kodabr, they want to prove themselves and show what they have learned.
3. "Advanced" - they already know exactly what and why they are doing and want to acquire new knowledge or meet like-minded people.
4. “Nothing is interesting / Parents brought” - A complex group from which children are quickly “converted” to one of the previous ones, and parents are divided into groups for parents.
It’s not hard to guess, all these groups behave differently, expect something different from the festival, and each of them needs a special approach. We take this into account and begin to create specific organization tasks based on these “user stories” that will be included in sprints. Fulfillment of all tasks will mean that we have satisfied the needs of all the groups of our “users” and, accordingly, the festival will be successful.
User stories are very important, but no matter how well you describe them and no matter how you think up the first sprint, it will fail. Even if you have the coolest scrum master in the city, your team will fail the first sprint, you need to accept it right away. It's not your team, let it understand Scrum principles well and have worked with a lot of similar projects before, anyway you will fail the first sprint. Because the organization of an event is a project in which the first sprint must fail.
Programmers, and, in general, people of technical professions, love to extrapolate their experience to other areas, on the basis of this to predict the development of events in one case or another, and often, in the end, will benefit. But not in this case. Organizing events has more in common with roulette than with poker. Your knowledge and professionalism often do not solve anything here, because each time you will start from scratch. That is why the first sprint is needed - to determine the vector of work. After the first sprint, you will understand the current state of the players and market conditions and will be able to create a strategy for the current event. You will have to completely change the work plan after the first sprint, but for this you need Scrum - even after losing once, you can easily adapt and continue to work.
Scrum has another very important tool that will make it easier for you to cope with failures and better build your sprints - a retrospective. Never ignore the retrospective, especially when working with such an unpredictable environment as agreements with real people. Even the most confusing code is more predictable than the speaker with whom you planned to speak at 11 a.m. Especially if this speaker also writes confusing code the rest of his time;)
The most important question of any project manager is when is the release? But there is a question even more important - and what, in fact, will we release? As you remember, our product is a whole festival, it does not fit into an RPM package and it cannot be sent to a remote server, so the readiness criterion is not so clear with us. If you started to prepare for the event in advance, your team may have a false feeling that “launching the product” == “opening the doors of the festival”, but this is not so. You have to understand that everything that you did before this is just preparation, no matter how much effort and time you spend on it, but all these actions were performed only to ensure that the event itself took place without a hitch. The last sprint of the project will be unusual for Scrum - it will be very short and very eventful, because the last sprint is always the event itself.
There may be two options for the development of events:
1. You were not very strong in organization. Then you have to improvise all the time and use the maximum amount of available resources.
2. Your Scrum was good and your team did everything according to the textbook. In this case, you will walk and look at everything with a pleased smile.
Of course not, option No. 2 does not exist in nature, but this is not a reason for despair. Just try to organize your last sprint with the maximum benefit, based on previous experience and retrospectives. We will do just that in Codabra at Digital Fest 2017 , and we urge you to come and personally evaluate how effective our Scrum has been!
Usually, when speaking about Scrum, people only talk about software development, but today Kodabra will tell you something unusual, we will tell you our experience of using a flexible methodology to “develop” a real offline event with live people instead of code, venues instead of servers and most demanding audience - children. This is a story about an unusual approach to organizing the largest digital technology festival for children and adolescents in Russia - Digital Fest 2017 .
Why Scrum without software?
A reasonable question that comes to the mind of an inexperienced reader - why do we need Scrum in such a remote question from the development of the event? And why are there any methodologies, principles, frameworks here? It would seem that he leased the site, agreed with the speakers, sold tickets - and the thing is in the hat, sit count the money. But not so simple. People who at least once tried their hand at organizing something more than a home party will not let us lie - if more than 3 people plan to attend your event, then everything will go wrong and you will have to change all your plans on the go . And the more the idea, the more chaotic the tasks of its implementation take on. Just like in the development of a complex product - there is only a goal and its global vision, but nobody knows how it will be achieved, even the author of the idea. The farther, the more there are analogies with product development. We also thought so and decided to dig deep into.
Contrary to established stereotypes, Scrum is not necessarily about writing software. Yes, this is the most common, demanded and best-studied field of application, but it is far from the only one, it’s enough to recall the story, because Scrum began as a way to increase the efficiency of the production of copy machines. In fact, this methodology has infinite variability of application due to its moderately abstract, but at the same time sufficiently precisely formulated terms and strict principles. Needless to say, if Jeff Sutherland himself, one of the founders of the methodology, in his book “ Scrum. The revolutionary project management method", Presents it precisely as a universal solution for managing projects, from the weeding of beds to the colonization of Mars. In Codabre there are beds only with talents growing on them, and our duty is to open the whole universe to them, so we fit perfectly into the world of Jeff Sutherland and tell you how to use Scrum, even if you are not an IT company and do not do software.
Festival as a product
Romance is romance, but like any business, our goals should be purely pragmatic. For us, Digital Fest is one of the most important sources of attracting a new audience and an ideal platform to demonstrate our capabilities. That is why we are so serious about the organization - we are making our real product. This product has a fixed release date and, perhaps, this is the only thing that distinguishes it from the classic project developed as part of Scrum.
We draw the remaining analogies.
Scrum is based on a sprint. From 2 to 4 weeks in the classical paradigm for software development, 1 week maximum in our case. This sprint length was chosen both because of the limited time for the sale of the product, and because of the excessive dynamics of the process caused by the human factor and the great involvement of third parties in the process.
Custom Stories aka “user story” are the real goals of your sprints. Scrum strongly discourages development for the sake of development and “tech. duty "as such. Fortunately, in real-world problems such concepts are almost completely absent, so we can focus exclusively on solving problems related to the needs of visitors to our event, one at a time.
The team is our "developers". They do not write in C and do not scale databases under high loads; they talk with people. When you are organizing a festival, 99% of your tasks begin with the word “agree”. Only areas in which you need to agree on something with someone vary, but the essence, as a rule, remains unchanged. An agreement is equated to a solved task. The speaker agreed to speak or hold a master class - a sticker in the “done” column, agreed with the contractor in price - another sticker in the coveted column, and so on. Your team can and should be good in itself, but it is Scrum that will make its work as efficient as possible.
User stories are the foundation of everything
Each sprint of our team is based on one or several main user stories that represent the needs of each group of festival visitors - children, parents, adolescents. We classify these three main groups into subgroups and describe in stories what they want to receive from the festival. For example, consider our classic group of children.
Children who come to the festival can be divided into several groups:
1. “Gamers” - are fond of games and want to learn more about them, including how they are made.
2. “Enthusiastic" - these guys have already tried to program themselves or in Kodabr, they want to prove themselves and show what they have learned.
3. "Advanced" - they already know exactly what and why they are doing and want to acquire new knowledge or meet like-minded people.
4. “Nothing is interesting / Parents brought” - A complex group from which children are quickly “converted” to one of the previous ones, and parents are divided into groups for parents.
It’s not hard to guess, all these groups behave differently, expect something different from the festival, and each of them needs a special approach. We take this into account and begin to create specific organization tasks based on these “user stories” that will be included in sprints. Fulfillment of all tasks will mean that we have satisfied the needs of all the groups of our “users” and, accordingly, the festival will be successful.
The first sprint is lumpy
User stories are very important, but no matter how well you describe them and no matter how you think up the first sprint, it will fail. Even if you have the coolest scrum master in the city, your team will fail the first sprint, you need to accept it right away. It's not your team, let it understand Scrum principles well and have worked with a lot of similar projects before, anyway you will fail the first sprint. Because the organization of an event is a project in which the first sprint must fail.
Programmers, and, in general, people of technical professions, love to extrapolate their experience to other areas, on the basis of this to predict the development of events in one case or another, and often, in the end, will benefit. But not in this case. Organizing events has more in common with roulette than with poker. Your knowledge and professionalism often do not solve anything here, because each time you will start from scratch. That is why the first sprint is needed - to determine the vector of work. After the first sprint, you will understand the current state of the players and market conditions and will be able to create a strategy for the current event. You will have to completely change the work plan after the first sprint, but for this you need Scrum - even after losing once, you can easily adapt and continue to work.
Scrum has another very important tool that will make it easier for you to cope with failures and better build your sprints - a retrospective. Never ignore the retrospective, especially when working with such an unpredictable environment as agreements with real people. Even the most confusing code is more predictable than the speaker with whom you planned to speak at 11 a.m. Especially if this speaker also writes confusing code the rest of his time;)
Readiness criterion
The most important question of any project manager is when is the release? But there is a question even more important - and what, in fact, will we release? As you remember, our product is a whole festival, it does not fit into an RPM package and it cannot be sent to a remote server, so the readiness criterion is not so clear with us. If you started to prepare for the event in advance, your team may have a false feeling that “launching the product” == “opening the doors of the festival”, but this is not so. You have to understand that everything that you did before this is just preparation, no matter how much effort and time you spend on it, but all these actions were performed only to ensure that the event itself took place without a hitch. The last sprint of the project will be unusual for Scrum - it will be very short and very eventful, because the last sprint is always the event itself.
There may be two options for the development of events:
1. You were not very strong in organization. Then you have to improvise all the time and use the maximum amount of available resources.
2. Your Scrum was good and your team did everything according to the textbook. In this case, you will walk and look at everything with a pleased smile.
Of course not, option No. 2 does not exist in nature, but this is not a reason for despair. Just try to organize your last sprint with the maximum benefit, based on previous experience and retrospectives. We will do just that in Codabra at Digital Fest 2017 , and we urge you to come and personally evaluate how effective our Scrum has been!