Unconventional trello software#
Software Engineers are optimistic people, we often give estimates that have nothing to do with reality.
One monster project took 18 months to complete, and that was the trigger for changing how we work again. We had a few “runaway” projects that took 6-9 months to complete. When there are no estimates, no deadlines and no limits on scope, before long the scope extends and tasks take ever more time. We acknowledged that it’s not possible to accurately estimate any non-trivial task, so we gave up on estimates. The downside then of our Kanban system was that it lacked time limits and scope of tasks. With Kanban developers can take their time, because the work is only released when it’s done. We continued with the above mentioned Kanban system until we reached about 25 people. Managers don’t drown in tickets and minutia. Individual engineers have real impact on the product roadmap, and make nearly all decisions about the details of implementation themselves. It’s common that an 8-week project will have only 2-3 sentences of high-level requirements. We discuss larger projects with individual engineers, and leave it up to them to fill in the details and to come up with solutions. We do not spend much time writing down detailed requirements. As a result our Product team may own the strategy and long term vision for k6, but our engineers are empowered to drive smaller scale projects and individual tasks themselves. We are the target audience for our own product. Individual impact on the product roadmapĪt k6, developers build tools for developers. On top of that, the system required minimal maintenance, so it was always up-to-date. Our lists were: Incoming => Backlog => Doing => In staging => Done (in production).Įveryone knew what to work on (top of Backlog), everyone was able to see what others were working on ( Doing) and what was close to being released (to staging). What ended up working was: a clear vision shared by all team members and one Trello board implementing Kanban. Most of these processes and tools sounded good in theory but for whatever reason didn’t work for us.
Before we knew it, we spent half the week just talking to each other.Īt this point we tried many different things: 2-week sprints, 4-week sprints, sticky notes, standups, Scrum, estimates, flows, streams and an endless number of ticketing systems. However, when k6 grew to 10-12 people, that model stopped working. At this size there is no need for a formal process. Everyone knows what to do because everyone can speak directly to everyone else. When a company has 4-5 team members, very little organization is needed. It turns out you can’t run a company of 30 people the same way you run a company of 15 🤷 Throwback time! We have noticed that every time the company doubles in size, the system we use at that time stops working for us: time for a change. We needed to change the way we organize ourselves because we outgrew the previous system. In this post we will explore how we aim to achieve rapid growth while staying productive.Ībout a year ago we changed the way we work. We're at 30 people now, so that's quite the explosive growth we have ahead of us. We currently have 17 open positions, across the organisation - mostly in Engineering, but also in Sales, DevRel, etc. We are growing rapidly, and are a little unconventional in how we organize ourselves, so I thought it would be a good idea to share in more detail how we build and ship software, being a remote-only company. August 7, I joined the Office Hours our Developer Relations team runs on a weekly basis, to talk about how we work at k6.
0 kommentar(er)
