Software the Agile Way....

The cost of change for a traditional software project When changes to a product is introduced during the development stage because of new information or a new customer requirement, a domino effect of negative consequences followed. First, the process had to go through formal change control that was intended to ensure everyone on the team, especially those handling development and QA, understood the change and that the plan of record was kept up-to-date. This meant documentation and meetings. Second, the effort had to be estimated and, often, the schedule recast. Kent Beck, who developed Extreme Programming, asks a very thought-provoking question: if our cost curve were relatively flat (Figure 1.3) Would we behave differently?  Would we delay decisions until we had better information?  Would we over-design in anticipation of future needs or just design and build to our current requirement?  Would we be able to deliver more value to the market, Would we

DO Say  what  needs to get done. Challenge the team Get interested in building a high-performance team. Practice business-value-driven thinking. Protect the team from outside noise. Incorporate change between sprints. Don’t Say  how  to do it or  how much  it will take. Bully the team Focus on the short-term deliveries only. Stick to the original scope and approach  “no matter what.” Worry the team with changes that might happen, until they become real. Allow change to creep into sprints. Advise from  Lyssa Adkins

C ommunication - Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming. S implicity - This is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.They remain constantly focused on doing the simplest thing that could possibly work. F eedback - XP teams value feedback, and the more immediate the feedback the better. This is achieved by Pair programming, Continuous Integration,Automated Testing and from customers. C ourage - XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage).They will use a metaphor and maintain a simple design through refactoring and test driven development.