Scrum is not only in development - we use a flexible methodology in organizing an IT festival for children and parents
Probably, there is no person on Habré who has not heard about Scrum - the most popular methodology of software development management in our time. The abundance of publications from coaches, companies just starting to work on the principles of Agile, or project managers who have already tried them in practice, and ordinary developers, satisfied and dissatisfied, who love and hate Scrum with all their hearts, have read them all more than once.
Usually, speaking about Scrum, people talk only about software development, but today Kodara will tell something unusual, we will tell you our experience of using flexible methodology for “developing” the most real offline event with real people instead of code, platforms instead of servers and demanding audience - children. This is a story about an unusual approach to the organization of Russia's largest digital technology festival for children and teenagers - 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 as the organization of an event? And why are there any methodologies, principles, frameworks? It would seem that he rented a platform, arranged with the speakers, sold tickets - and the trick is done, sit and count the money. But not everything is so simple. People who have tried their hand at organizing something more than a home party at least once will not let us lie - if more than 3 people plan to take part in your event, then everything will go wrong and you will have to change all your plans on the go . And the more the venture, the more chaotic the nature of the task of its implementation. Just like in the development of a complex product - there is only a goal and its global vision, but no one knows what way it will be achieved, even the author of the idea. The further, the more is the analogy with the development of the product. We also thought so and decided to dig deep.
Contrary to well-established stereotypes, Scrum is not necessarily about writing software. Yes, this is the most common, sought-after and best-studied application area, but it is far from the only one, it’s enough to remember the story, because Scrum began as a way to improve the efficiency of the production of copying equipment. In fact, this methodology has an infinite variability of application due to its moderately abstract, but at the same time quite accurately 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 as a universal solution for project management, any, from weeding the beds to the colonization of Mars. Kodabar has beds only with talents growing on them, and our duty is to open the whole universe for 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 make software.
Romance is romance, but like any business, our goals should be purely pragmatic. Digital Fest for us is one of the most important sources of attracting new audiences and an ideal platform to demonstrate our capabilities That is why we take the organization so seriously - we make our real product. This product has a fixed release date and, perhaps, this is the only thing that distinguishes it from the classic project being developed within Scrum.
Let's draw the other analogies.
The basis of Scrum is the sprint. From 2 to 4 weeks in the classical paradigm for software development, 1 week maximum in our case. This length of the sprint was chosen both because of the limited time frame for the sale of the product, and because of the excessive dynamics of the process caused by the human factor and the large involvement of third parties in the process.
User stories aka "user stories" are the real goals of your sprints. In Scrum, development for the sake of development and “those. debt "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 the database under high loads, they talk to people. When you are organizing a festival, 99% of your tasks begin with the word “agree”. Only the spheres in which it is necessary to negotiate with someone about something vary, but the essence, as a rule, remains unchanged. The agreement is equal to the solved problem. The speaker agreed to speak or hold a master class - a sticker in the “done” column, agreed with the contractor on the price - another sticker in the treasured 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, teenagers. We classify these three main groups into subgroups and describe in the stories what they want from the festival. For example, consider our classic group "children."
Children coming to the festival can be divided into several groups:
1. “Gamers” are addicted to games and want to learn more about them, including how they are made.
2. "Hobby" - these guys have already tried to program themselves or in Kodabra, they want to express themselves and show what they have learned.
3. "Advanced" - 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 in” - A complex group from which children are quickly “converted” into one of the previous ones, and parents are divided into groups for parents.
As it is not difficult to guess, all these groups behave differently, they expect from the festival something of their own, and each of them needs a special approach. We take this into account and begin to create specific tasks for the organization on the basis of these “user stories”, which will be included in the sprints. The fulfillment of all tasks will mean that we have satisfied the needs of all 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 much you think through the first sprint, it will not succeed. Even if you have the coolest scrum master in the city, your team will fail the first sprint, you need to take it right away. It's not about your team, even if it understands the principles of Scrum well and has worked before with many similar projects, you still fail the first sprint. Because the organization of the event is a project in which the first sprint must be failed.
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 way or another, and often turn out to be the gainers. But not in this case. Event organization has more to do with roulette than poker. Your knowledge and professionalism often do not solve anything here, because every time you start from scratch. It is for this that 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 the market conditions and you can 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 one time, you can safely adapt and continue working.
Scrum has another very important tool that allows you to more easily tolerate 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 am. In particular, if this speaker also writes obfuscated code for the rest of his time;)
The most important question of any project manager is when is the release? But there is a question that is even more important - what, exactly, will we release? As you remember, our product is a whole festival, it does not fit into an RPM package and cannot be sent to a remote server, so the readiness criterion is not so clear for us. If you started preparing for the event in advance, your team may have a false feeling that “product launch” == “opening the doors of the festival”, but this is not so. It should be understood that everything that you did before is just preparation, no matter how much time and effort you spend on it, but all these actions were done only to ensure that the event itself passed without a hitch. The last sprint of the project will be unusual for Scrum - it will be very short and very rich, because the last sprint is always the event itself.
There may be two scenarios:
1. You were not very strong in the 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 as a textbook. In this case, you will walk and look at everything with a contented smile.
Of course, no, option number 2 in nature does not exist, but this is not a reason for despair. Just try to organize your last sprint with maximum benefit, based on previous experience and retrospectives. We at Kodabar at Digital Fest 2017 will do just that, and we urge you to come and personally evaluate how our Scrum has turned out to be effective!
Usually, speaking about Scrum, people talk only about software development, but today Kodara will tell something unusual, we will tell you our experience of using flexible methodology for “developing” the most real offline event with real people instead of code, platforms instead of servers and demanding audience - children. This is a story about an unusual approach to the organization of Russia's largest digital technology festival for children and teenagers - 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 as the organization of an event? And why are there any methodologies, principles, frameworks? It would seem that he rented a platform, arranged with the speakers, sold tickets - and the trick is done, sit and count the money. But not everything is so simple. People who have tried their hand at organizing something more than a home party at least once will not let us lie - if more than 3 people plan to take part in your event, then everything will go wrong and you will have to change all your plans on the go . And the more the venture, the more chaotic the nature of the task of its implementation. Just like in the development of a complex product - there is only a goal and its global vision, but no one knows what way it will be achieved, even the author of the idea. The further, the more is the analogy with the development of the product. We also thought so and decided to dig deep.
Contrary to well-established stereotypes, Scrum is not necessarily about writing software. Yes, this is the most common, sought-after and best-studied application area, but it is far from the only one, it’s enough to remember the story, because Scrum began as a way to improve the efficiency of the production of copying equipment. In fact, this methodology has an infinite variability of application due to its moderately abstract, but at the same time quite accurately 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 as a universal solution for project management, any, from weeding the beds to the colonization of Mars. Kodabar has beds only with talents growing on them, and our duty is to open the whole universe for 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 make software.
Festival as a product
Romance is romance, but like any business, our goals should be purely pragmatic. Digital Fest for us is one of the most important sources of attracting new audiences and an ideal platform to demonstrate our capabilities That is why we take the organization so seriously - we make our real product. This product has a fixed release date and, perhaps, this is the only thing that distinguishes it from the classic project being developed within Scrum.
Let's draw the other analogies.
The basis of Scrum is the sprint. From 2 to 4 weeks in the classical paradigm for software development, 1 week maximum in our case. This length of the sprint was chosen both because of the limited time frame for the sale of the product, and because of the excessive dynamics of the process caused by the human factor and the large involvement of third parties in the process.
User stories aka "user stories" are the real goals of your sprints. In Scrum, development for the sake of development and “those. debt "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 the database under high loads, they talk to people. When you are organizing a festival, 99% of your tasks begin with the word “agree”. Only the spheres in which it is necessary to negotiate with someone about something vary, but the essence, as a rule, remains unchanged. The agreement is equal to the solved problem. The speaker agreed to speak or hold a master class - a sticker in the “done” column, agreed with the contractor on the price - another sticker in the treasured 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 basis 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, teenagers. We classify these three main groups into subgroups and describe in the stories what they want from the festival. For example, consider our classic group "children."
Children coming to the festival can be divided into several groups:
1. “Gamers” are addicted to games and want to learn more about them, including how they are made.
2. "Hobby" - these guys have already tried to program themselves or in Kodabra, they want to express themselves and show what they have learned.
3. "Advanced" - 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 in” - A complex group from which children are quickly “converted” into one of the previous ones, and parents are divided into groups for parents.
As it is not difficult to guess, all these groups behave differently, they expect from the festival something of their own, and each of them needs a special approach. We take this into account and begin to create specific tasks for the organization on the basis of these “user stories”, which will be included in the sprints. The fulfillment of all tasks will mean that we have satisfied the needs of all groups of our “users” and, accordingly, the festival will be successful.
First sprint - lumpy
User stories are very important, but no matter how well you describe them and no matter how much you think through the first sprint, it will not succeed. Even if you have the coolest scrum master in the city, your team will fail the first sprint, you need to take it right away. It's not about your team, even if it understands the principles of Scrum well and has worked before with many similar projects, you still fail the first sprint. Because the organization of the event is a project in which the first sprint must be failed.
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 way or another, and often turn out to be the gainers. But not in this case. Event organization has more to do with roulette than poker. Your knowledge and professionalism often do not solve anything here, because every time you start from scratch. It is for this that 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 the market conditions and you can 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 one time, you can safely adapt and continue working.
Scrum has another very important tool that allows you to more easily tolerate 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 am. In particular, if this speaker also writes obfuscated code for 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 that is even more important - what, exactly, will we release? As you remember, our product is a whole festival, it does not fit into an RPM package and cannot be sent to a remote server, so the readiness criterion is not so clear for us. If you started preparing for the event in advance, your team may have a false feeling that “product launch” == “opening the doors of the festival”, but this is not so. It should be understood that everything that you did before is just preparation, no matter how much time and effort you spend on it, but all these actions were done only to ensure that the event itself passed without a hitch. The last sprint of the project will be unusual for Scrum - it will be very short and very rich, because the last sprint is always the event itself.
There may be two scenarios:
1. You were not very strong in the 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 as a textbook. In this case, you will walk and look at everything with a contented smile.
Of course, no, option number 2 in nature does not exist, but this is not a reason for despair. Just try to organize your last sprint with maximum benefit, based on previous experience and retrospectives. We at Kodabar at Digital Fest 2017 will do just that, and we urge you to come and personally evaluate how our Scrum has turned out to be effective!
Source: https://habr.com/ru/post/343012/
All Articles