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 re-establishes the development team's daily events. "It was 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 :

– To show our | the development team's regular meeting

Weekly Testing

The work that took place every week every Friday, We recall from weekly meetings; short, 1 hour, 2 hours long; here we share and discuss topics from lead meetings or other meetings, as well as topics that team members want to share.

Monthly Testing

We have monthly speaking on the last Friday of every month; it's almost like weekly speaking, but we take the time to comprehensively look back at the things of the past month and share and design for the steps we're going to take next month; we're talking about a big unit period of one month.

Testing :

Showing my growth in | code reviews using Pull Request

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 feature that has 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.