Total 10 PostsDevelopment 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, ✔ It allows for quick product launches, ✔ It has the advantage of quickly reflecting market and user feedback. However, is just making things quickly always the best answer? After a product has established itself in the market or after we have created the product we want, we now need to consider stable operation and improvements that have continuity 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️⃣ The short goal cycle method is not suitable for long-term improvements Since sprints quickly execute short-term goals, they don't align well with continuous improvements that need to be carried out over a long period. 2️⃣ Focus on feature-based changes, making it difficult to consider the big picture for improvement There is a tendency to focus on short-term goals like adding/changing features rather than long-term improvements. Prioritizing the achievement of small sprint-based goals 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's difficult to maintain a consistent direction for improvement, and operational disruptions can occur. In the long run, the artificial deadlines of sprints can also become 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 executing 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 provide an optimized work environment. 💡 Tools are needed to look into individual work to increase work productivity by accumulating work from yesterday and today, rather than developing to meet quick deadlines. 🚀 It's time to consider not just speed, but also long-term operation and improvement in product development methods.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 operating a development team. According to actual experience, schedule adjustments were greatly helped by preconceptions about developers' development habits/patterns. Schedule adjustments 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 plan with a buffer of about 6 days. By reflecting this preconception, A will 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 room Conversely, B approaches the schedule with room. The 5 days B talks about 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. Why use preconceptions Efficient schedule adjustment: By considering delays and ensuring that the presented schedule is met stably, time delays are reduced in advance until development is completed. Building trust: Conversations that can embarrass developers and managers are reduced, and through high 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 developers' past history to the present must be recorded and remembered. As the number of developers increases, the management of the above two items becomes exponentially difficult. Use 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 check Analysis of individual developers' work patterns It helps managers to lead the team more professionally by providing effects such as improving the accuracy of schedule prediction and adjustment, and giving '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 face a common concern. It's KPI (Key Performance Indicator) and/or OKR (Objectives and Key Results) setting. It's unfamiliar, and it's difficult to know what to set and how. It even causes a greater disconnect with managers. Why is it so difficult? Reasons for Difficulties in Setting KPIs/OKRs 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 debuggings"? Realistically, 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, developers' 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 the task, you can more specifically measure the developer's individual KPIs/OKRs based on this. KPI/OKR Management, Not Easy, But Possible Of course, manually performing these records and management is not easy. However, 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 tools, you can effectively organize the developer's activities for a year and evaluate KPIs/OKRs more clearly. Conclusion Developers' KPIs/OKRs are not simply measured by numbers. It is more important to record the contribution to the business, the value of the developed product, and the process of their own growth. To this end, it is essential to utilize tools that enable effective recording and management. How about developers approaching KPIs/OKRs not just as a burden, but as an opportunity to objectively confirm their performance and grow?2025.04.09
DeveloperUnderstanding the Developer Mindset and Effective Schedule Management
When developing, planners and managers would sometimes say, "Ugh, that developer mindset..." What is this developer mindset? I remember hearing it mainly when developers reacted negatively or defensively to certain developments/issues, but developers don't react that way from the start. When a development project is brought up and the question "How long will it take?" is asked, and if the feature isn't completed by the date the developer suggests, after experiencing the "You set the schedule" infinite responsibility a few times, they start to set the schedule to 1.5 to 2 times longer, and they tend to answer as negatively as possible. This is because developers are held solely responsible for situations they couldn't have anticipated before development began, but as time goes by and experience accumulates, they start to "predict" those situations and set schedules accordingly. Developers who become experienced may or may not keep to their schedules, but that doesn't have a positive effect on companies, especially small ones like startups. When a developer's schedule isn't kept, if a problem arises even though the developer has made an effort, you should accept and acknowledge the developer's explanation 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, and instead of reactions like "That won't work, it'll take a long time," you can get reactions like "It seems difficult, but I'll give it a try." Understanding the Developer Mindset and Effective Schedule Management When developing, planners and managers often say, "Ugh, that developer mindset..." In particular, this expression is often heard when developers react negatively or present schedules conservatively during the schedule estimation process. However, developers don't take this attitude from the start. Developers' Schedule Estimation Methods and the Formation of Defensive Attitudes 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 tend to 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 is repeated, developers become more conservative when estimating schedules. For example, they may increase the estimated time by 1.5 to 2 times, or they may choose to assume the most negative scenario and answer accordingly. This is not a simple defense mechanism, but a reasonable response formed through experience. It is the result of learning that schedule adjustments are necessary, taking into account the many variables in the actual development process. Experienced Developers' Schedule Predictions and the Startup Environment Developers with experience consider these variables and estimate schedules more realistically. However, a higher schedule adherence rate does not necessarily have a positive effect on small companies like startups. This is because if developers set schedules too conservatively, the company's ability to respond quickly may be reduced. In startups, quick execution and appropriate risk management are important. Therefore, if the development schedule is delayed, it is important to acknowledge and flexibly respond if the developer has made sufficient effort but unavoidable problems have occurred. From the developer's perspective, an approach of "What problems were there, and how can we solve them?" is needed rather than the blame of "Why was the schedule delayed?" Creating a Positive Culture for Collaboration with Developers To prevent developers from taking overly defensive attitudes, it is necessary to create a culture that accepts and acknowledges the developer's explanations when schedules are delayed, rather than rejecting them unconditionally. By doing so, developers will also consider the company's position 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 give it a try, even though it seems difficult" instead of saying "That won't work, it'll take a long time." To this end, it is essential to create a collaborative environment based on trust and to avoid a culture that excessively criticizes failure. Supporting developers to have a positive attitude towards new challenges will ultimately help the company grow. Conclusion The term '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 them with 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 should not 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 whether the developer who created the bug should be blamed. 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 degrades the user's service experience. Then, should the developer who created the bug be blamed? It seems so at first glance, but it is not. Previously, an acquaintance in a specific field talked about using the number of bugs as a performance management indicator for developers. Thinking that bugs = bad, developers who create bugs = incompetent developers, or developers who are not helpful, can have a very negative impact on the development team. If bugs lower your performance score, no one will try to develop excessively, and the schedule will also be very defensive. Because you have to avoid bugs. They will oppose unreasonable development and try to pass on 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 limited time available, if you try to evaluate developers based on bugs, the phenomenon of avoiding development will become 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. The frequency of bug occurrences is normal to decrease over time, and if the frequency of bug occurrences suddenly increases, it is recommended to 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!
Let me tell you about my experiences as a developer and 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 a front-end developer is lazy or diligent, causing work to be done quickly or delayed. But if the development isn't finished, the CEO and the manager will urge the front-end developer. "When will the screen come out?" It's easy to explain that the screen work isn't progressing because the design hasn't come out, but it's a little difficult to explain that the screen development isn't complete because the backend function development isn't complete. In that case, you can share Git and tell them to refer to the backend developer's development. 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
Project ManagementReasons why using project management tools is becoming increasingly cumbersome
There are many project management tools available for IT development management, such as Jira, and also Asana, Trello, and Swit, which can be used to manage tasks using tickets, etc., in addition to IT. By the way, are you using these services as actively as you initially adopted them? If you don't use them as well as you did at first, is it because you've become lazy? <I'm too lazy to write> After using these tools for a certain period, you may feel that using them is like another task, and you may feel like you are using them by force. There are many reasons, but from the developers' perspective, it seems to be even more so when they have to pay attention to tasks other than development or project progress. In my experience, the project management tool became deactivated when the representatives and managers, and other related departments, did not use the tool. At first, everyone seems to use it actively after hearing how to use it, but as time goes by, those who don't know about development, such as the representatives, find it difficult to use the tool and can't get the information they want, so they request, "Please submit a daily report in Excel." If this happens, the project management tool becomes completely useless for developers. <I'm too busy just taking care of development> So, is there a way to prevent this situation and allow developers to focus only on development and tickets? Use BCTO. BCTO integrates with project management tool APIs, so developers can use them as they always have, and it only shows the information that the representatives need to see. Developers only focus on development and manage their tasks using project management tools, and the representatives or development-related personnel can easily read them and communicate with the developers based on the project management tool. <Tickets in progress and detailed development history> <Detailed information of the ticket> BCTO will create an environment where developers can truly focus only on development.2025.04.09
