{"id":7155,"date":"2023-07-31T13:37:42","date_gmt":"2023-07-31T11:37:42","guid":{"rendered":"http:\/\/blog.bart.sk\/en\/?p=7155"},"modified":"2024-01-25T13:57:02","modified_gmt":"2024-01-25T12:57:02","slug":"manage-growth-team-not-go-crazy","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/manage-growth-team-not-go-crazy\/","title":{"rendered":"How to Manage the Growth of a Team and Not Go Crazy"},"content":{"rendered":"

Some time ago, Crossuite was just a simple calendar with the option of making an appointment with a doctor. Now it’s a digital multidisciplinary platform with more than 10,000 experts in 13 countries. As the project grew, so did our team. At the beginning, one developer and one client were enough for us. Today, 45 people work at Crossuite. However, at a certain point in our operation, we realized that the meetings were no longer within the time limit. That transparency wasn\u2019t what it used to be and people were less involved and proactive. That there were too many of them and therefore it was difficult to synchronize them. So the time came to scale our processes.<\/b><\/p>\n

What does scalability mean?<\/b><\/h2>\n

The definition changes depending on what we associate it with. Generally, however, it’s the <\/span>ability of a process, network, software or organization to handle an increased workload<\/b> or increasing requirements <\/span>without a significant reduction in performance<\/b>, efficiency or quality. The advantage of a scalable entity is that it accommodates the needs and requirements of its users or clients.<\/span><\/p>\n

On the Crossuite project, we develop a product through Scrum.<\/b> It’s an agile framework that <\/span>just fits us<\/span><\/a>. <\/span>When we began to perceive the need to change development processes<\/b>, we didn’t ask what we would exchange Scrum for. Rather<\/span>, we tried to work out how we could develop it into such a form that it could handle a larger number of people<\/b>, requirements and more complex dependencies between functionalities.<\/span><\/p>\n

Our goal was to achieve a way of development in which the team would be able to continue to function well, deliver regularly and meet business requirements.<\/b> This is regardless of the fact that there’s an increase in its size or in the volume of requests.<\/span><\/p>\n

There are several scalable frameworks. Some examples include:\u00a0<\/b><\/p>\n

    \n
  1. Scaled Agile Framework (SAFe) (37% of Scrum users use it, according to a <\/span>2021 survey<\/span>)<\/span><\/li>\n
  2. Nexus<\/span><\/li>\n
  3. Large-Scale Scrum (LeSS)<\/span><\/li>\n
  4. Scrum@Scale<\/span><\/li>\n<\/ol>\n

    We opted for Nexus.<\/span><\/p>\n

    Why Nexus?\u00a0<\/b><\/h2>\n

    Nexus won because it’s based on Scrum itself.<\/b> Therefore, it means only a small change compared to what our people are already used to. There’s also no need for new roles and all the teams involved are working on a single product<\/span>. It has one product owner and one common backlog.\u00a0<\/b><\/p>\n

    Refinement meetings, which aren’t an official event in Scrum, have become a mandatory event in the case of Nexus. This was also one of the decision-making criteria for us. We assessed the need for joint refinement meetings, when individual teams discuss and evaluate the complexity of the requirements entering development in the next sprint, as necessary. So we decided on a joint retrospective, where we unanimously agreed that we want and need them. <\/span>At the same time, Nexus allows you to support Scrum with a Kanban board, and doesn’t mind when the team isn’t in one location, which happens in our team too.<\/b><\/p>\n

    How is Nexus different from Scrum itself?<\/b><\/h2>\n

    Scrum diagram:<\/b><\/p>\n


    \"\"<\/a><\/span><\/h3>\n

    Nexus diagram:<\/strong><\/h3>\n

    \"\"<\/a><\/p>\n

    So what’s changed?<\/b><\/h2>\n

    From the point of view of the diagram, there was no big change <\/span>\ud83d\ude42 From the point of view of reality, however, the change was bigger, although it didn’t significantly affect people on the project.\u00a0<\/b><\/p>\n

      \n
    1. \n

      Smaller teams<\/b><\/h3>\n<\/li>\n<\/ol>\n

      Large teams were divided into smaller ones and we joined the Slovak developers with development teams in Ukraine and Belgium. Today we have a total of 7.<\/span><\/p>\n

      \"\"<\/a><\/p>\n

        \n
      1. \n

        Added Proxy Product Owners<\/b><\/h2>\n<\/li>\n<\/ol>\n

        We kept the Product backlog and one Product Owner, but two Proxy Product Owners were added to them.<\/b> Yes, I know, it’s not an ideal solution. With Nexus and Scrum, we should avoid using a proxy. <\/span>However, in our case, our Product Owner is also our sponsor, client and founder of Crossuite.<\/b> \ud83d\ude42 Thanks to this, visions, short-term goals, strategies and market successes\/failures are regularly communicated to us. The disadvantage is his occasional unavailability.\u00a0<\/span><\/p>\n

        However, we put our heads together in the team and agreed that the advantage of a detailed business view, understanding the requirements and communicating them to us, outweighs the negative situations that the intermediary role of a Proxy Product Owner can bring.<\/span><\/p>\n

          \n
        1. \n

          New integration team<\/b><\/h3>\n<\/li>\n<\/ol>\n

          In addition to the three roles existing in Scrum, we’ve also added the Nexus integration team.<\/b> These are the people responsible for ensuring the compatibility of the work of individual Scrum teams. <\/span>They check, for example, whether each sprint has brought us a joint increase in the product that meets the sprint goal.<\/b> They’re also in charge of educating and guiding people in the individual Scrum teams.\u00a0<\/span><\/p>\n

          Thus, its main task is to ensure smooth development, remove obstacles, guide mutual communication and coach people<\/b> in the individual Scrum teams so that they are able to deliver the desired joint result and don’t hinder each other.\u00a0<\/span><\/p>\n

          The Nexus integration team is composed of a Product Owner, a Scrum Master and appropriate representatives of the Scrum teams. <\/span>Each member should have the skills and knowledge necessary to effectively address any issues that Nexus may face.<\/b> The composition of the Nexus integration team may change over time to reflect current needs. In practice, this means that different team members can participate in Nexus daily Scrum meetings.<\/span><\/p>\n

            \n
          1. \n

            Edited events\u00a0<\/b><\/h2>\n<\/li>\n<\/ol>\n

            Nexus adds or extends Scrum-defined events.\u00a0<\/span><\/p>\n

            Cross-team refinement<\/b><\/h3>\n

            Nexus introduces, for example, the concept of cross-team refinement, i.e. the refinement and division of requirements into smaller meaningful units<\/b> between representatives of individual teams. The product backlog must therefore be broken down so that dependencies are transparent, identified between teams and removed or minimized.\u00a0<\/span><\/p>\n

            Subsequently, this cross-team refinement is complemented by<\/b> team refinements<\/b>, where the individual teams go into more depth. They prepare their own user stories, evaluate them and define requirements in order to achieve the “definition of ready” status and be able to plan them.<\/span><\/p>\n

            Nexus planning<\/b><\/h3>\n

            In Nexus, planning takes the form of Nexus planning. The <\/span>Nexus integration team and\/or individual representatives of the Scrum teams and the Product Owner participate in it.<\/b> Their task is to coordinate all the activities of the individual Scrum teams for the next sprint.<\/span><\/p>\n

            The result of Nexus sprint planning is:<\/b><\/p>\n