top of page

Collecting Opportunities for Growth: How the Lemonade Development Team Works

"Everything in the software changes. Requirements change. Design changes; business changes; technology changes; teams change.Team members also change. Change must happen, and change does not become a problem itself. Our inability to overcome change is the problem."

– Kent Beck, <Extreme Programming>

The lemonade team is sensitive to change; we test and improve applications in shorter cycles, and we're constantly working to make the number of bugs we face to a minimum in a changing development environment.

So we're used to CI/CD automation and unit testing; it's no wonder that constantly bringing opinions together (Declaration) and testing the effectivity of those results represents the culture itself of the Lemonade development team.

The most important factor in creating and maintaining a culture like this is in a 'free discussion culture that's not position / career engrossed'; to be so focused on change, you need a variety of ideas; most of the new ideas that have brought about innovation have come from free-flowing atmospheres, and they've not been the key to easily solving difficult problems that might be outlandish.

That's why we try to create an environment where members can think proactively: Here are some ways the lemonade development team can gather feedback and test growth.

Integration :

– Daily stand-up meeting | let our development look the same place

At 11:40 a.m., Google Calendar unfailingly reminds everyone of the development team's daily event. "It is 10 minutes before the development team's Daily Stand-Up Meeting."

At this stand-up meeting, we quickly identify and share what we've done with each other yesterday and what we'll be doing by tomorrow morning; whether there's no specifics in our work, whether there's anything out of the way of work, or whether there's anything unusual about our health or work condition.

The focus of this meeting is "simplicity"; the meeting time is not more than 10 minutes; for more detailed discussions, we host separate meetings or discuss them in depth at regular meetings.

Deployment :

– The development team's regular meeting

Weekly Meeting

What happened for a week is recalled at the weekly meeting held every Friday. It between one and two hours. Here, we share agenda items from lead meetings or other meetings as well as weekly tasks, and discuss topics that we want to share. The topics presented individually by the team members are prioritized by voting by all development teams. Topics with the highest score are the top priorities. When discussing each topic, focus on listening to everyone's opinions and finding the best answer.

Monthly Meeting

On the last Friday of every month, a monthly meeting is held. It's almost like a weekly meeting, but at this time, we have time to comprehensively reflect on the past month's events and share and design steps to take next month. We focus more on the big unit periods of a month.

Testing :

– Pull Request | Code review using it | Showing my growth

We believe that we need to develop a variety of features and services quickly, but when we value speed, we are not only more likely to encounter bugs, but inversely, code quality will also be poorer.

Code reviews are one of our team's signature cultures, reflecting only features that have received and passed feedback from team members on the service, as one way to minimize the possibility of this problem. Pull request (note: A particular developer tells his colleagues what changes he made on the system. For convenience, I can understand the concept of "informing people of my activities.") This allows members to review, and the other side of the review request can be any team member, regardless of their job title, career, or age.


bottom of page