Teamwork at Greenbyte — A story of aggressive scaling while remaining adaptable
Working at a startup like Greenbyte — in a fast-moving industry with big customers that have even bigger requirements — can be tough. Scaling in such an environment can be even tougher.
We have evolved software development methods over the years to keep production as high as possible while onboarding as many new people as possible in product development.
Once upon a time
When we were a small workshop of five developers, we worked with a pure Kanban-esque sprint-less process. Stuff came in, either directly from our customers, or from our Product Owner, and got dispatched as fast as possible. We had a physical board, work-in-process limits, and a whole lot of enthusiasm.
It worked well until we realized that the type of work we were doing wasn’t really suited for a Kanban-style flow.
Our work came in chunks that needed refinement. They couldn’t quickly get dispatched by anyone to secure a strong flow. They needed planning and they needed synchronization between multiple people, both within and without product development. This convinced us that we needed to move beyond attaining pure flow to add a little structure.
At the same time, we started growing really rapidly and doubled the team size in just three months. We had to change and adapt, or we would drown in the chaos.
Chapter 2 — multiple teams, single product
Driven by the need to plan our work further in advance and make it transparent to our customers, we were inspired by Maxime Prades, Product Manager at Algolia, and decided to try their brand of quarterly planning.
We tried to determine what work needed to be done in a quarter by listening to our customers, analyzing the market, and infusing our grand vision. We then split this work up into two categories: P1 and P2. P1 items were so important that they had to be finished during the quarter, no questions asked. P2s were also very important but could be omitted if time was short. As an example, in Q2 of 2018 implementing “Einspeisemanagement” for the German market was a definite P1 — as it is paramount for operation in Germany. Something less critical, like adding sound alerts to dashboards on important events was a P2.
Our work was then planned and prioritized in a backlog that we dispatched during the quarter. We wanted to try this approach, even though a sprint length of three months felt large.
As for our teams, we grew into two separate product development teams and a platform team. We nicknamed the two product development teams the Bears, and the Wolves, while the platform people were the Owls.
The Owls are our enablers; our way of increasing the efficiency of all developers by improving CI/CD, reworking tooling/applications, and developing new shortcuts. They also enforce uniformity across our (already huge) code base and make sure our architectural guidelines are followed, as well as producing new ones when needed.
The Wolves and Bears work closely with our Product team (primarily our Product Managers) to build our product. They participate in backlog refinement, requirements engineering, and of course, software engineering. Their commitment is to deliver all P1s in a quarter, as many P2s as possible, and hand off items to Product for final approval.
This started off well, and we could finally feel that we were getting a grasp of the horizon, of what we wanted to do. Transparency went up, and everyone in the company, not just product development, was keeping track of P1s and their progress. This was good. It felt good, and our Product team worked hard on the three-month horizon. However, after a while, we began hitting some speed bumps.
Chapter 3 — Bigger product, more teams, less rigidity
After a while, as more and more customers and people came on, we realized that our approach wasn’t holding up. It proved difficult to plan and fix work for three months at a time (even though it was just a subset; the P1s). The scope-lock of committing to P1s and guaranteeing them also reduced our flexibility. We didn’t want to change anything or introduce new items, which would invalidate the commitment we had worked so hard to obtain.
We needed to get back to our more agile roots and accept change as it came (rapidly). We enjoyed the transparency and horizon of three months — it really helped us get clarity in the product planning — but we wanted to get rid of the rigidity.
We decided to take a step back toward our first approach, the ordered backlog. No more quarterly commitments, but instead a plan to build things in a certain order, from most important to least. Our product development teams would work off this backlog in 2-week sprints, collaborating with Product to plan the work and refine it. However, we didn’t go all the way back to Kanban and decided to include more structure from frameworks like Scrum to improve communication and transparency.
This is now slowly being implemented, step-by-step, and we already feel the more agile methodology suits us as a company much better. It also suits the fast and ever-changing domain of renewable energy, where we need to be adaptable to prevail.
