We had a 1-on-1 meeting with all members over

We had a 1-on-1 meeting with all members

We had a 1-on-1 meeting with all members over the past week. The feedback on the ejail from the developers of our vision technology team was very good.

"The last six months have been the period where I grew the most," "I think I just found out what it's like to develop software in an egyle way," and "It's been great to learn the egyle platforms like Jira and Gitlab."

For the first time in our company, the vision technology team started developing software using the Ejail method. In order to ensure 'development efficiency' and 'quality', which are the ultimate goals of the Ejail development process, business processes such as 'creating frequent bottom-up work', 'bimonthly sprint review', 'monthly milestone and integrated test' were established. In order for Ejail to be settled 'properly', it must be settled as a culture within the team beyond development methodology or platform.

Underneath that, values such as 'trust', 'sharing', 'cooperation', 'voluntary', and 'efficiency' must be 'properly' understood, platforms such as Jira and Git must be 'properly' used, and regular processes such as scrum, code review, print, and milestone must be 'properly operated'. If any of these do not work 'properly', the edgyle process is likely to become a bomb with a greater workload than effectiveness.

"The Sprint Planning Conference is a meeting to prioritize work in the backlog and identify the storage points assigned to each developer. Each story unit should be defined in units that can be completed in up to 2-3 days, and the output should be correctly defined so that peer reviewers can verify that work is complete. With the backlog so unprepared right now, the Sprint Planning Conference is meaningless."

Even in the vision technology team, which has developed in an ego-type method and completed product v1.0 launch over the past five months, it is still difficult for each developer to accurately define the story work. Story is not a simple functional definition, but a definition of 'As a USER, I want to have a FEATURE to solve a PROBLEM to archive a GOAL'.

It may seem inefficient to define the last unit of work in the form of a sentence with a story like this, but if this story is defined correctly, many subsequent meetings can be shortened and decision-making can be made clearer. In particular, there is no need to ask questions such as, "Why do I have to do this?" "Why do I do this?" "Who should do this?" or, "When does this work?" or biweekly sprint review/planning meetings can be conducted very efficiently.

In addition, for work sharing or code sharing, which is the biggest advantage of ejail, this clear story definition is very efficient in communication and reporting between developers and organizations. (In other words, if I just check the Jira board, I don't need to call the development team to receive a work report.)

The development culture of our vision technology team seems to have been very well established. Despite the differences in skills and work processing speed between developers, they do not criticize or complain to each other, but complement, help, and cooperate with each other to complete the milestone every month. It adheres to the basics such as daily code commitment and branch creation, peer code review and unit testing at merge requests, etc. If the definition of story and backlog work creation, which are still a little insufficient, are more established, it will be a perfect edge development team that does not require large-scale reporting or decision-making meetings.  

Efforts are being made to establish an Eile development culture at CJ Korea Express' TES Research Institute. There are still a lot of legacies and lack of experience or trust in Eile development, but I hope we can change the perception that 'Eile can only be done by startups, not by large companies'. Isn't Google a big company, too?