Section 3.5. Preparing for Changes That Affect External Entities


3.5. Preparing for Changes That Affect External Entities

Although iterations within the development cycle can be internal to the development organization, connecting to the customer at this level requires external changes as well. In the long term, the way you communicate with upper management, quality assurance, and even human resources will change. Although those changes may take time, laying the groundwork now is important.

It is likely that the first externally visible change will be in the structure of the plans and status information that you share with management. You will no longer produce a detailed PERT chart showing the development of components and their integration. In fact, you won't want to show a long-term plan at all. This isn't going to be well received without some preparation! The best strategy for exposing this change is to give the new types of information in parallel with the old types. For example, if you have been responsible for producing a plan that included milestones and deliverables for the entire project, continue to do that (with possibly less attention to detail). In addition, report on the features planned for the current iteration or, better yet, those completed in the last iteration. After a few iterations, management will be much more interested in those feature lists (and priorities) than with the updated PERT chart. Soon the PERT chart will become unnecessary.

As these changes become more visible, people outside of the team will become interested in understanding the new agile process. Try to share information as much as possible. If you have a stand-up meeting in the morning or you run information/training sessions for your team, invite others to observe. You should open your planning sessions for observers and share your feature development status with anyone who is interested. The goal is to be as open as possible about this change. You need to advocate for agility by making sure that people understand the motivation behind time-boxed iterations and the goals that you have for making the change.

This change will seem very foreign to many people. Most people have been trained in the motivations behind plan-driven methods and why those methods should be superior to ad hoc development. There is a risk that people will think you have thrown away your process and are just hacking code. Part of the motivation for going to time-boxed iterations during the development phase is that you still have the results of requirements analysis and design. This should reduce the appearance that you are hacking code.

Wherever possible, demonstrate the discipline your team is using and the benefits this change causes. You can do this by showing deliverables that meet standards (design documents, code, etc.), by tracking metrics like code complexity and defect rates, and by demonstrating the robustness of the delivered functionality.




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