 |
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
 |
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
 |
|||||||||||
|
|||||||||||
 |
|
|
 |
|
Experience reports contain first-hand information and reflection: "We saw this, did that, and consider this-and-that about our experiences." If you are interested in adding to your research data or are a practitioner looking to avoid problems and focus on success, these presentations will provide valuable knowledge gained through hands-on experience. Each report will create a portal through which attendees can glimpse what works, what doesn’t and why in employing agile methods in projects. Specialists in computer engineering, business analysis, programming, sociology and management as well as other essential disciplines will round out the list of presenters. Scheduled Experience Reports
Experience Report Abstracts Thursday morning, June 24 XP "Anti-Practices" : anti-patterns for XP practices When you introduce XP to your project, the team gets fresh enegy and high efficiency. However, sustaining the good condition becomes difficult when you are attacked by its side effects. We call these XP side effects "Anti-Practices", just as well as we name "Anti-Patterns" for Patterns. "Turning all the knobs up to 10" is the XP way, but Anti-Practices show bad symptoms of the overdrive. (There is a proverb "more than enough is too much" in Japan.) In this experience report, we identify Anti-Practices discovered from our projects with prescriptions to the symptoms so that XPers can share the counter plans. Refactoring the Development Process: Experiences with the Incremental Adoption of Agile Practices The goal of many current process improvement efforts is to become more agile by adopting an agile process. However, the results of several recent projects suggest that when attempting to become more agile, adopting an agile process is exactly the wrong thing to do! In this experience report, we discuss our failures with wholesale process adoption and our successes using an incremental adoption strategy based on metric- and retrospection-driven feedback. Similar to refactoring practices for design and code, this strategy identifies “process smells,” and targets the worst of them with specific agile practices drawn from several popular agile processes. Subclassing XP: Breaking its rules the right way XP says that all of its practices are mandatory. Fine, subclass XP and create a new methodology. For each XP practice you remove you need a compensating one. We removed pair programming and replaced it with pairing. A pair has an author and a second. Design must be paired, but only by the completion of the story. Formal pair programming can ensue at the option of the author or the second. We also replaced individual or pair refactoring with group-controlled refactoring. A refactor list is maintained and prioritised by the group and worked on towards the end of the iteration.
Thursday afternoon, June 24 Learning Effective XP: Successes and Failures Agile processes such as XP (eXtreme Programming) have been recognised for their potential benefits of greatly improving software vis-à-vis fewer bugs, early delivery of valuable functionality, closer client/programmer interaction and a lower cost/change curve. As with any process, factors such as experience, time pressures and project scale influence its success or failure. In this paper, we describe the experiences of five different teams that adopted XP in small projects. Project teams were made up of four or five programmers, who were from various backgrounds, with varying levels of experience. The experiments were conducted as part of a postgraduate degree course in a university. Each team had differing levels of success. In determining the dominant features of both the successful and unsuccessful projects, we observed that many of the XP principles can be applied in a way that detrimentally affects the project. This paper discusses the learning curve associated with the XP process and how inexperienced teams can misinterpret the guidelines. We argue that this is due to the fact that teams do not appreciate the underlying ethos upon which these principles are based. This paper presents experiences that show how a naïve application of the XP guidelines can greatly affect the success of a project. Emergent Database Design: Liberating Database Development with Agile Practices Many agile projects do not apply agile practices to their database development. Common wisdom dictates that the entire data model be carefully designed up front and protected from change thereafter. We believed the common wisdom as well. But the clash of traditional database practices and agile development practices caused us significant pain, and hamstrung our ability to deliver the most business value in each iteration. Once we recognized this pain, we abandoned the conventional wisdom. Incrementally, we applied agile discipline to our database development, eventually reducing up-front design work to just-in-time work that matched our 1 to 2 week development iterations. This paper summarizes our experience. Agile Methodologies Applied to Embedded Firmware Development This paper describes the experience of applying Agile approaches to the development of firmware for the Intel® Itanium® processor family. Embedded development (i.e. firmware) projects are quite different from object-oriented and pure software endeavors, yet they face many of the same challenges that Agile software development practices address. Several unique challenges are described, including team members’ specialized domain knowledge, technical backgrounds and attitudes toward change, and the impact hardware plays in firmware design. We found Agile approaches to be well-suited for our project, in spite of the fact that most Agile methodologists come from very different backgrounds.
Friday morning, June 25 Aligning Strategic Planning with Agile Development: How Companies Have Failed to Live Out the Dreams of Agile Methodologies In my experience, I have successfully used Agile Development to build quality software, but often these projects have failed to bring about company success. This failure is due to the fact that most companies’ strategic planning capabilities have not been aligned with the flexibility and adaptability of Agile Development. I believe that Agile Development alone is insufficient to make every software project successful; every project must be coupled with a complimentary strategy to achieve business goals. If Agile Development is to continue growing in the business community, current strategic planning capabilities must be developed that share the same agile philosophies. Adaptive Agility - Managing Complexity and Uncertainty Landmark Graphics has a large portfolio of software projects, with over 60 commercial products consisting of over 50 million lines of code. We sought to improve our software development process and looked to agile methods as natural extension of our current processes. As we examined our past projects we realized that an overall process to suit all projects would need to be adaptable based on the project conditions. This led us to look at some of the ideas of Cockburn in Crystal methods, and later to the work of Boehm and Turner. Upon reviewing our projects, we realized that we could categorize them into a four quadrant matrix with the axes of Complexity and Uncertainty, where Complexity included such issues as team size and criticality, and Uncertainty included both market and technical uncertainty. As is tradition, we used animal names to represent the four quadrants: Dogs – Small projects with low uncertainty All projects might have core processes that they adopt, but many process activities should be adapted based on the elements of Complexity and Uncertainty. It was comforting to uncover that most of our project teams had already naturally taken on this emergent behavior. The Slackers Guide To Project Tracking As a project manager, your time is far too important to be wasted on mundane tasks like detailed tracking of the day-to-day activities of each of your developers. Wouldn't it be nice if you spent your time negotiating project scope and identifying and removing team impediments? Our experience has shown that consistency in card sizes and estimates allows you to perform full project planning with little effort. Additionally, it results in diagrams that accurately reflect your project's status. With this, accurate release planning sessions take hours not days, freeing up valuable time for both you and your developers.
Saturday morning, June 26 DecisionSpace Infrastructure: Agile Development in a Large, Distributed Team This report takes lessons and experiences from the first two years of the DecisionSpace Infrastructure project. This covers the period from first inception to relative process stability. Reasons for Interest
Lessons Learned
While the DecisionSpace Infrastructure did not use a pure agile methodology, it managed to adopt several agile approaches, and used them to enable flexibility, and to deliver more successfully than it would have by making use of a heavy process methodology. The Development Game Three years ago we started a new project at our company. Undermanned, short on time, and under the gun to succeed, we started with 12 developers made up of existing domain experts and new technology experts. Management decided that the new project was the perfect time to implement some much needed process and, after investigating several published processes began implementing practices deemed important to success. I was on both the management and development teams. The developers resisted the idea of new processes and practices for weeks, with quiet grumbling and out-and-out defiance. To move forward, we created a "game" that involved developers in the process, rewarding approved practices and mildly disciplining non-compliance. Management spotted us $1,400 in prize money, which we used to buy techno-gadgets that would serve as rewards at the end of the iteration. The game worked, and we developed a competitive and fun environment that improved morale, increased compliance, and caused the developers to become more involved in how the process itself worked. This paper describes the game and our experiences in playing it on several occasions. A Study Case: Evolution of Co-location and Planning Strategy Agile practices can and should be evolved throughout a project. This paper focuses on the evolution of two agile practices, namely co-location and planning strategy, in a software development project at TransCanada. From inception to conclusion, the evolution contributes to the successful delivery of an in-house developed system and leads to change in organizational culture.
Friday morning, June 25 Taming the Embedded Tiger The challenge: An embedded application for a new product design; Brand new CPU with its design not even finalized; Must integrate with software being developed by a partner company. Add to that a schedule already shortened by delay in staffing. Next, add a team with half of its members inexperienced in embedded or real-time software. Sound like a recipe for disaster? We discovered that even inexperienced team members could contribute productively if there were test methods tailored for agile embedded software development, and real teamwork. Embedded systems are notoriously hard to troubleshoot. Test practices we describe in this paper made troubleshooting so easy that our bug list never had more than 2 entries throughout the whole project. Don't Mock Me: Design Considerations for Mock Objects Mock objects, an object-oriented testing construct used predominantly in test-driven development, are often abused, leading to inflexible and defective systems. Developers abuse mocks because they don't fully understand the driving forces for when to use and not use them; they also don't fully understand the implications of their improper use. Mocks inherently introduce design concessions in code. This experience report discusses when to use mocks, presents design categories that most mock implementations fall into, and discusses the considerations for each design category.
Reviewer Committee
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
