Our Development Process

We are currently on the fifth iteration of our development process. This is normal and expected, because as the team and company grows, old processes become obsolete. Below is a brief history timeline of what we have gone through to get to where we are now.

Iteration 1: Scrum + Jira

When I started, more than three years ago, there were two developers on the
team and they were doing Scrum together with Jira. Coming from a large organization where we used Jira, and where I saw what huge mess a tool can cause, I immediately scraped Jira in favor of pure Github Issues. After all, we were using Github, so why not use what’s already there, right?

It worked great when the issues were few, but quickly became unmanageable. We did a huge mistake to use Github Issues as a capture tool for everything and it quickly grew into a huge pile of issues where you could find anything. Github Issues had become a garbage dump reeking obsolete information.

Iteration 2: Github + Kanban

Back then we were still doing Scrum with two week long sprints, but that quickly got really discouraging because we never managed to finish a single sprint. All these urgent issues coming from the side that required immediate attention. Being a young company, trying to get it’s first product out of the door, that is kind of expected. We decided to ditch Scrum in favour of Kanban and started doing continuous day-by-day prioritisation. Our progress and our mood improved. We were moving fast, kicking ass and giving high-fives left and right. Our team was growing too.

Iteration 3: Waffle + Kanban

The team demanded something more sophisticated than pure Github Issues and someone hinted about Waffle.io. We like waffles and the tool was free too, so we decided to give it a try. Waffle served us well for a long time but as with everything, we outgrew it too. People demanded better tooling.

I was also trying to run the show with dailys, retros, and roadmap planning
meetings. It was a lot of work alongside with my other commitments and I had a hard time keeping up with everything. Very fast I became a bottleneck. Because of that people started sneaking in new tickets and started reaching out directly to developers, basically creating a parallel process. Things got out of control and we had a really hard time keeping up with the status on things. We needed help.

Iteration 4: PT + Kanban

Our process got out of control and had become unmanageable so we hired a PO to help us, Piotr Podhajski, who not only brought inspiration for a new process but also suggestions for new tools. He did some research, scouted the market, and after his findings we decided to go with Pivotal Tracker, and Kanban. Things were great, people were inspired, and many of us loved the new tool and the new process.

We were growing and our tech team was getting larger. The process had
improved. We were still doing Kanban but this time with epic based approach and “weekly sprints.” Basically, each Tuesday we would hold a planning meeting where we would present the work, that needed to be done, in forms of epics. Developers volunteered to work on an epic and also asked other team members for help if the epic was too large for one to handle. Internal recruiting. So basically, we formed micro teams for every epic to work on, that would then dissolve when the epic was completed.

Our clarity and our speed had improved. However, it was still kind of hard to know the status of tickets and who was working on what, because there were so many developers involved at the same time. Also, suddenly there were a lot of meetings I had to attend. Dailys, planning, pre-planning, backlog grooming. People started to demand better tooling and I demanded better process, because it started to get unbearable with all process related meetings.

Iteration 5: Jira + Scrum

This year we are back to Jira and Scrum, and smaller autonomous teams. Each team is composed of 3–4 developers, where one of developers is a team lead. We are also back to two week sprints, expect this time we are completing them.

There is also a new virtual team called SWAT. Every sprint one developer from
each team joins the SWAT team for the duration of the sprint where she only works on SWAT tickets. SWAT’s responsibility is to squash bugs and help our onboarding team. SWAT has its own Jira project and uses Kanban, because there is constant prioritization juggling going on and we need to be fast. Speed is one of our core strengths that we are really proud of.

Speed is one of our core strengths that we are really proud of.

While the teams were crushing it, I had a hard time keeping up with the status of things, because I was now detached from the daily process. In a way it was relieving but also a little worrying, and lonely. Other teams also didn’t know of what others teams were working on too, so they were detached too. We solved this by adding weekly Scrum of Scrum meetings where me, PO and team leads meet and brief each other.

Iteration X: The Future

As you might have noticed, we have tried a bunch of different tools to track
our work and progress. Tooling is important, but lets be honest, there is no perfect tool. All tools have limitations, unless you can afford to build one yourself of course. One that fits your culture and your process. But that requires time and energy. And money. While building internal tools is super fun we are still growing and need to invest these assets into our products instead.

Our team is distributed, and because of it, sometimes we are a little in the dark when it comes to knowing the current status of things. Different people on our team have different needs. Some of us would like to have almost instant, real-time feedback on the status of things, while others are cool with people getting back to them when something they are working on is done.

All processes have flaws, you have to keep fighting and find what works for you and your team. Find the balance between pros and cons. After all, a team is a group of highly skilled individuals who all have different needs and come
from different backgrounds. It’s hard to please everyone. Finding a good and efficient process is a never-ending process. I heard that it takes around 10 years to implement Lean correctly.

Change is inevitable when you grow, and yes, it’s often painful. And that’s
OK. That’s actually good. Expected. I would be more worried if people just
blindly accepted the present, if they didn’t want to change, if they got too comfortable. Change is what makes you grow.

Tech Process and OKRs

OKRs and Scrum might seem like similar things. Both let you set goals with
measurable outcomes and work towards them. However, in a way, they have
nothing to do with each other. They are not competitors, but complements. OKRs are like choosing a theme for your dinner party, Korean, Mexican or Italian, and Scrum is like cooking — you come up with a menu and then you turn it into reality for your guests to enjoy. OKRs are directional but without clear actions, while stories and epics in Scrum are very concrete with defined outcomes. OKRs help you set direction and company goals. By first knowing where you are going only then you decide and choose the supporting tech projects. How you then get them done is up to you. Scrum is a common framework for this. I hear that many teams are successful with Kanban as well.

Here is a great article that explains OKRs well — Are you doing OKRs
right?

Conclusion

Finding a process that works is hard. Change is hard, but you have to keep an
open mind. Complains won’t help, but constructive feedback and valid arguments will. We are still learning. Retrospectives are a great tool for tweaking things as you go. Don’t be afraid to try a bunch of different process tools to find which one sucks the least.

I never lose. I either win or I learn. — Nelson Mandela

Most important of all — don’t give up, but see all failures as a learning experience!