Total 11 PostsBCTO[Update] Adding Git accounts by administrator without developer invitation
The existing BCTO invited individual developers, and those developers could add their own work Git accounts and Repositories themselves. This was the meaning of BCTO onboarding for developers collaborating together. However, this method had the difficulty and inconvenience of having to invite all the developers in our development team one by one and have those developers register the project redundantly. Therefore, an update was made to provide convenience by completing all settings by adding the Git account and the Repository to be managed by the administrator only once, and not having to wait for the registration of all developers. To do this, The administrator who wants to register must request a Git account invitation from the developer and have the authority of the Git account. After that, 2. Go to the settings page 3. Register the Git account you want to manage 4. Agree to register the Git account Application 5. Select the registered account in BCTO 6. Select the Repository you want to manage and register it, and the repository registration is complete Through this, it is possible to check the development status and receive daily reports immediately without waiting for developer registration and repository registration If you find any problems or need help, please contact nick@extory.co2025.06.17![[Update] Adding Git accounts by administrator without developer invitation](/_next/image?url=https%3A%2F%2Fdev2job.s3.ap-northeast-2.amazonaws.com%2Fpost%2Fimage_e4b5c117-eb65-411f-8a5b-dbfa24531205png&w=384&q=75)
Development TeamIs our development team's Scrum working properly?
Many development teams hold Scrum meetings every morning. But why do many developers consider Scrum one of the 'most hated tasks'? Scrum is a term originally derived from rugby. You may have seen the scene where players from both teams put their heads together and push each other to compete for the ball when the ball stops during the game. What's important in this scene is role division, cooperation, and immediate execution. It's not just a meeting, but a moment of focused tactical execution to regain the ball. However, in many companies, Scrum is merely used as "a short report of what you did yesterday and what you will do today." In fact, when I first joined a startup, the CEO said, "Scrum is done standing up!" and made everyone stand up and only reported for an hour. The essence of Scrum was gone, leaving only the format of 'a meeting held standing up'. Real Scrum is a process where the team shares accurate information in a short amount of time, establishes strategies to overcome problems through cooperation, and quickly transitions to execution. It should be a real "movement to win the ball," not a report-like feeling. Manager: "Developer A, what did you do yesterday?" rather than Developer A: "Some design modifications are needed for the feature I am currently implementing." It's time for a Scrum where practical discussions and requests like this are exchanged. Scrum is coordination, not reporting. How about rethinking Scrum that the development team doesn't hate, starting now?2025.06.12
SprintMethodology Differences in IT Product Development: Rapid Development vs. Continuous Improvement
When developing IT products, is rapid development always the most important value? These days, many project management tools offer sprint-based productivity management services, aiming to increase team productivity through rapid product development and optimization of periodic sprint execution. This method is certainly effective in quickly creating products. ✔ It's good to set small goals and execute them quickly to get results, ✔ Quickly launch the product, ✔ It has the advantage of being able to quickly reflect market and user feedback. However, is just making things quickly always the best answer? After the product has established itself in the market or after we have created the product we want, Now, we need to consider stable operation and continuous improvement over a longer period, rather than just 'rapid development'. However, achieving long-term improvements with a sprint-based approach is not as easy as it seems. ❌ Limitations of the Sprint Method 1️⃣ Short goal cycle is not suitable for long-term improvement Since sprints are a method of quickly achieving short-term goals, they do not align well with continuous improvements that need to be carried out over a long period. 2️⃣ Focus on functional changes, making it difficult to consider improvements with a big picture There is a tendency to focus on short-term goals such as adding/changing features rather than long-term improvements. Prioritizing achieving small goals within a sprint often takes precedence over improving the overall product completeness. 3️⃣ Difficulty in maintaining a consistent improvement flow due to gaps between sprints As goals are set and pursued for each sprint, it is difficult to maintain a consistent direction for improvement, and operational disruptions can occur. In the long run, the artificial deadlines of sprints can also be a burden on improvement and operation. Development Team Optimization for Continuous Improvement and Operation Now, if the product is operating stably and continuous improvement is needed, Simply performing specific goals quickly in small units may not be the best option. ✅ It is important to help each developer perform their best work. ✅ Team operation becomes more efficient by understanding the developers' tendencies and work styles and utilizing optimization tools. 💡 Tools are needed to understand the work history and strengths and weaknesses of each developer and to provide an optimized work environment. 💡 Rather than developers meeting quick deadlines, tools are needed to look into each individual's work to increase work productivity by building on the work of yesterday and today. 🚀 It's time to consider product development methods, not just speed, but also long-term operation and improvement.2025.04.09
Developer PatternUsing Prejudice in Development Team Management
Preconceptions about ordinary people are not very useful for positive information. However, preconceptions about a developer's work pattern can be excellent underlying data for development team management. According to actual experience, schedule adjustments were of great help through preconceptions about developers' development habits/patterns. Schedule adjustment through preconceptions examined with two cases In the case of Developer A, this friend is always bound to take longer than expected A usually processes shared schedules tightly or tends to be a little late. If A presents a 5-day work schedule, the manager can use this as a reference and establish a plan with a buffer of about 6 days. By reflecting this preconception, A can do his best to complete the work within the schedule without any burden, and as a result, a relationship of trust is formed. In the case of Developer B, always take the schedule with a buffer Conversely, B approaches the schedule with a relaxed style. The 5 days that B mentions are likely to be kept, and in case of an urgent schedule, it is possible to explain the situation and bring a buffer to reduce the schedule slightly. Reasons for utilizing preconceptions Efficient schedule adjustment: By considering delays and matching the presented schedule stably, time delays are reduced in advance until development is completed. Building a relationship of trust: Conversations that can embarrass developers and managers are reduced, and through a high degree of understanding, they trust each other's words (correction through preconceptions) and development can proceed based on that trust. Reasons why it is difficult to create preconceptions Attention: It requires a great deal of focus and attention on each developer, from their usual development habits to their lifestyle at times. Experience: Experience in development and development management is essential, and all experiences from the past history of developers to the present must be recorded and remembered. As the number of developers increases, the management of the above two items becomes exponentially difficult. Utilization of professional tools In order to understand preconceptions, that is, the habits and patterns of developers, it is necessary to use professional tools: Real-time work status monitoring Analysis of individual developers' work patterns It helps managers to lead the team more professionally by providing effects such as improved accuracy of schedule prediction and adjustment, and gives 'experience'. Do you know the characteristics of each developer in our team?2025.04.09
KPIIT Developer's KPI/OKR Management
Why is KPI/OKR so difficult for developers? At the beginning of the year, many developers fall into one common concern. It's KPI (Key Performance Indicator) and/or OKR (Objectives and Key Results) setting. It's unfamiliar, and it's just difficult to know what to set and how. It even causes a further disconnect with managers. Why is it so difficult? Reasons for Difficulties in Setting KPI/OKR The reason is the nature of development work. Generally, businesses establish annual goals and plans, and accordingly, they deliver requests for new feature development or modifications to the development team. However, development work has the characteristic that it cannot plan everything from the beginning and proceed. For example, is it appropriate to set simple goals like "10 new features, 100 debugging"? In reality, if the business cannot accurately define all development details for a year, it is almost impossible for developers to set clear KPIs accordingly. So, should developers not manage KPIs/OKRs? That's not the case. Rather, a developer's KPI/OKR management becomes an important record of how effectively they have supported the business and what products they have developed. What's important in this process is recording and managing past development work. If you clearly organize the developed features and improvements, the goals of each task, the Key Results, and your role in that task, you can more specifically measure the developer's individual KPI/OKR based on this. KPI/OKR Management, Not Easy, But Possible Of course, manually carrying out these records and management is not easy. But if you use an efficient tool that allows you to view developers' tasks and development details by developer, by task, and by period, the story changes. By utilizing such a tool, you can effectively organize a developer's activities for a year and more clearly evaluate KPIs/OKRs. Conclusion A developer's KPI/OKR is not simply measured by numbers. It is more important to record contributions to the business, the value of the developed product, and your own growth process. To this end, it is essential to utilize tools that enable effective recording and management. Why don't developers approach KPI/OKR not just as a burden, but as an opportunity to objectively confirm their performance and grow?2025.04.09
DeveloperUnderstanding the developer's mindset and effective schedule management
When developing, planners and managers sometimes say, "ㅉㅉ, the developer's mindset..." What is this developer mindset? I remember hearing it when developers reacted negatively or presented defensive schedules regarding development/issues, but developers don't react that way from the beginning. When a development task is brought up and asked, "How long will it take?" and if the feature isn't completed by the date the developer provides, after experiencing the endless responsibility of "You set the schedule," they tend to set the schedule to 1.5 to 2 times longer and answer as negatively as possible. This is because they are held solely responsible for situations they didn't anticipate before starting development, but as time goes by and experience accumulates, they "predict" such situations and set the schedule. Developers who become experienced may or may not keep to the schedule, but it doesn't have a positive effect on companies, especially small ones like startups. If a developer's schedule isn't kept, and if a problem arises despite the developer's efforts, you should accept and acknowledge the developer's explanations as much as possible, so that they can set the schedule from the company's perspective in the future. Also, they will show a more positive reaction to our business, leading to responses like "I'll try, even though it seems difficult" rather than "It can't be done, it will take a long time." Understanding the Developer Mindset and Effective Schedule Management When developing, planners and managers often say, "That's the developer's mindset..." In particular, this expression is often heard when they show a negative reaction or present a conservative schedule during the schedule estimation process. However, developers don't take this attitude from the beginning. The Developer's Schedule Estimation Method and the Formation of a Defensive Attitude Generally, when a new feature development is requested, the planner or manager asks, "How long will it take to develop this feature?" The developer carefully estimates the schedule and answers, but unexpected problems often arise during the actual development. However, if the development schedule is delayed, the developer often bears the burden of "You set the schedule, so you have to take responsibility." As this experience repeats, developers become more conservative in their schedule estimation. For example, they may increase the estimated time by 1.5 to 2 times, or they may choose to assume the most negative scenarios and answer accordingly. This is not a simple defense mechanism, but a rational response formed through experience. It is the result of learning that schedule adjustments are necessary, considering the many unexpected variables in the actual development process. Experienced Developers' Schedule Prediction and the Startup Environment Developers with experience consider these variables and estimate the schedule more realistically. However, a high schedule adherence rate does not necessarily have a positive effect on small companies like startups. This is because if developers set overly conservative schedules, the company's ability to respond quickly may be reduced. In a startup, quick execution and appropriate risk management are important. Therefore, if the development schedule is delayed, it is important to acknowledge it and respond flexibly if the developer has made sufficient efforts but unavoidable problems have occurred. Rather than blaming the developer with "Why was the schedule delayed?", an approach of "What problems were there, and how can we solve them?" is needed. Creating a Positive Culture for Collaboration with Developers To prevent developers from taking an overly defensive attitude, it is necessary to create a culture that accepts and acknowledges the developer's explanations when the schedule is delayed, rather than rejecting them unconditionally. That way, developers will also consider the company's perspective more when setting schedules and can be more proactive in their work. For example, it is important to encourage developers to respond with "I'll try, even though it seems difficult" instead of saying "It can't be done, it will take a long time." To do this, it is necessary to create a collaborative environment based on trust and avoid a culture that excessively criticizes failure. Supporting developers to have a positive attitude towards new challenges will ultimately help the company's growth. Conclusion The phrase 'developer mindset' is often used in a negative sense, but in fact, it is a realistic response formed through experience. For effective collaboration, it is important to understand the developer's schedule estimation method and not to overly burden the responsibility for schedule delays. Through this, both developers and the company can move forward in a positive direction.2025.04.09
DebuggingWhy developers' bugs in IT development shouldn't be evaluated negatively
In IT development, there is a tendency to consider bugs as a great sin, and while bugs do degrade the quality of the service, it seems to be a matter of consideration as to whether the developer who created the bug should be criticized. I have experience as both a developer and a development manager, and I am sharing the experiences I have gained through them. In the development and operation of IT services, the occurrence of bugs certainly makes the user's service experience unpleasant. So, should the developer who created the bug be criticized? It seems so at first glance, but it is not. Before, an acquaintance in a specific field talked about using the number of bugs as a performance management indicator for developers. Thinking that bugs = bad, and the developer who created the bug = an incompetent developer, or a developer who is not helpful, can have a very negative impact on the development team. If bugs lower your performance score, no one will try to develop unreasonably and the schedule will be very defensive. Because you have to avoid bugs. They will oppose unreasonable development and try to pass unfamiliar development to others. The development team will take a very negative trend. Especially in the case of startups, where there is a lack of skilled developers and little time available, if you try to evaluate developers based on bugs, the phenomenon of avoiding development will be noticeable. Bugs are more often caused by a lack of experience in the relevant domain or a lack of development experience than by development skills. It is normal for the frequency of bug occurrences to decrease over time, and if the frequency of bug occurrences suddenly increases, it is recommended that you discuss the allocation of development tasks or the lack of development time with the development team. What tasks are our developers focusing on now? Is the bug fix frequency increasing or decreasing? 2025.04.09
Front-end developerFront-end (screen) developers are wronged!
I'll talk about my experiences as a developer and as a manager! Actually, it's hard to be as wronged as a front-end developer when it comes to schedules. Work starts when the design is finished, and work can be completed when the backend API development is finished. It's not often that front-end developers are lazy or diligent, causing work to be done quickly or delayed. But if the development is not finished, the CEO and the manager will urge the front-end developers. "When will the screen come out?" It's easy to explain that the screen work is not progressing because the design is not out, but it's a little difficult to explain that the screen development is not completed because the backend function development is not completed. In that case, you can share Git to let them refer to the development of the backend developers. However, in the case of front-end developers, they may not have been invited to the backend API repository, so ask the administrator to invite them to the backend repository. Or, if you use a service like BCTO, you can show the commit history even if you are not invited to the repository, in conjunction with the task. So, I recommend our front-end developers to watch YouTube or Netflix if they have nothing to do. Because only the front end will be busy soon.2025.04.09
Backend DeveloperBackend (server) developers are wronged!
As a former developer and manager, I'm here to address the grievances of backend developers. When working at a startup, the CEOs often ask "Is our team A working?" Backend developers especially receive such misunderstandings. Unlike front-end development, where changes can be shown almost daily, backend development often takes several days. Moreover, when writing reports, the content of yesterday, the day before yesterday, and today may be the same, and even if you ask, you might get the same report, "We are developing the sign-up feature," which leads to the misunderstanding of "Aren't you being insincere?" In addition, even after development is complete, what can be shown is a DB query value or a JSON response value, and in many cases, it doesn't seem like a significant accomplishment. The backend development becomes visible only after the front-end development is complete, but it looks like the front-end has done everything. To eliminate misunderstandings and appeal that you are working smoothly, it would be effective to show it through Git work history. <GitLab Commit log> Or, it can be effective to show it by linking it to the tasks you have handled more easily. Or, there is also a way to show the current development progress. If you are curious about what backend developers do, ask them to show you through Git! (I'll talk about the grievances of front-end developers soon!)2025.04.09
Development Team ReportDaily reporting tasks and documentation that reduce developer efficiency
As a developer and manager for about 18 years, one of the tasks that developers hated was "reporting what I'm doing every day." It could be writing documents or meetings. https://www.explore-group.com/blog/top-10-developer-hates/bp60/ Top 10 Developer Hates | Blog Being a developer or programmer is a great job, but no job is perfect all the time. Find out what annoys developers the most in our Top 10 Developer Hates www.explore-group.com It's also busy just taking care of development, but reporting at the end of the day and verbally reporting in the name of scrum when you go to work, and newly composing the content every day is quite stressful. However, if the manager cannot accurately see the development team, they have no choice but to request daily reports even if the developer is annoyed. Otherwise, you won't know what they're doing. Among them, the difficulties of backend developers are quite severe. It is not visible, cannot be confirmed, and if they are doing the same development history for several days. It looks like they are not working or are perfunctory in their reports to the manager. But! A developer's development work is more transparent than any other work. Because the development history is all uploaded to Git services (represented by GitHub), and it is difficult to tamper with it, and the update history is not actually used for development reports, but is left for when you need to look back at your development history, so you can easily understand the development history and understand it. You will leave comments and Commit. However, the Commit history and development Activities of these services are for the development of developers, so it is quite unfriendly to read if you are not a developer, so you don't look at it closely. If you can easily read these details, it will be an environment where developers can focus more on development than reporting, and managers can easily understand the current development progress of our team at any time. Ask the developers to invite you to the Git service and check the messages. And if you share the development situation with the developers, it will be easier for the developers to talk about their development situation. And also, if you are using a ticket service (represented by Jira), by connecting the ticket service and Commit messages, "Ah! There was such a development change to perform this task I gave," you can more easily see what tasks our development team is currently processing and what changes have been made. A new year has begun. I will look further into the problems between developers/development teams and managers, and if there is any content that can be helpful, I will continue to upload it!2025.04.09
