KUKU.io SMM application case: the path from a sprint of 4 months to sensible planning
The guys from KUKU.io, a popular service for SMM , have come a long way from chaotic planning and sprints, stretched for almost half a year, to logical task management, an autonomous team, and finally sprints to be closed in time. Young projects note.
Project manager Pavel shared his story on how to solve most problems painlessly:
We have been developing the KMU.io SMM application since last May, and only now we were able to adjust all the processes so that the chaos in the tasks was minimized, and the users were satisfied with the new functional features that we were asked for as often as possible.
')
When we started, KUKU.io was able to publish content in 4 social networks: Facebook, Vkontakte, Twitter and Linkedin. Definitely, this cannot be called full-fledged social network management, and the application gradually began to acquire other features: users wanted to see the division of social media accounts into channels or projects, social network analysis became a key factor in choosing (or not choosing) a service, UTM tags, reducing links , many pictures in one post, new social networks (now KUKU.io supports 10), etc. - all this was to be realized.
In the first days, when I came to the project, there was a situation when everything seemed to be clear, but in fact nothing was clear. What a project I understood very quickly, without details, since the product is already on production, and you can poke it to see what's what. In addition, the team immediately took care of the cool UX / UI, even a person who is far from social networks can figure out in a few minutes.
The team ... There is a team, all excellent guys, professionals in their work: from unreal developers to marketing specialists and smmschik. Who does what is not clear. :) There is some kind of project management and systems: Jira and GanttPRO, there is something in them, but that this is also not the slightest idea (there are minimal tasks, descriptions of them minimal, logic, nothing).
I climb into the documents - there is a sea of ​​folders in the drive, in which it seems that something adequate is planned by the names: alpha version, competitor analysis, beta version, demo, specs version 1.0 and so on. You open - the title, some sketches and all.
As a result, we have: a working product, without understanding how and what is working in it, who is working on what, who is the product owner, who is responsible for what, where the project is going, what goals are thereafter, what are the working rules. Planning did not determine what it was, as it seems, they tried to come to some kind of flexible framework, but they threw everything. As a result, there were a lot of releases, sprints unclosed, a giant sprint in 4 months. On the working process there was such a scheme: almost any team member created issues for himself in Jira, naturally without any descriptions.
Those. we climb into a sprint or backlog, and then there is some beard “Change existing block” or a bug “Does not work login - console error #”.
Understandably, the product on the production recently. Sea bugs, functional features are not enough, they need to quickly roll out. Plus, the payment system must be tied, the fire is full.
Therefore, we started with a simple:
There are different mechanics, equipment and frameworks, suitable for outsourcing companies, but completely unrealizable in their own projects. We began to choose elements from different methodologies and try what would get accustomed.
From Scrum we took Daily Meetings , which immediately showed sore spots in the working process and allowed the guys to figure out who is working on what and to establish communication within the team. Unfortunately, at first they took a lot of time, sometimes up to an hour. This problem was solved when the team became more autonomous: now at meetings there is no place for discussing the tasks, only quick reports are done by someone who does what and plans to do.
Then we tried iterations , but this did not give the desired effect, since the product in live, the team bombed the features one by one, the bugs of the rod. It didn’t help us much at the beginning, but we’ll come to this, slowly but surely.
We did not introduce a retrospective , as there was no special meaning. Planning was done for a month, since it would hardly have been possible to quickly, the project is too dynamic, although even now there are problems with the deadlines. We decided that we would come to story points later and left everything in a task, but with a description of logic and use cases, which gave a quick result: the acceptance conditions were clear to everyone, and the number of bugs decreased.
From XP, they took most of the CI (Continuous Integration) , which accelerated the updates and, again, allowed to produce better releases, feedback from the client (users' feedback) was taken as a basis when setting priorities; All decisions were made by you, at your own peril and risk.
By the way, about priorities. This has become one of the most painful processes. Everyone believes that his task is the most important, and he is fighting for it to the end, but I would like to set priorities with less “blood”.
Previously, we had such a flow of tasks and feedbacks that we did not know what to undertake and rushed to everything in order to please every user. The next stage was complete asynchronous actions: my task is the main one. Now, when we debugged a process and came to the understanding that it would not be possible to please everyone, we began to intelligently distribute user recommendations and balance between internal tasks and new requests. To our joy, user requests are very similar in most cases, and we can confidently add new features.
Kanban helped his board , and left him, only added a few columns, based on the needs of CI.
Later, we took story and epics from Scrum - we are moving to detailed planning. We can say that we come to a more detailed planning and shorter iterations. Now we know that we will have almost a month ahead by 80-90 percent. And we can easily make edits.
The next step for us was the creation of an autonomous team . Everyone writes that autonomous teams are cool - and this is really cool (there are already many chewed why: more involvement, interest and feedback, which makes it possible to call a group of like-minded people a team, less risks and misunderstandings) - but the developers mostly prefer did not touch, they say, give us a detailed TZ, and we’ll do everything on this TZ, and if it’s not clear, we’re all cool, we’ll do it on our own, and determine readiness too.
What in our case led to autonomy:
1) the ever-changing and growing product and holidays - everyone smelled gunpowder in the role of other participants and have an idea of ​​what is arranged in the product.
2) daily meetings - we not only tell them who does, but also try to solve the problem quickly, so the whole team, even with an ear, but knows about the changes or the problem (if we understand that the discussion will be delayed, then the rest participants are released).
3) planning - we know what we have now and where we are going.
4) team cohesion - going to a bar, corporate parties , lively communication, lack of pressure.
5) communication - we still need to grow in this direction, but now, if someone has a problem, they don’t keep her in the store for a long time, and immediately speak their fairy or ring the bell, there is no fear of speaking.
All this led to the fact that the guys know about the dependence of their tasks on a partner or on third-party factors and do not work blindly, small jambs and problems are fixed quickly in the bud or else in the bud :), fewer fixes and technical debt, since the medium-term goals are clear .
So, what about the total? First of all, we have reduced the number of bugs: to say how much, I’ll definitely not undertake (honestly, I didn’t keep records, it will be interesting to analyze), but at the output we have a very good product, and the bugs that appear are not critical - minor bugs mainly because of inattention (although there are still shoals with Merge and Deploy). But our QA (and we have it 1) has become easier to live, and we have become more happy to please users with releases.
We plan for about a month, then fix, regress, deploy. Total approximately once every 5-6 weeks we release an update with major features, and updates with bug fixes - as messages arrive from users. Previously, in general, our plans were space. A sprint of 3 weeks could drag on for a couple of months.
Vivid recent examples: this is the Content Plan for social networks and the Team Plan for SMM and marketing agencies and companies in which more than one person is engaged in promotion in social networks. We thought of doing the last month in the first estimation without any understanding how it should be. After analyzing, decomposing, writing a small “specs”, the scoped tasks were estimated at 2 months. In fact, the team threw out a team plan, a lot of dodgers to it, smm and marketing buns, annual subscriptions, improved the analytics of social networks, tested it all, regressed and relaxed to production for 3 months. This is taking into account the fact that we have 3 developers, two of them had a session and an eviction from a hostel, the Content Plan was created in parallel, they are interconnected and must be merged without conflicts. And it all worked as described. This is a real success!
Another achievement is a great achievement - fewer conflicts in the team.
Then I would like to come to more frequent releases and notify users of our upcoming updates. The whole road map, it seems to me, is not so cool to show - there is no interest, everything is in the palm of your hand, and they will wait this way. :)
Project manager Pavel shared his story on how to solve most problems painlessly:
We have been developing the KMU.io SMM application since last May, and only now we were able to adjust all the processes so that the chaos in the tasks was minimized, and the users were satisfied with the new functional features that we were asked for as often as possible.
')
When we started, KUKU.io was able to publish content in 4 social networks: Facebook, Vkontakte, Twitter and Linkedin. Definitely, this cannot be called full-fledged social network management, and the application gradually began to acquire other features: users wanted to see the division of social media accounts into channels or projects, social network analysis became a key factor in choosing (or not choosing) a service, UTM tags, reducing links , many pictures in one post, new social networks (now KUKU.io supports 10), etc. - all this was to be realized.
In the first days, when I came to the project, there was a situation when everything seemed to be clear, but in fact nothing was clear. What a project I understood very quickly, without details, since the product is already on production, and you can poke it to see what's what. In addition, the team immediately took care of the cool UX / UI, even a person who is far from social networks can figure out in a few minutes.
The team ... There is a team, all excellent guys, professionals in their work: from unreal developers to marketing specialists and smmschik. Who does what is not clear. :) There is some kind of project management and systems: Jira and GanttPRO, there is something in them, but that this is also not the slightest idea (there are minimal tasks, descriptions of them minimal, logic, nothing).
I climb into the documents - there is a sea of ​​folders in the drive, in which it seems that something adequate is planned by the names: alpha version, competitor analysis, beta version, demo, specs version 1.0 and so on. You open - the title, some sketches and all.
As a result, we have: a working product, without understanding how and what is working in it, who is working on what, who is the product owner, who is responsible for what, where the project is going, what goals are thereafter, what are the working rules. Planning did not determine what it was, as it seems, they tried to come to some kind of flexible framework, but they threw everything. As a result, there were a lot of releases, sprints unclosed, a giant sprint in 4 months. On the working process there was such a scheme: almost any team member created issues for himself in Jira, naturally without any descriptions.
Those. we climb into a sprint or backlog, and then there is some beard “Change existing block” or a bug “Does not work login - console error #”.
Understandably, the product on the production recently. Sea bugs, functional features are not enough, they need to quickly roll out. Plus, the payment system must be tied, the fire is full.
Therefore, we started with a simple:
- We took kanban as a basis (your project, so there is no link to the deadlines).
- Determined who is responsible for what, who makes decisions.
- Chose urgent tasks.
- Set priorities.
- Agreed with QA about the method of describing bugs in the form of use cases with a description of the environment.
- Finally, they backed up the backlog (it took a lot of time).
- Began to describe everything through stories to reduce the number of bugs.
There are different mechanics, equipment and frameworks, suitable for outsourcing companies, but completely unrealizable in their own projects. We began to choose elements from different methodologies and try what would get accustomed.
From Scrum we took Daily Meetings , which immediately showed sore spots in the working process and allowed the guys to figure out who is working on what and to establish communication within the team. Unfortunately, at first they took a lot of time, sometimes up to an hour. This problem was solved when the team became more autonomous: now at meetings there is no place for discussing the tasks, only quick reports are done by someone who does what and plans to do.
Then we tried iterations , but this did not give the desired effect, since the product in live, the team bombed the features one by one, the bugs of the rod. It didn’t help us much at the beginning, but we’ll come to this, slowly but surely.
We did not introduce a retrospective , as there was no special meaning. Planning was done for a month, since it would hardly have been possible to quickly, the project is too dynamic, although even now there are problems with the deadlines. We decided that we would come to story points later and left everything in a task, but with a description of logic and use cases, which gave a quick result: the acceptance conditions were clear to everyone, and the number of bugs decreased.
From XP, they took most of the CI (Continuous Integration) , which accelerated the updates and, again, allowed to produce better releases, feedback from the client (users' feedback) was taken as a basis when setting priorities; All decisions were made by you, at your own peril and risk.
By the way, about priorities. This has become one of the most painful processes. Everyone believes that his task is the most important, and he is fighting for it to the end, but I would like to set priorities with less “blood”.
Previously, we had such a flow of tasks and feedbacks that we did not know what to undertake and rushed to everything in order to please every user. The next stage was complete asynchronous actions: my task is the main one. Now, when we debugged a process and came to the understanding that it would not be possible to please everyone, we began to intelligently distribute user recommendations and balance between internal tasks and new requests. To our joy, user requests are very similar in most cases, and we can confidently add new features.
Kanban helped his board , and left him, only added a few columns, based on the needs of CI.
Later, we took story and epics from Scrum - we are moving to detailed planning. We can say that we come to a more detailed planning and shorter iterations. Now we know that we will have almost a month ahead by 80-90 percent. And we can easily make edits.
The next step for us was the creation of an autonomous team . Everyone writes that autonomous teams are cool - and this is really cool (there are already many chewed why: more involvement, interest and feedback, which makes it possible to call a group of like-minded people a team, less risks and misunderstandings) - but the developers mostly prefer did not touch, they say, give us a detailed TZ, and we’ll do everything on this TZ, and if it’s not clear, we’re all cool, we’ll do it on our own, and determine readiness too.
What in our case led to autonomy:
1) the ever-changing and growing product and holidays - everyone smelled gunpowder in the role of other participants and have an idea of ​​what is arranged in the product.
2) daily meetings - we not only tell them who does, but also try to solve the problem quickly, so the whole team, even with an ear, but knows about the changes or the problem (if we understand that the discussion will be delayed, then the rest participants are released).
3) planning - we know what we have now and where we are going.
4) team cohesion - going to a bar, corporate parties , lively communication, lack of pressure.
5) communication - we still need to grow in this direction, but now, if someone has a problem, they don’t keep her in the store for a long time, and immediately speak their fairy or ring the bell, there is no fear of speaking.
All this led to the fact that the guys know about the dependence of their tasks on a partner or on third-party factors and do not work blindly, small jambs and problems are fixed quickly in the bud or else in the bud :), fewer fixes and technical debt, since the medium-term goals are clear .
So, what about the total? First of all, we have reduced the number of bugs: to say how much, I’ll definitely not undertake (honestly, I didn’t keep records, it will be interesting to analyze), but at the output we have a very good product, and the bugs that appear are not critical - minor bugs mainly because of inattention (although there are still shoals with Merge and Deploy). But our QA (and we have it 1) has become easier to live, and we have become more happy to please users with releases.
We plan for about a month, then fix, regress, deploy. Total approximately once every 5-6 weeks we release an update with major features, and updates with bug fixes - as messages arrive from users. Previously, in general, our plans were space. A sprint of 3 weeks could drag on for a couple of months.
Vivid recent examples: this is the Content Plan for social networks and the Team Plan for SMM and marketing agencies and companies in which more than one person is engaged in promotion in social networks. We thought of doing the last month in the first estimation without any understanding how it should be. After analyzing, decomposing, writing a small “specs”, the scoped tasks were estimated at 2 months. In fact, the team threw out a team plan, a lot of dodgers to it, smm and marketing buns, annual subscriptions, improved the analytics of social networks, tested it all, regressed and relaxed to production for 3 months. This is taking into account the fact that we have 3 developers, two of them had a session and an eviction from a hostel, the Content Plan was created in parallel, they are interconnected and must be merged without conflicts. And it all worked as described. This is a real success!
Another achievement is a great achievement - fewer conflicts in the team.
Then I would like to come to more frequent releases and notify users of our upcoming updates. The whole road map, it seems to me, is not so cool to show - there is no interest, everything is in the palm of your hand, and they will wait this way. :)
Source: https://habr.com/ru/post/308588/
All Articles