{"title":"It's more than just toys and food: leading agile development in an enterprise-class start-up","authors":"Joseph A. Blotner","doi":"10.1109/ADC.2003.1231456","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231456","url":null,"abstract":"One of the myths of agile development is that self-organizing teams do not need direction. The agile development movement focuses primarily on programmers - programmers should do X, Y and Z, and everyone else should do whatever it takes to support the programmers. A fantastic start, since programmers are the people who actually build the organization's product; however, few techniques are offered to the rest of the organization. The admonishment to managers instructing them to only provide \"toys and food\" [Beck et al., (2000)] and buffer the team from external distractions implies that leaders in an agile environment should do less work, and be less involved with the team on a day-to-day basis, than in a more traditional environment. In fact a leader in an agile group must do more than he/she would in a more traditional environment and must be even more involved in the day-to-day activities of the team. The Sabrix development discipline has strong and deeply involved management as one of its keys to success. Management best practices, when applied appropriately and discerningly, do not limit, but rather enhance, the productivity and job satisfaction of the individual members of the engineering teams. We discuss ways a manager can and should help the team be more productive, have a better understanding of their fit in the organization as a whole and develop team members by being active and involved with the team and the rest of the company.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"141 6","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132477938","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Retrofitting an acceptance test framework for clarity","authors":"R. Mugridge, E. Tempero","doi":"10.1109/ADC.2003.1231457","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231457","url":null,"abstract":"An XP customer needs to write and check acceptance tests. However, the format for defining the tests needs to be clear. Many acceptance test approaches use arcane formats which do not promote clarity for the customer, due to a conflict of interest between the complexities of automation and the needs of the customer. We discuss the evolution of acceptance tests to improve their clarity for the customer. Sat is an acceptance test system for testing socket-based servers with multiple clients. The first version used an XML file to define the tests in a test suite. Any errors detected were written to a text log. There were two problems with this first version. The XML format made it difficult to read and edit the tests. When an error was given, it was not easy to identify the place in the test where the problem occurred. Sat was altered to make use of Fit, a testing framework that uses HTML tables for defining tests and reporting any errors. We found the new version considerably easier to use. The tabular form makes it much simpler to read and alter the tests. Any errors are reported in a copy of the tables, in the place where they occur. We have also found it convenient to include information about the tests in the HTML, providing a form of \"literate testing\".","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"204 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131876118","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Maria Istela Cagnin, J. Maldonado, F. S. Germano, R. Penteado
{"title":"PARFAIT: towards a framework-based agile reengineering process","authors":"Maria Istela Cagnin, J. Maldonado, F. S. Germano, R. Penteado","doi":"10.1109/ADC.2003.1231449","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231449","url":null,"abstract":"We present a sketch of a framework-based agile reengineering process, named PARFAIT, whose objective is to provide the users with evolved versions of legacy systems, as soon as possible. The overall static structure of the rational unified process (RUP), originally developed for forward systems engineering, has been here adapted for reengineering and is used for PARFAIT documentation. Frameworks are used in the process aiming at an agile approach to support the reengineering. Frameworks allow applications to be rapidly created, more than if they are built from scratch. Agile characteristics, such as incremental approach, cooperative approach with users and customers, straightforwardness, etc. give PARFAIT the ability to support the rapid evolution of the legacy system to a new version, according to the users and customers needs. A summary of a case study and the results obtained in the reengineering are presented. This study refers to a concrete reengineering case of a real system for controlling entry and exit of electronic appliances in a repair shop.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132128666","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"YP and urban simulation: applying an agile programming methodology in a politically tempestuous domain","authors":"B. Freeman-Benson, A. Borning","doi":"10.1109/ADC.2003.1231447","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231447","url":null,"abstract":"YP is an agile programming methodology that has evolved over the past 15 years. Many of its features are common to other agile methodologies; its novel features include using a highly visible, physical software status indicator (a real traffic light), and a well-defined nested set of development cycles. It is also an exceptionally open process, with the current status of the development process visible to the customers, as well as the code and documentation. We are using YP in developing the software for UrbanSim, a sophisticated simulation system for modeling urban land use, transportation, and environmental impacts over periods of 20 or more years under alternate possible scenarios. Our purpose in developing UrbanSim is to support public deliberation and debate on such issues as building a new light rail system or freeway, or changing zoning or economic incentives, as well as on broader issues such as sustainable, livable cities, economic vitality, social equity, and environmental preservation. The domain of use is thus politically charged, with different stakeholders bringing strongly held values to the table. Our goal is to not favor particular stakeholder values in the simulation or its output, but rather to let different stakeholders evaluate the results in light of what is important to them. There are several implications of this for the development process. First, having credible, reliable code is important - and further, both the code itself and the development process that produced it should be open and inspectable, not a black box. Second, to allow us to respond quickly to different stakeholder values and concerns, a flexible agile development process is required.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129729820","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Observations on balancing discipline and agility","authors":"B. Boehm, R. Turner","doi":"10.1109/ADC.2003.1231450","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231450","url":null,"abstract":"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses. We believe this can be accomplished using a risk-based approach for structuring projects to incorporate both agile and disciplined approaches in proportion to a project's needs. We present six observations drawn from our efforts to develop such an approach. We follow those observations with some practical advice to organizations seeking to integrate agile and plan-driven methods in their development process.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"41 2","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134427752","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"XP culture: why the twelve practices both are and are not the most significant thing","authors":"Hugh Robinson, H. Sharp","doi":"10.1109/ADC.2003.1231448","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231448","url":null,"abstract":"XP emphasises underlying values as well as the more visible twelve practices. We explore the relationship between practices and values from two perspectives: empirical and theoretical. We present empirical evidence that the twelve practices create a community in which the XP values are supported and sustained. We also present models of culture from other domains which suggest that an alternative set of practices can produce a community with the same underlying values. We conclude that the twelve practices are both significant and not significant.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"89 5","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132273316","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Agile development and remote teams: learning to love the phone","authors":"Christian Sepulveda","doi":"10.1109/ADC.2003.1231464","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231464","url":null,"abstract":"We currently work on a project where we adopted an agile process that integrates elements of extreme programming and agile modelling. Our approach is unconventional however; instead of the team being co-located, we work remotely as the lead developer. The risk of increased communication costs can be mitigated rather easily. However, trust is the most complicated element of team dynamics to establish and maintain. A virtual team must address this issue in order to succeed. Remote teams can work quite well. We have been delivering quality software in a timely manner, within the expectations of management for the last two years. We actually are more efficient and successful with a virtual team than when we were all co-located in the same room.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116664227","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Improving the interface between business and product development using agile practices and the cycles of control framework","authors":"Jari Vanhanen, Juha Itkonen, Petteri Sulonen","doi":"10.1109/ADC.2003.1231455","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231455","url":null,"abstract":"We describe how we created and adopted an agile product development process in a small software company based on the cycles of control framework by combining selected agile practices and principles from the scrum and XP methodologies. Describing the development process using the framework helped in identifying the crucial control points between business and development and enabled defining practical and well-functioning connections between them. The control points enable visibility and flexible management of product development status and direction. Currently business understands development status better, which has led to fewer interruptions between the control points, and thus improved working conditions for development. Positive experiences are reported of newly adopted practices such as scrum meetings, pair programming, and unit testing. However, finding and adopting technical tools to facilitate the process proved to be challenging.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133416499","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Test driven development and the scientific method","authors":"R. Mugridge","doi":"10.1109/ADC.2003.1231452","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231452","url":null,"abstract":"The scientific method serves as a good metaphor for several practices in extreme programming (XP). We explore the commonalities and differences and show that the scientific method, by analogy, can be used to better understand test driven development (and vice versa).","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131129928","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"An agile request for proposal (RFP) process","authors":"J. Andrea","doi":"10.1109/ADC.2003.1231466","DOIUrl":"https://doi.org/10.1109/ADC.2003.1231466","url":null,"abstract":"The request for proposal (RFP) process can be agile and efficient. At a high level, the key to achieving this is to specify requirements just in time and containing just enough detail. We apply the following XP practices and concepts to the RFP process: acceptance tests, business value, iterative and incremental delivery, on-site customer, pair development, planning game, spike, story, velocity, and yesterday's weather. In addition, the following concepts are combined with those from XP to achieve maximal benefit: user-goal use case, context diagram, level of detail, and decision tree. The contributions to the agile community are two-fold: describing a practical application of XP concepts to a nonprogramming project; and making use case style requirements processes more agile.","PeriodicalId":325418,"journal":{"name":"Proceedings of the Agile Development Conference, 2003. ADC 2003","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-06-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116475946","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}