1 / 31

Delivering Agile Business Process & Integration Solutions

Delivering Agile Business Process & Integration Solutions. Thursday 23 rd March 2006 Microsoft Architect Insight Conference. Dave Morris Tamer Shaaban. Introduction. What does Agile really mean? What is the real cost of integration? What is the impact of strategic BPI on an organisation?

jgray
Download Presentation

Delivering Agile Business Process & Integration Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Delivering Agile Business Process & Integration Solutions Thursday 23rd March 2006 Microsoft Architect Insight Conference Dave Morris Tamer Shaaban

  2. Introduction • What does Agile really mean? • What is the real cost of integration? • What is the impact of strategic BPI on an organisation? • How does this work in the real world? • Was there any pain along the way?

  3. What Agile is and how is it different? The integration view point

  4. What is Agile? Agile • Agile is a number of lightweight methodologies including DSDM, Extreme Programming (XP) and SCRUM • Agile methods are disciplined processes that focus on people and the way software is developed • It’s about developing software that is more aligned to business needs SCRUM • An agile process to manage and control development work • A team-based approach to iteratively, incrementally develop systems • Controls the chaos of conflicting interests and needs • Improves communications and maximises co-operation • Scrum is a way to maximise productivity

  5. Sometimes Rarely 16% 19% Never Often 45% 13% Always 7% Increase Focus on Business Value Features and Functions Used in a Typical System Often or Always Used: 20% Rarely or Never Used: 64% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

  6. Traditional Projects • Waterfall

  7. Sprint 0 User Review & Feedback Review Product Sprint 1 User Review Backlog & Define & Feedback Sprint Backlog Review Product Sprint 2 User Review Backlog & Define & Feedback Sprint Backlog Review Product Sprint 3 User Review Backlog & Define & Feedback Sprint Backlog Review Product Sprint 4 User Review Backlog & Define & Feedback Sprint Backlog Review Product Sprint 5 User Review Backlog & Define & Feedback Sprint Backlog Review Product Release Sprint Backlog & Define Sprint Backlog Month 1 Month 2 Month 3 Month 4 Month 5 Month 6 Month 7 SCRUM, Sprints, and backlogs

  8. Scrum for Team System

  9. Why is Integration different?

  10. Enterprise Scale • Integration projects typically span an entire enterprise • Intra-business, cross department • Typically at the heart of major business processes • Supply chain • Finance • Effects span many business units and trading partners • Central and distributed effect • Knock on to suppliers and customers

  11. Business Change • BPI projects typically involve a degree of business change • New business processes impact far more than just IT • Incremental change is better than a big bang • Incremental change makes organisations more agile • Incorporate feedback reviews in the following sprints

  12. Complex Team Structures • Integration projects often have multiple teams and diverse inter-team relationships • Multiple teams • Multiple suppliers • Specialist resources • Communication failure is a key risk

  13. Intangible • The cost justification model for an integration project is complex • Difficult to justify to individual business units • ROI is hard to estimate • Ownership is an issue • Both during projects and once live • Benefits are shared • But often initial risk is not shared

  14. Integration Exposes Systems • Integration exposes poor quality • Nothing in isolation • Impact of failure can be catastrophic • Nothing happening is easy • System 'pollution' can be impossible to undo • Not easy to develop services without consumers • Difficult to understand real use in isolation • Agile builds useable stack of service and consumer • Changing services with consumers • Leverage consumer contracts to minimise impact of service change

  15. How does Agile help deliver real world Integration?

  16. Deliver Business Value Early • Identify quick wins • Overcome the intangible nature of integration projects • Better alignment to business drivers Iteration1 Iteration2 Iteration3 Iteration4

  17. Deliver Business Value Early • Deliver returns quicker • Change the cost model of project delivery • Potential for 'self sustaining' integration Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 ROI £ Time Go Live

  18. Planning Can’t be Avoided • Integration is complex and needs preparation up front • First iteration is essential for planning • Need enough planning to start the first implementation iteration • Recognise this will not be comprehensive or conclusive • Leave important decisions until as late as possible • We cannot know everything up front • Waterfall approach wastes effort in pinning down unknowns that may never be needed • Continual re-factoring • Cannot start implementation without a view of the 'big picture' architecture

  19. De-risk The Project • Tackle technical issues / risks early • Don’t leave the difficult parts to the end • Iteration isn’t an excuse for cherry-picking easy bits • Tackle deployments early • Forced to deploy frequently • Urgent business change carry less risk • Engineering practices associated with Agile lifecycle • Unit testing • Continuous Integration • Automatic deployments • End To End testing

  20. Reduce Integration Complexity • Break down the project into manageable and presentable tasks • Enterprise scale of integration project can be managed • Value from specialist resources can be maximised • Ownership is clearly defined – more dynamic decision making • Avoid delivery in a single big hit • Multiple teams can work in parallel and bring together deliverables quicker • Each iteration increases knowledge – technical and domain • Incremental delivery increases quality • Business has control of objectives throughout lifecycle • Business change can be managed

  21. Keep the Business Involved • Iterative releases need constant business involvement • Feedback will affect future iterations • Cannot get future iterations right without feedback • Scale of an integration project will impact the business • They need to feel they own it • Demo to the business • Tactical interfaces • User Interface

  22. Managing Complex Team Structures • Integration typically spans organisations • Within team • Between teams • With the Business • Between 3rd Parties • Agile provides a framework for open communications • Team members have to work together to achieve the sprint goals • Can’t assume everyone will be Agile

  23. Architecture Must Evolve • Without a 'green-field' budget integration, platforms must be delivered by successive projects • Architecture issues exaggerated by iterations • Need to keep the 'Big Picture' visible • Can’t be in someone’s head

  24. S**t Happens – Things Change! • BPI projects inherently change all the time • Frequency of change is higher • Size of change is higher • More system interdependences increase scope of change • Agile embraces change as a natural part of development • Short iterations can allow proactive delivery to align to the changing business

  25. Some food for thought

  26. What is the Correct Project Setup? • Committed and Non-committed • Chicken and Pigs • Semi-committed pigs • What is the Correct Iteration Duration? • Working with external suppliers • Semi-committed pigs

  27. 'Iteration gives Fragmented Architecture' • Reactive architecture • Need to be able to change continually • Continual re-factoring? • Business dependency

  28. Can Agile be Fixed Price? • Fixed price = fixed backlog – not Agile • Yes it can be: Flex the scope • No it cannot be: Scope is decided by the business. • The Iron Triangle • If the cost is fixed how do you react to changes in scope • Quality is often sacrificed • How do we manage change? • A change request is a waterfall artefact Cost Scope Time

  29. How is a Strategic View Maintained? • Multiple projects exist so complexity is already high • Break out architecture to separate team • The Architecture Team • Treat architecture as its own product • Delivery to other teams as customers • How big and detailed does the 'Big Picture' need to be?

  30. When is Agile not Appropriate? • People need to think differently • Buy in – team and business • Team dynamics • Agile assumes that you can change it later • Not always true • Can be perceived as a waste

  31. Thank you • dave.morris@conchango.com • http://blogs.conchango.com/davemorristamer.shaaban@conchango.com • http://blogs.conchango.com/tamershaaban/

More Related