Seals and Scrum

Introduction

It so happened that with the theme agile and scrum I have long and tender feelings. It all started back as a student: start-ups with a complete lack of experience, but with burning eyes, the IIDF pre-acceleration program, cool conferences with celestial speakers. As is often the case with startups: nothing came of our ideas, but for myself I learned the main thing – a business can (and in some cases should) be flexible.

Since then, there have been many interesting things in my life: 3 years of experience remotely introducing flexible methodologies with five like-minded colleagues, working as a scrum master in an IT company for 2000+ people, countless books and conferences, a couple of very small projects and … the opening of the kotokafe. Here I will tell about the last point in more detail.


How it all started

At the source were 3 enthusiasts with no practical business experience, but with the idea of ​​making an anticafe with cats. The project is primarily social: for the soul and pleasure, so the main goal was self-sufficiency. On the waves of enthusiasm, a business plan was drawn up, investments were calculated, break-even point and so on, but as soon as it came to the realization of ideas, work traditionally slowed down …

“Why do we need your agile?”

My husband (one of three enthusiasts) asked me such a question on my timid attempts to accelerate a new project. “We already know what to do, why do we need additional meetings, and is that all?” – this, by the way, is one of the most popular issues when introducing new approaches to work, relevant for both IT and non-IT companies so remember it.

One way to work out this objection is to show the prospects for development (more precisely, stagnation) with the current approach. Well, when there are 3 organizers in a team, almost inevitably everyone will want to shift responsibility to another. So in a few weeks we have not moved too far off the ground. Self-organization did not work. I had to help her.

The best option is when the team itself has managed to feel the “pain” from the lack of a unified approach to work and has come to you for help. But in this case, I did not wait for the moment when the intervention would already be vital, since I myself was part of the team. My second attempt to suggest “use some of the practices and ideas from agile and scrum” worked better.

What steps have we taken at this stage:

  1. Started and prioritized task backlog

    First, we identified the main blocks of tasks (search and rental of premises, repairs, marketing, design, etc.), then we already painted each of the blocks for individual tasks and determined the order of their execution. Already this simple step helped to restore order in the head and make rough estimates of the terms.

  2. Set up the rhythm of interaction

    The obvious fact is that backlog preparation alone does not ensure the achievement of goals. However, I must admit that at least several weeks passed between creating a backlog and starting the rhythm of work. At first, we naively hoped that everyone would simply take some tasks from the list on their own and do them. But it doesn’t work like that. At least in most cases.

So we had a meeting at which a decision was made:

  • Determine the day and time for regular meetings (in essence – set the duration of iterations). In our case, we agreed on iterations 1 week long. These meetings did not move and were not canceled.
  • Build meetings in the format: demonstration of the results of work + exchange of feedback + planning tasks for a new iteration with the appointment of those responsible.

    We did not use special terminology, although the meetings themselves are very reminiscent of a bunch from scrum: sprint review + retro + sprint planning. In fact, it was one whole meeting with a predetermined agenda, which closed the previous iteration and started a new one.

Having done all this, we were able to better predict the timing, not to forget anything and not to kill each other at the launch stage (which, by the way, is very important).

From “We and They” to “We”

The next fascinating stage came at the moment when we began to discuss the approach to working with employees and hire these same employees.

It was important for a start to understand among ourselves: how exactly we want to build work in a team. At first, one of the future leaders expressed a desire to keep a distance with employees: “As you know, but I would like them to contact me by name and patronymic.” I remember how at this moment I choked nervously. Maybe because we were all 25, or maybe because I did not know the middle name of any of my previous leaders. “And for work, we will prepare them instructions for all occasions.” All this did not fit in with my idea of ​​how to work.

I wanted to make a small but strong team, where the relationship would be based on mutual respect and trust. To make employees feel comfortable and confident. So at this stage we had to work out this moment: move from the approach “I’m the boss, you are a fool” to the approach “we will work in one team”. It was not so simple, we came to this through long conversations and a search for the root of the problems. It seems to me now that the views of each of us on how to build relationships with employees were determined by the corporate culture in which we still boiled. Someone was brought up by startups, and someone was working in factories. But to transfer the culture of the plant in Kotokafe is not entirely true.

It is important to remember that our potential employees had some work experience behind their backs. And if they had already become accustomed to “you’re the boss, I’m a fool”, then for them teamwork would be stressful. Therefore, when choosing employees, we focused on the similarity of views and ideas, ability to communicate and approach to solving non-standard tasks. In addition to the usual questions, we proposed problem situations to the applicants and evaluated the solutions they proposed. What we did not pay attention to: diplomas, medals and other regalia. As a result, we chose the right strategy and took the team of really cool guys with whom it was easy to build further work.

“Why is your Agile to the staff?”

“Ok, Katya, the list of tasks and general meetings helped us at the opening. Every day we performed non-standard tasks and we needed to share the results. But what does the staff have to do with it? They will have the same type of work, once taught – and into battle. ”- I was asked about this when we were already open, and the question arose about how to build further work.

And I did not argue. I thought: “But what, there is logic in this. Let everything go as it should. ”Moreover, we spent the first weeks together“ in the fields ”, side by side with employees: we debugged processes, shared experiences, trained ourselves and trained them, and collected feedback.

In fact, everything worked very well. The employees are motivated, do not juggle, cats and guests are satisfied, any issues are resolved promptly – the perfect picture. And everything was perfect. Until the moment we went on vacation a month after the opening. For two weeks we worked only in the format of answers to urgent questions in a working chat. And when we returned, rested and happy, in the kotokafe we ​​were met by depressed and confused employees. “Don’t leave us again, please,” they asked plaintively.

We take the best practices and apply in work

So we went to the first retrospective of the team. They did not artificially introduce a new meeting, but only when they realized that it was necessary.

For more than an hour, we discussed what problems the employees faced, which nevertheless worked out well, and as a result we made a list of improvement steps. And everyone liked this format of interaction, so it was decided to conduct retrospectives every 2 weeks.

Later, daily morning mini-reports in the working chat were added to the retrospectives. Usually they were in free form and contained the following information: plans for today; Faced such and such problems, applied such and such a solution, worked / did not work; I need some kind of help (urgent / not urgent). Let the word “report” not scare you, in fact, this information was equally important to us and our employees. For us it is an opportunity to keep abreast, for employees it is an opportunity to highlight problems. This format was somewhat similar to daily scrum, although it was adapted to our specifics.

So, on a daily basis, we solved current issues, once every 2 weeks we considered ideas for improving work processes. Why didn’t we add, for example, planning and sprint reviews? Yes, because they would not make any sense. We took only those practices that were really applicable and useful in our case. And yes, none of the team used the words “agile” and “scrum” in the workflow because:

  • Applying individual scrum practices does not give you the right to call your workflow a scrum.
  • The name is not important, the goal is important. And the essence of all our meetings was reduced to a process of continuous improvement. And everyone knew about this goal.

What happened next?

And then we gradually came to almost complete autonomy kotokafe. Employees learned everything that was needed to work. We did what we wanted: we gave employees freedom, respected their opinions, supported them. In response, they became the driving force behind this place: they initiated change, proposed and promoted their ideas.

In connection with the move, we were forced to sell a kotokafe. Now he has other owners, the business lives on, the cats continue to delight the guests – and this is really great.

That’s just the employees left a month after the change of leadership. They say that after our departure I no longer want to work “differently”. And now we continue to keep in touch with them. Because the team is the second family.

And in what cases you should not use Scrum, read in my other article “Scrum will not help you. We understand why. ”

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *