KUKU.io SMM application case: the journey from sprinting in 4 months to smart planning

    The guys from the startup KUKU.io, a popular service for SMM , have come a long way from chaotic planning and sprints lasting almost half a year to logical task management, an autonomous team and, finally, sprints that are deadline-locked. Note to young projects.

    Project manager Pavel shared a story on how to painlessly solve most of the problems:




    We have been developing the KUKU.io SMM application since May of last year and only now we managed to configure all processes so that the chaos in tasks was minimized and users were satisfied new features requested by us as often as possible.

    When we started, KUKU.io was able to publish content on 4 social networks: Facebook, Vkontakte, Twitter and Linkedin. Definitely, you can’t call it a full-fledged management of social networks, and the application gradually began to acquire other features: users wanted to see the separation of social network accounts into channels or projects, the analysis of social networks became a key factor in choosing (or not choosing) a service, UTM tags, shortening links , many pictures in one post, new social networks (now KUKU.io supports 10), etc. - all this was to be implemented.

    In the early days when I came to the project, there was a situation where everything seems to be clear, but in reality nothing is clear. What kind of project I realized very quickly, without details, since the product is already in production, and you can poke 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 it out in a few minutes.

    The team ... There is a team, all the guys are excellent, professionals in their field: from unrealistic developers to a marketer and smmshchik. 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 (wait for task, minimal descriptions for them, logic, nothing).

    I’m climbing into the documents - there is a sea of ​​folders in the drive, in which something adequate is supposed to be named according to the names: alpha version, analysis of competitors, beta version, demo, spec version 1.0, etc. You open - the headline, some drafts and that’s it.

    As a result, we have: a working product, without understanding how and what works in it, who is working on what, who is the product owner, who is responsible for what, where the project is going, what are the goals in the future, what are the working rules. Planning did not determine what it was, as you can see, they tried to come to some kind of flexible framework, but they abandoned it all. The result was a bunch of releases, open sprints, a giant sprint in 4 months. The working process was such a scheme: almost any member of the team created issues for himself in Jira, naturally without descriptions.

    Those. we’ll climb into the sprint or backlog, and there’s some beard “Modify an existing block” or a bug “login doesn’t work - console error #”.

    Clear business, a product on production recently. There are a lot of bugs, functional features are not enough, they need to be rolled out quickly. Plus, the payment system must be tied, the fire is complete.

    Therefore, we started with a simple:

    • We took as a basis kanban (your project, so there is no timing).
    • They determined who is responsible for what, who makes decisions.
    • Chose the actual tasks.
    • Set priorities.
    • We agreed with QA about the method for describing bugs in the form of use cases with a description of the environment.
    • Finally, they fed backlog (it took a lot of time).
    • They began to describe everything through stories in order to reduce the number of bugs.

    There are various mechanics, estimation techniques and frameworks suitable for outsourcing companies, but completely unrealizable in their own projects. We began to choose elements from different methodologies and try what will take root.

    From Scrum we took the Daily Meetings , which immediately showed the sore spots in the workflow and allowed the guys to figure out who was working on what and to establish communication within the team. Unfortunately, at first they took a very long time, sometimes up to an hour. This problem was resolved when the team became more autonomous: now there is no place for discussion of problems at meetings, only quick reports are made of who does what and plans to do it.

    Then we tried iterations, but this did not give the desired effect, since the product is live, the team bombes features one by one, the bugs are twisted. It didn’t help us much at first, but we will come to this, slowly but surely.

    We did not introduce a retrospective , since there was no special meaning. We did the planning for a month, since it would hardly have turned out to be a too dynamic project, although now there are problems with the deadlines. We decided that we would come to story points later and left everything in task, but with a description of the logic and use cases, which gave a quick result: the acceptance conditions were clear to everyone, and the number of bugs was reduced.

    Most XP took CI (Continuous Integration)that accelerated updates and, again, allowed to release better releases, users' feedback was taken as a basis for prioritization; all decisions were made at their own 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 fights for it to the end, but I would like to prioritize less “blood”.

    Previously, we had such a stream of tasks and feedbacks that we did not know what to do and rushed to everything in order to please every user. The next stage was complete asynchrony of actions: my task is the main one. Now that we have debugged some kind of process and came to the understanding that it’s impossible to please everyone, we began to competently distribute user recommendations and balance between internal tasks and new requests. To our joy, user requests are in most cases very similar, and we can confidently add new features.

    Kanban helped with his board , and left him, just added a few columns, based on the needs of CI.

    Scrum later got story and epics- go to detailed planning. We can say that we come to more detailed planning and short iterations. Now we know that we will have 80-90 percent advance for almost a month in advance. 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 it’s really cool (there’s already a lot to chew on: more involvement, interest and return, which makes it possible to call a group of like-minded people a team, fewer risks and misunderstandings) - but the majority of developers prefer that they they didn’t touch, they say, give us the TK in detail, and we will do everything according to this TK, and if it is not clear - we are all so cool, we will do it at our discretion, and we will determine our willingness too.

    What in our case led to autonomy:

    1) a constantly changing and growing product and holidays - all sniffed the gunpowder in the role of other participants and have an idea of ​​what and how is arranged in the product.
    2) daily rallies - we not only tell them what everyone is doing, but also try to solve the problem quickly, so the whole team, at least out of our ears, knows about the changes or about the problem (if we understand that the discussion will be delayed, then the rest release participants).
    3) planning - we know what we have now and where we are going.
    4) team cohesion - going to the bar, corporate parties , lively communication, lack of pressure.
    5) communication- you still need to grow in this direction, but now, if someone has a problem, they don’t keep her in the coffers for a long time, but immediately say their fairies or beat the bell, there is no fear to speak out.

    All this led to the fact that the guys know about the dependence of their tasks on a partner or on external factors and do not work blindly, small schools and problems are fixed quickly in the bud or still in the bud :), fewer corrections and technical debt, as medium-term goals are clear .

    So, what is the outcome? First of all, the number of bugs has decreased: to say how much, I definitely won’t take it (to be honest, I didn’t keep records, it will be interesting to analyze), but at the output we have a very solid product, and those bugs that appear are not critical - minor flaws mainly due to carelessness (although there are still jambs with merge and deploy). But our QA (and we have 1) has become easier to live, and we have become much more happy with release releases.

    We plan for about a month, then fix, regression, deployment. In total, approximately every 5-6 weeks we will release an update with major features, and updates with a bugfix - as soon as messages from users arrive. Previously, in general, our plans were outer space. Sprint for 3 weeks could drag on for a couple of months.

    Bright 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. The last we thought to do in a month according to the first estimate without any understanding of how it should be. After analysis, decomposition, writing a small “spec”, the scope of tasks was evaluated at 2 months. In fact, the team wiped out a team plan, a bunch of body kits for it, smm and marketing buns, annual subscriptions, improved analytics on social networks, tested all this, made a regression and released to production for 3 months. This is taking into account the fact that we have 3 developers, two had a session and eviction from the hostel, a Content Plan was created in parallel, they are interconnected and should be interrupted without conflict. And it all worked as described. This is a real success!

    Another achievement is a huge achievement - fewer conflicts in the team.

    Further I would like to come to more frequent releases and notify users of our upcoming updates. It seems to me that the whole road map is not so cool to show - there is no interest, everyone is in the palm of your hand, and they will wait this way. :)

    Also popular now: