Communication in teams is an important but difficult issue. In a Scrum development process, we use the Daily Scrum meetings to inform others about important problems, news and events in the project. When persons are absent due to holiday, illness or travel, they miss relevant information because there is no document that protocols the content of these meetings. We present a concept and a Twitter-like tool that improves communication in a Scrum development process. We take advantage out of the observation that many people do not like to create documentation but they do like to share what they did. We used the tool in industrial practice and observed an improvement in communication.
One of the most important challenges in large Scrum teams is inter-team coordination @cite_4 . Coordination requires communication both between teams and within a team. @cite_3 shows in a case study that handling with knowledge over a longer period of time can only be managed with extensive communication. But important events that occur during development could be relevant to others and are often not sufficiently documented or communicated @cite_2 . Software developers do not update relevant documents, do not see their benefits and wish more automatic generation of documented content @cite_5 @cite_0 . An example of such a generation is an automatic summarizer for daily scrum meetings proposed by @cite_1 . Nevertheless there is a gap in the current state of the art on how developers of agile teams stay informed when being absent. Our proposed tool tries to fill this gap.
@cite_4 @cite_1 @cite_3 @cite_0 @cite_2 @cite_5
2100502494 5059649 1614607847 2147018965
A critical factor in work group coordination, communication has been studied extensively. Yet, we are missing objective evidence of the relationship between successful coordination outcome and communication structures. Using data from IBM's Jazz™ project, we study communication structures of development teams with high coordination needs. We conceptualize coordination outcome by the result of their code integration build processes (successful or failed) and study team communication structures with social network measures. Our results indicate that developer communication plays an important role in the quality of software integrations. Although we found that no individual measure could indicate whether a build will fail or succeed, we leveraged the combination of communication structure measures into a predictive model that indicates whether an integration will fail. When used for five project teams, our predictive model yielded recall values between 55 and 75 , and precision values between 50 to 76 . Agile processes enable software development projects to react to rapid changes in the development environment. However, they are often criticized for not creating and maintaining standard documentation such as requirements and design documentation. The lack of documentation can be detrimental for maintaining knowledge, especially in the long run, because there is no explicit medium for communication to new people and among existing developers. This poses an important question: whether the use of agile processes in long run is feasible. In this paper, we presented a field study of an organization that has been using an agile process for more than 20 years and has been successful in maintaining knowledge over that period. Instead of written documentation, they use living documents, well-connected communication, and working software are prioritized as mediums for maintaining knowledge. However, success is not easily achieved. There are important factors that enable the organization to use the current practices successfully. These factors are: shared values, overlapping knowledge among team members, low turnover rate, and well-understood requirements. Ward Cunningham in his experience report presented at the OOPSLA'92 conference introduced the metaphor of technical debt. This metaphor is related to immature, incomplete or inadequate artifacts in the software development cycle that cause higher costs and lower quality. A strategy for the technical debt management is still a challenge because its definition is not yet part of the software development process. Carolyn Seaman and Yuepu Guo proposed a technical debt management framework based on three stages. First, debts are identified and listed. After that, debts are measured by their payment efforts and then debts are selected to be considered in the software development cycle. This study evaluates the application of this framework in the real context of software projects adopting Scrum. Action research is conducted in two companies where their projects have significant technical debt. We performed three action research cycles based on the three stages of the framework for both companies. The main contribution of this paper is to provide real experiences and improvements for projects using Scrum and that may adopt the technical debt management framework proposed by Seaman and Guo. Both teams recognized that the proposed approach is feasible for being considered in the software development process after some modifications. Because of projects time constraints and ease of use, we reduced the use of the proposed metrics to two: Principal and the Current Amount of Interest. In consequence, decision-making was benefitted by the early consideration of the debts that really need to be paid. Instead of using probabilities to find the interest, these are registered every time the technical debt occurs. During the first phase, the debts identification was improved when all Scrum roles participated, while measurement and decision-making were improved when the team was responsible for these phases. The Product Owner role in both companies understood the importance of Technical Debt monitoring and prioritization during a development cycle. With these changes, the two teams mentioned they would remain using the resulting approach. Task dependencies drive the need to coordinate work activities. We describe a technique for using automatically generated archi-val data to compute coordination requirements, i.e., who must coordinate with whom to get the work done. Analysis of data from a large software development project revealed that coordina-tion requirements were highly volatile, and frequently extended beyond team boundaries. Congruence between coordination re-quirements and coordination activities shortened development time. Developers, particularly the most productive ones, changed their use of electronic communication media over time, achieving higher congruence. We discuss practical implications of our technique for the design of collaborative and awareness tools.