There is tricky thing in Agile Methodology (inherited in Scrum) - the initial Feasibility Study. In the organisation, where I worked together with Robert Morschel before, this Study was used to gather business requirements and map them onto technical capabilities; nobody asked a question if Agile Methodology is suitable for the task in hand. Even different Technology groups that were supposed to work on different parts of the same solution (presentation layer and business middle layer) had different development models - on was time-boxed while another was more waterfall like.
Why this happened? Because one of the basic principles of Agile Methodology was violated: use Agile only if it has objectives for being applied. Even when majority of Delivery team was made remote and separated from the business, architecture, and business analysis, the team still insisted it worked in Agile... Once again, SOA concept can help here: first, you have to answer WHAT, WHY and WHO questions, and only then - HOW - Michael ________________________________ From: Gervas Douglas <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, November 6, 2008 1:38:55 PM Subject: [service-orientated-architecture] Morschel on SOA & Agility <<SOA promises business agility, so the question naturally arises whether Agile methodologies (as in XP, Scrum etc) are better suited to SOA development than more traditionaly (albeit iterative) methodologies such as RUP. If you're not familiar with Agile principles you've probably been marooned on an island somewhere. Agile is the slated answer to the software development crisis. To quote the Agile Manifesto (http://www.agileman ifesto.org/ principles. html): We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. The key principles of Agile methodologies include things like: - Customer satisfaction through rapid, continuous delivery of functional software - Working software, not documentation, is the principal measure of progress - Change is welcomed - Close, face-to-face daily cooperation between business people and developers - Projects are built around motivated individuals, who should be trusted - Continuous attention to technical excellence and good design - Continuous integration of source code changes - Simplicity - Self-organizing teams - Regular adaptation to changing circumstances - Test driven development Agile methodologies are in general suited to small teams of senior developers with rapidly changing requirements and an end user. Some work has been done to apply Agile on the larger scale but in general the larger the scale and number of interworking groups, the less agile is applicable "to the whole". The last phrase is key, because certainly there is no issue with organising service development teams in an Agile manner, however Agile as a methodology for delivering enterprise SOA is surely inappropriate? SOA is highly planned, requires a defined architectural and organisational framework in which to operate, needs lots of up front business modeling to help drive service requierments, needs formally defined and well-documented contracts, needs formal rigorous change management, and finally some measure of stability because of the cost of change to clients.>> You can read this blog at: http://soaprobe. blogspot. com/ Gervas
