Software the Agile Way....

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.

S mall releases -  By the end of each iteration( 2 to 3 weeks long)  the team is responsible for delivering working, tested code that can immediately be put to use. The p lanning game -  Prior to the start of each iteration, the team and customer plan the iteration. This involves selecting the highest priority stories that can be completed in the iteration and then identifying the specific tasks necessary to complete the story . R efactoring -  Refactoring (Fowler 1999; Wake 2003) refers to the restructuring or rewriting  of code so as to improve the code without changing its external behavior.Refactoring is one of technique used by XP to replace upfront design. T esting -  XP puts the tests right up front in a practice called test-driven development (Beck 2003; Astels 2003). On an XP project the developers write automated unit tests and the customers write acceptance tests, which are often automated either by the customers themselves or ...

Normally enterprise architecture should take place before the project even starts.It should be part of the project start-up or mandate.  In particular the organizations application architecture and integration architecture should be done.  Its unlikely that there will be a enough information at this point for information architecture,This will need to evolve as the project progresses. As for the other enterprise level architectures, many of these will be defined and form part of a definition of done. Typically in the start-up of a project, a BA, product owner will capture epic ideas and these will be broken down into high level feature stories/requirements. Note this is not going to be detailed and ready for a team to implement, but it covers enough knowledge that an architect should be able to formulate a technical approach. This also servers as a high level release plan. A good technical/system architect should be able to look at these feature requirement and formulat...