Section 1.4. Phased Transition and Refactoring to Agility


1.4. Phased Transition and Refactoring to Agility

This book is designed to help a plan-driven (or ad hoc) organization become a mature agile organization. This book does not advocate a specific agile methodology but instead provides a framework for optimizing your process by utilizing best practices from any agile (or non-agile) methodology. The transition strategy contained in the rest of the text is a surprisingly simple three-phase process. Organizations that already produce in time-boxed iterations can start optimizing at Phase 2.

Phase 1: Modify the implementation phase of development so that it is scheduled in time-boxed iterations and so that the team will produce customer-visible functionality with each iteration. Because that is the critical difference between plan-driven and agile organizations, it is a requirement that must be addressed before optimization can occur.

Phase 2: Measure the process. There are standard metrics that will lead to agility by helping you detect problems and evaluate possible changes to the process. In addition, an organization may need to hone its ability to define metrics based on its goals.

Phase 3: Refactor the process. After the procedure for delivering in time-boxed iterations is established and we begin to gather metrics reflecting our capabilities, it is likely that we will find that other parts of the process can be optimized. In addition, changes in requirements, personnel, competitors, and so on will continue to require optimization of your process.

This ongoing optimizing phase is patterned after Martin Fowler's source code refactorings but focuses on process smells[5] and process changes that address those smells. In the context of refactoring your code, a "code smell" is something that somehow looks "bad" in the code. Examples include methods that are too long, classes that are very tightly coupled, and methods with many parameters. In his revolutionary book[6], Fowler created an encyclopedia of such smells. For each smell, he gave one or more refactorings to address the underlying problem in the code. A refactoring is a mechanical manipulation of the code that does not change the external behavior but that cleans up the problem causing the smell.

[5] Elssamadisy and Schalliol[5] initially applied the concept of refactoring to the process by listing some "smells" and possible fixes from their XP experience.

Refactoring your process follows this principle: when something smells, search for the standard way to fix it. Many agile techniques have been beneficial on specific projects, but no method is a "silver bullet." These methods have used different techniques to solve similar process problems. Therefore, this text defines process smells and relates them to strategies that have been shown to work in agile (and sometimes non-agile) organizations.

Throughout this process, you're going to have to handle resistance to these changes. Auer and Miller[1] do an excellent job of identifying the types of resistance you'll probably see and strategies for dealing with that resistance. During the transition, it is especially important to pay attention to the effect that this shift in philosophy has on individual engineers. It cannot be stated too strongly that engineers in agile organizations approach development in a very different way from engineers in plan-driven organizations. Not only are there new development strategies like automated tests, source code refactoring, and test-driven development, but also engineers in agile organizations are much more involved in the overall design of the system, interactions with the customer, and planning. Finally, the focus on delivering customer-visible functionality differs from the focus on delivering architectural components. Engineers who have been successful in an organization's current environment may be threatened by the transition to agility. These concerns must be addressed for the transition to be successful.




Refactoring to Agility
Refactoring to Agility
ISBN: B000P28WK8
EAN: N/A
Year: 2006
Pages: 58

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net