Buzzword Deathmatch: Agile vs SOA


Published on

Slides from the Skills Matter in-the-brain-of session of September 2nd 2008

Published in: Technology, Business
  • Slide 13 stating '.. project management' seems to contradict: 'Scrum is a framework for developing and sustaining complex products'. You have a view on that?
    Are you sure you want to  Yes  No
    Your message goes here
  • This presentation is realy interesting, could you send it to me please at


    Are you sure you want to  Yes  No
    Your message goes here
  • can i have your presentation please ..
    Are you sure you want to  Yes  No
    Your message goes here
  • Great subject with great content
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Buzzword Deathmatch: Agile vs SOA

    1. Buzzword Deathmatch: Agile vs SOA formerly “ Agile Development with SOA”
    2. About me <ul><li>10 years experience in IT, mainly as a consultant </li></ul><ul><li>Took part in many large scale projects </li></ul><ul><ul><li>Government(s) </li></ul></ul><ul><ul><li>Banking </li></ul></ul><ul><ul><li>Insurances </li></ul></ul><ul><li>A foot in the process, the other one in the architecture. </li></ul><ul><li>My blog: </li></ul>
    3. Agenda <ul><li>Starting from the dinosaurs… </li></ul><ul><ul><li>The Agile Landscape </li></ul></ul><ul><ul><li>The SOA Landscape </li></ul></ul>
    4. The Agile Rationale <ul><li>Waterfall software development proved itself inefficient and unsatisfactory </li></ul><ul><ul><li>Waterfall is “traditionally” associated with </li></ul></ul><ul><ul><ul><li>high cost, </li></ul></ul></ul><ul><ul><ul><li>long development time </li></ul></ul></ul><ul><ul><ul><li>Result unpredictability and low success ratio </li></ul></ul></ul><ul><ul><ul><li>Difficulties in managing and accommodating change </li></ul></ul></ul><ul><li>If asked, nobody is doing waterfall anymore (…or so they think) </li></ul>
    5. Unified Process <ul><li>The unified process changed the scenario </li></ul><ul><ul><li>Iterations as a fundamental part of the process </li></ul></ul><ul><ul><li>Fine grained roles and artefact definition </li></ul></ul><ul><ul><li>UML as the official representation language </li></ul></ul><ul><ul><li>A comprehensive definition of all development process activities </li></ul></ul><ul><li>Unfortunately, it also set the ground for </li></ul><ul><ul><li>A family of UML modelling tools </li></ul></ul><ul><ul><li>A lot of documentation templates </li></ul></ul>
    6. The Dark side of Unified Process <ul><li>The tools became more and more important, ultimately twisting the process </li></ul><ul><li>Analysis and design turned into solo activities </li></ul><ul><li>Paper, paper, paper, and more paper </li></ul>
    7. Developers <ul><li>Developers were considered “interchangeable resources” whose only goal was to implement the specification, though iteratively . </li></ul>
    8. Roles and responsibilities <ul><li>The fine grained roles framework eventually turned into a slow down factor: </li></ul><ul><ul><li>People took over only “the right tasks” </li></ul></ul><ul><ul><li>(implicit waterfall) </li></ul></ul><ul><ul><li>Slower response </li></ul></ul><ul><ul><li>Bottlenecks </li></ul></ul><ul><ul><li>Blame game </li></ul></ul><ul><ul><li>... </li></ul></ul>
    9. Rebel forces gathered
    10. The three flavours of Agility <ul><li>XP made a breakthrough focusing on extreme software development practices </li></ul><ul><li>Scrum defined a framework in which Agile practices could be applied within an organization </li></ul><ul><li>Lean software development introduced concepts and principles from the manufacturing industry into software development (defining also a theoretical background) </li></ul>
    11. eXtreme Programming <ul><li>User Stories </li></ul><ul><ul><ul><ul><li>Less formal than Use cases, act like placeholder for a real discussion </li></ul></ul></ul></ul><ul><li>Frequent small releases </li></ul><ul><ul><ul><ul><li>Iterations are shorter and targeted to production, </li></ul></ul></ul></ul><ul><li>Frequent planning and estimation </li></ul><ul><ul><ul><ul><li>Each iteration is re-planned according to the currently available information </li></ul></ul></ul></ul><ul><li>No anticipated development </li></ul><ul><ul><ul><ul><li>No frameworks or layered architecture </li></ul></ul></ul></ul><ul><li>Test first </li></ul><ul><ul><ul><ul><li>Test suites run preserving application integrity, and producing better interfaces </li></ul></ul></ul></ul><ul><li>Customer availability </li></ul><ul><ul><ul><ul><li>Real feedback is the key to make the right thing </li></ul></ul></ul></ul><ul><li>No code ownership </li></ul><ul><li>Continuous integration </li></ul><ul><ul><ul><ul><li>The whole system is frequently integrated and tested </li></ul></ul></ul></ul><ul><li>Pair programming </li></ul><ul><ul><ul><ul><li>Programmers work in pairs, in coding sessions </li></ul></ul></ul></ul><ul><li>No overtime </li></ul><ul><li>... </li></ul>
    12. XP <ul><li>Feedback seems to be the driving factor for many of the proposed practices </li></ul><ul><ul><li>From the code </li></ul></ul><ul><ul><li>From peers </li></ul></ul><ul><ul><li>From the customer </li></ul></ul><ul><ul><li>From the project </li></ul></ul><ul><ul><li>From the team </li></ul></ul><ul><li>The team is largely empowered and encouraged to propose original solutions </li></ul><ul><li>Process itself might be modified or improved </li></ul>
    13. Scrum <ul><li>Scrum does not refer strictly to software development, but provides a framework for adaptive project management </li></ul><ul><li>Unlike UP, only 3 roles are defined in Scrum </li></ul><ul><ul><li>The Team </li></ul></ul><ul><ul><li>The Product Owner </li></ul></ul><ul><ul><li>The Scrum Master </li></ul></ul>
    14. Development team landscape
    15. The agile team <ul><li>Small units </li></ul><ul><li>Cross-functional </li></ul><ul><li>The team is free to take any design decision </li></ul><ul><li>In Scrum, the team reports only to the product owner </li></ul><ul><ul><li>A well defined ceremony and set of actions to prevent the team to drift in dangerous directions </li></ul></ul>
    16. Dealing with several stakeholders <ul><li>The Product Owner is the ONE and ONLY responsible for the development team. </li></ul>
    17. XP vs Scrum <ul><li>XP </li></ul><ul><li>Frequent iterations of working software </li></ul><ul><li>Frequent status update and re-planning </li></ul><ul><li>Focus on the development team internal organization and practices </li></ul><ul><li>Scrum </li></ul><ul><li>Frequent iterations of working software </li></ul><ul><li>Frequent status update and re-planning </li></ul><ul><li>Focus on the relations between the development team and the organization </li></ul>
    18. XP and Scrum <ul><li>The two perspectives are largely complementary: </li></ul><ul><ul><li>XP does not say much about what happens outside of the development team </li></ul></ul><ul><ul><li>Scrum lets the team free to organize, and XP might be a sensible choice </li></ul></ul><ul><li>Scrum has definitely a better marketing </li></ul>
    19. Lean software development principles <ul><li>Eliminate waste </li></ul><ul><ul><ul><ul><li>Everything that is not delivering any value to the user </li></ul></ul></ul></ul><ul><li>Amplify learning </li></ul><ul><ul><ul><ul><li>Developing is discovery, </li></ul></ul></ul></ul><ul><li>Decide as late as possible </li></ul><ul><ul><ul><ul><li>Avoid irreversible decisions or take them only when you have as much information as needed to decide </li></ul></ul></ul></ul><ul><li>Deliver as fast as possible </li></ul><ul><ul><ul><ul><li>Fast development cycles help feedback. Speed is better than quality </li></ul></ul></ul></ul><ul><li>Empower the team </li></ul><ul><ul><ul><ul><li>The team is or will become the maximum expert on the matter </li></ul></ul></ul></ul><ul><li>Build integrity in </li></ul><ul><ul><ul><ul><li>Software must be useful, used and right for the job </li></ul></ul></ul></ul><ul><li>See the whole </li></ul><ul><ul><ul><ul><li>Failing to see the whole picture will lead to local optimizations </li></ul></ul></ul></ul>
    20. Waste <ul><li>Instances of waste that can show up in different shapes </li></ul><ul><ul><li>Unnecessary documentation </li></ul></ul><ul><ul><li>Anticipated design </li></ul></ul><ul><ul><li>Over engineering </li></ul></ul><ul><ul><li>Waiting </li></ul></ul><ul><ul><li>Communication leaks </li></ul></ul><ul><ul><li>Defects </li></ul></ul><ul><ul><li>Handoff </li></ul></ul><ul><ul><li>Complexity </li></ul></ul><ul><ul><li>Blame </li></ul></ul><ul><ul><li>Quality (?) </li></ul></ul><ul><ul><li>... </li></ul></ul>
    21. The lo-fi approach <ul><li>As a consequence, some tools were deprecated, favouring a non-tech approach: </li></ul><ul><ul><li>Paper </li></ul></ul><ul><ul><li>Post-it </li></ul></ul><ul><ul><li>Whiteboards </li></ul></ul><ul><li>Information radiators took advantage of physical proximity to allow a more efficient exchange of meaningful information (where possible) </li></ul><ul><li>Some tools were basically banned (es. MSProject), others entered the show (es. Wikis) </li></ul>
    22. The bottom-up revolution <ul><li>Agile sets the ground for interesting proposal to emerge from the team </li></ul><ul><li>The team learns and focuses on a given problem space eventually turning into the best available expert on the matter </li></ul>
    23. Breeding collaboration <ul><li>Isolation happens seldom </li></ul><ul><li>Many activities are performed in groups, or pairing, or in a clearly visible way </li></ul><ul><li>Transparency enables trust and a more effective form of collaboration </li></ul><ul><li>Information exchange happens in both ways </li></ul>
    24. The Ideal Agile scenario <ul><li>Not every condition is optimal to turn to agile: to fully benefit of agile’s potential we should (ideally) </li></ul><ul><ul><li>Be employed by a company in whose top priority is software development. </li></ul></ul><ul><ul><li>Be located in the same place </li></ul></ul><ul><ul><li>Have access to customers (whatever this means) </li></ul></ul><ul><ul><li>Be free to grow as a team and assume responsibilities </li></ul></ul><ul><ul><li>Free to arrange logistics, hardware, etc. </li></ul></ul>
    25. Agenda <ul><li>Setting the Background </li></ul><ul><ul><li>The Agile Landscape </li></ul></ul><ul><ul><li>The SOA Landscape </li></ul></ul>
    26. SOA Rationale <ul><li>Large organizations were burdened with the weight of </li></ul><ul><ul><li>Different legacy systems </li></ul></ul><ul><ul><li>Mergers and acquisitions </li></ul></ul><ul><ul><ul><li>Necessity to integrate heterogeneous systems </li></ul></ul></ul><ul><ul><ul><li>Duplicate and redundant systems </li></ul></ul></ul><ul><ul><li>High (unnecessary) complexity </li></ul></ul><ul><ul><ul><li>Operation costs </li></ul></ul></ul><ul><ul><ul><li>Evolution costs </li></ul></ul></ul><ul><ul><li>Extremely slow reaction times, or ...basically being stuck, or failing to deliver value </li></ul></ul><ul><li>...Does all this sound familiar? </li></ul>
    27. Pursuing uniformity <ul><li>Standards, frameworks, rules and tight integration failed to deliver the needed business agility, resulting in a heavier burden to take into account, before even designing a possible solution to a given problem. </li></ul>
    28. Service Oriented Architecture <ul><li>SOA aims to dramatically reduce coupling between applications in a given landscape: </li></ul><ul><ul><li>Language coupling  XML </li></ul></ul><ul><ul><li>Protocol coupling  WS, SOAP </li></ul></ul><ul><ul><li>Network coupling  ESB </li></ul></ul><ul><ul><li>Availability coupling  messages </li></ul></ul><ul><li>Standards and low coupling defined an enterprise-level architecture made up of replaceable components </li></ul>
    29. Low coupling <ul><li>Services are meant to talk to each other, with the lowest possible reciprocal knowledge </li></ul>Enterprise Service Bus
    30. The ideal goal <ul><li>SOA was a tool to </li></ul><ul><ul><li>Allow the long awaited necessary cleanup </li></ul></ul><ul><ul><li>Allow IT to become a driving factor for the business instead of a burden </li></ul></ul><ul><ul><ul><ul><li>“ It’s a mess” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ I’ll schedule it for 2010” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ We have no time right now” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ We can do that” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ Why not doing that instead?” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ ...We have an idea” </li></ul></ul></ul></ul><ul><ul><li>Allow enterprises to reduce vendor lock-in recovering control on IT budget. </li></ul></ul>
    31. Put in another way <ul><li>SOA is a tool to allow large enterprises to achieve business agility </li></ul><ul><ul><li>Shorter products release cycles </li></ul></ul><ul><ul><li>Getting feedback straight from the market </li></ul></ul><ul><ul><li>Experimenting new ways to make business </li></ul></ul><ul><li>SOA is not a way to recreate an existing structure with a newer technology </li></ul>
    32. The “classical” SOA scenario <ul><li>The agile greenfield </li></ul><ul><li>Be employed by a company in whose top priority is software development. </li></ul><ul><li>Be located in the same place </li></ul><ul><li>Have access to customers (whatever this means) </li></ul><ul><li>Be free to grow as a team and assume responsibilities </li></ul><ul><li>Free to arrange logistics, hardware, etc. </li></ul><ul><li>The “classical” SOA </li></ul><ul><li>Company’s top priority is generally not software development </li></ul><ul><li>Consultants, contractors (and sub-contractors) are the rule </li></ul><ul><li>Development takes often place in multiple locations , remote and offshore teams are possible. </li></ul><ul><li>Smaller incentives to grow and assume responsibilities </li></ul><ul><li>Low control over logistics, hardware, etc. </li></ul>
    33. Unleashing freedom <ul><li>Loose coupling and language neutral standards offered the possibility to develop applications in the most appropriate technology </li></ul>Enterprise Service Bus
    34. ... Maybe we’re still coupled...? <ul><li>Technical coupling was only one of the many coupling factor on the stage: </li></ul><ul><ul><li>Licence budget </li></ul></ul><ul><ul><li>Operations & Support </li></ul></ul><ul><ul><li>Standards, Rules and existing prescriptions </li></ul></ul><ul><ul><li>HR strategies </li></ul></ul><ul><ul><li>Architecture </li></ul></ul><ul><ul><li>Corporate culture </li></ul></ul>
    35. A new Jargon <ul><li>UML was not enough for SOA needs </li></ul><ul><li>A new Jargon eventually emerged as well as new notations, new diagrams, new stencils, new layers ... </li></ul>
    36. Agenda <ul><li>Setting the Background </li></ul><ul><ul><li>The Agile Landscape </li></ul></ul><ul><ul><li>The SOA Landscape </li></ul></ul><ul><li>Putting things together </li></ul>
    37. Pairing Agile and SOA <ul><li>“ Enterprises experience more success with SOA when they eschew big top-down delivery projects and instead get down in the trenches with an evolutionary approach. Agile processes provide a basic structure for this kind of incremental delivery.”  </li></ul><ul><li>Carey Schwaber, Forrester Research </li></ul><ul><li>Interestingly, not so many articles tell how Agility benefits from SOA. </li></ul>
    38. Agile as a Cooperative Game <ul><li>Software development might be classified as a finite, goal-directed, cooperative game (Cockburn) </li></ul>Carpet wrestling Jazz Tennis Software Development Dolls Competitive Cooperative Organization Survival Career management Finite, Non-goal-directed Finite, goal-directed Infinite
    39. Software development as a Game <ul><li>Finite: a project starts and ends (somehow) </li></ul><ul><li>Goal directed: es. deliver on time </li></ul><ul><li>Collaborative : we’re playing together within a team </li></ul><ul><li>… but we’re not only doing that: </li></ul><ul><ul><li>We’re playing career game </li></ul></ul><ul><ul><li>Playing family game </li></ul></ul><ul><ul><li>Etc. etc. </li></ul></ul>
    40. A successful team
    41. Some key issues <ul><li>The Team </li></ul><ul><ul><li>Best of breed selection </li></ul></ul><ul><ul><li>Team goals before individual ones </li></ul></ul><ul><ul><li>High motivation </li></ul></ul><ul><li>The goal </li></ul><ul><ul><li>Clearly defined goal </li></ul></ul><ul><ul><li>Time-framed experience </li></ul></ul><ul><ul><li>Measurable outcome </li></ul></ul>
    42. A “not so successful” team
    43. Key issues <ul><li>The team </li></ul><ul><ul><li>Best of breed? </li></ul></ul><ul><ul><li>Individual goals before common goals </li></ul></ul><ul><li>The Goal </li></ul><ul><ul><li>Not so clearly defined </li></ul></ul><ul><ul><li>Random time-frame </li></ul></ul><ul><ul><li>Non measurable outcome (only history will tell) </li></ul></ul>
    44. Limited resources game <ul><li>A Software Development scenario is bounded on several key areas: </li></ul><ul><ul><li>Budget </li></ul></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Expertise </li></ul></ul><ul><ul><li>Talent </li></ul></ul><ul><ul><li>Manageable Information </li></ul></ul>
    45. SOA game? <ul><li>SOA is generally a different type of game played at a different level: </li></ul><ul><ul><li>SOA’s goal might be of a longer term strategy </li></ul></ul><ul><ul><li>Mid term results might not be easily observable and measurable by the team. </li></ul></ul><ul><ul><ul><li>Es. Budget </li></ul></ul></ul><ul><ul><ul><li>Suppression of an external system </li></ul></ul></ul>
    46. The SOA Game <ul><li>A common critic to Agile methods is that they focus on a short-term strategy, in a given project scope. </li></ul>SOA aims to see “the whole picture” focusing on somewhat obscure long-term goals
    47. The dominant culture <ul><li>Enterprise culture might be far from agility </li></ul><ul><li>SOA might have management’s sponsorship but agile might not. </li></ul><ul><li>Careers, roles and specialities might be put under pressure </li></ul>
    48. Project Size <ul><li>SOA scope calls for many development teams at a time. </li></ul>
    49. A more realistic scenario
    50. Team’s reward <ul><li>Individual bonuses might be counterproductive or out of control </li></ul><ul><ul><li>Consultants and contractors might not be reached </li></ul></ul><ul><li>We’ve got to work on something else </li></ul><ul><ul><li>Increase the team’s knowledge </li></ul></ul><ul><ul><li>Improve working conditions </li></ul></ul><ul><ul><li>Bring (honest) positive feedback </li></ul></ul><ul><ul><li>... </li></ul></ul>
    51. Top – Down reprise <ul><li>Some tools and artifacts re-introduce a top-down philosophy </li></ul><ul><ul><li>Role based game </li></ul></ul><ul><ul><li>Tool driven design </li></ul></ul><ul><ul><li>Specification based development </li></ul></ul><ul><li>Another vicious effect is that ... </li></ul><ul><ul><li>Bottom up feedback is discouraged </li></ul></ul><ul><ul><li>Possible good ideas get lost </li></ul></ul>
    52. Starting Agile and SOA? <ul><li>Though “orthogonal”, two revolutions at the same time are probably too much for any team </li></ul><ul><li>But ...agile performs well where a lot of explorations and uncertainty is involved: </li></ul><ul><ul><li>Adaptive process </li></ul></ul><ul><ul><li>spikes </li></ul></ul><ul><li>For a good Agile team SOA is “Just another Technical Hassle” </li></ul>
    53. Read the scenario <ul><li>Different roles within the organization read buzzwords differently: </li></ul><ul><ul><li>Team might value agility more </li></ul></ul><ul><ul><ul><li>(and blame SOA if something goes wrong) </li></ul></ul></ul><ul><ul><li>Architects might value SOA more </li></ul></ul><ul><ul><ul><li>(and blame agility if something goes wrong) </li></ul></ul></ul><ul><ul><li>Management couldn’t care less </li></ul></ul><ul><ul><ul><li>And value only results </li></ul></ul></ul>
    54. Set up the scene <ul><li>Don’t raise expectations you cannot fulfil </li></ul><ul><li>Keep management aware of potential emerging problems </li></ul><ul><ul><li>Transitions to agile practices (especially Scrum and lean) stress the organization, exposing problems that lived long “under the carpet”. </li></ul></ul><ul><ul><li>Problems have always being there, but pointing them out might result impolite . </li></ul></ul>
    55. Choose a close target first <ul><li>Can’t wait months to prove that choices were good. </li></ul><ul><ul><li>Look to close targets </li></ul></ul><ul><ul><li>Achieve them </li></ul></ul><ul><ul><li>Build on this </li></ul></ul><ul><ul><ul><li>Confidence </li></ul></ul></ul><ul><ul><ul><li>Team jellying </li></ul></ul></ul><ul><ul><ul><li>Reputation </li></ul></ul></ul>
    56. Travel light <ul><li>Availability of tools to manage SOA-related complexity does not mean that complexity has to be encouraged </li></ul><ul><li>The dark side of SOA would not be better than it was before </li></ul>
    57. Adhere to standards <ul><li>As a corollary to “ Decide as late as possible ”: </li></ul><ul><ul><li>Develop on standards whenever possible </li></ul></ul><ul><ul><ul><li>Generally better documentation </li></ul></ul></ul><ul><ul><ul><li>More easily replaceable </li></ul></ul></ul><ul><ul><ul><li>... Think long term </li></ul></ul></ul><ul><ul><li>Avoid temptations from vendor-specific features </li></ul></ul><ul><ul><li>Keep deviation from standards under control </li></ul></ul><ul><ul><li>Don’t buy anything until proves necessary. </li></ul></ul>
    58. Rethink waste <ul><li>Some obvious form of waste “doing the same thing twice” might be preferable to “document what you’ve been doing” </li></ul><ul><li>Large scale changes priority </li></ul><ul><li>Company and location boundaries impact </li></ul><ul><ul><li>Communication cost </li></ul></ul><ul><ul><li>Handoff cost </li></ul></ul>
    59. The cost of communication <ul><li>Information does not propagate with documentation, but by knowing what others are doing. </li></ul><ul><ul><li>Keep multiple teams in sync </li></ul></ul><ul><ul><ul><li>Scrum of Scrums </li></ul></ul></ul><ul><ul><ul><li>Information radiators </li></ul></ul></ul><ul><ul><ul><li>Proximity </li></ul></ul></ul><ul><ul><ul><li>End of iteration demo </li></ul></ul></ul><ul><li>When written words are better, favour Wikis and on-demand documentation. </li></ul>
    60. Share the big plan <ul><li>Preventing developers to see the whole picture severely harms the possibility of a bottom-up contribution </li></ul><ul><ul><li>Only local optimizations are possible  </li></ul></ul>
    61. High level planning <ul><li>SOA is a long term transformation process </li></ul><ul><li>Every step changes the scenario </li></ul><ul><ul><li>More knowledge </li></ul></ul><ul><ul><li>Different weight </li></ul></ul><ul><ul><li>Different opportunities </li></ul></ul><ul><li>Frequent high-level re-planning is necessary to achieve the goals (not necessarily the original ones) </li></ul><ul><ul><li>Measure , don’t expect </li></ul></ul><ul><ul><li>Assess risks , don’t make predictions </li></ul></ul><ul><ul><li>Don’t initiate anything that’s not needed now </li></ul></ul>
    62. Testing a SOA <ul><li>SOA overall design is based on Design by Contract principles </li></ul><ul><ul><li>Clean interface definition based upon standards </li></ul></ul><ul><ul><li>“ Official” expected service behaviour </li></ul></ul><ul><li>Let’s test on the contract! </li></ul>
    63. Testing a SOA: challenges <ul><li>Language independent test suite  </li></ul><ul><li>Mocks and Stubs implementing services  </li></ul><ul><li>Selection of key areas  </li></ul><ul><li>Test environment management  </li></ul>
    64. Environment definition <ul><li>Staging environment might be hard to afford in certain context </li></ul><ul><ul><li>Keep continuous integration tools running and testing the app </li></ul></ul><ul><ul><li>Extend your integration capabilities as far as you can get </li></ul></ul><ul><ul><li>Find a balance between correctness and manageability </li></ul></ul><ul><ul><li>Keep the tests updated </li></ul></ul>
    65. Put in two words... <ul><li>Don’t let the “old bad habits” strike back </li></ul><ul><li>Be prepared to compromises, in the short term (it’s a limited resource game) </li></ul><ul><ul><li>Keep track the price you pay </li></ul></ul><ul><ul><li>Be ready to change them if opportunities arise </li></ul></ul><ul><ul><li>Always aim to your long term goals </li></ul></ul><ul><li>Involve the right sponsors </li></ul><ul><li>Communicate! </li></ul><ul><li>Be ready for a rollercoaster ride! </li></ul>
    66. References <ul><li>Agile Software Development – Alistair Cockburn (Addison Wesley) </li></ul><ul><li>Extreme Programming Explained – Kent Beck (Addison Wesley) </li></ul><ul><li>The Unified Software Development Process – Ivar Jacobson, Grady Booch, James Rumbaugh (Addison Wesley) </li></ul><ul><li>Agile Modeling – Scott Ambler (Wiley) </li></ul>
    67. References <ul><li>Lean Software Development: An Agile Toolkit  – Mary Poppendieck, Tom Poppendieck (Addison Wesley) </li></ul><ul><li>User Stories Applied – Mike Cohn (Addison Wesley) </li></ul><ul><li>Enterprise SOA: Service-Oriented Architecture Best Practices – Dirk Krafzig, Karl Banke, Dirk Slama (Prentice Hall) </li></ul><ul><li>Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services – Thomas Erl (Prentice Hall) </li></ul>