Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Doing Architecture with Agile Teams IASA UK Summit 2013

3,255 views

Published on

Published in: Technology
  • Be the first to comment

Doing Architecture with Agile Teams IASA UK Summit 2013

  1. 1. SoftwareArchitecturewith AgileTeamsChris F. Carroll&Alan Gawthorpephoto: http://d.lib.ncsu.edu ua023_025 copyright not known
  2. 2. First, a couple of questions...
  3. 3. Agile vs ArchitectureDestined to Fight?Individuals & Interactionsover processes and toolsWorking Softwarevs comprehensive documentationCustomer Collaborationover contract negotiationResponding to Changeover following a planITABOKISO 4201040 years of experience!
  4. 4. Agile & ArchitectureCommon Priorities“Our highest priority is to satisfy the customer ...”ISO42010Systems & Software Engineering —Architecture Description
  5. 5. Architecture with Agile TeamsQuestions & Issues• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,maturity – how• Personalo How can an agile team and an architect relateeffectivelyo How do I the architect add value effectively• Technicalo Agility as a software qualityo What kind of architecture might count as agile
  6. 6. Summary of Agile
  7. 7. Achitecture with Agile TeamsQuestions & Issues• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,maturity – how• Personalo How can an agile team and an architect relateeffectivelyo How do I the architect add value effectively• Technicalo Agility as a software qualityo What kind of architecture might count as agile
  8. 8. How does Agile Scale?“Out of the box ‘core’ agile methods do not giveadequate consideration to the risksassociated with delivering solutions on largeenterprise projects and as a result wereseeing organizations investing a lot of effortcreating hybrid methodologies ...”Ambler & Lines, Disciplined Agile Delivery, 2012
  9. 9. Scaling Agile:Enterprise-level MethodologiesAgile Unified Process & Agile Modeling– Scott Ambler, 2005Open Unified Process– Eclipse Foundation, 2005MSF4ASD– Microsoft, 2005agile@scale – IBM-Rational, 2008Disciplined Agile Delivery–Scott Ambler & Mark Lines, 2012
  10. 10. Disciplined Agile:•Risk-Value lifecycle•Self-organised withingovernance framework•Full delivery cycleIBM: Agile Scaling ModelCore Agile:•Value Driven•Self-OrganisedFocus on ConstructionAgility@Scale:•Disciplined with scaling factorsapplied
  11. 11. Scaling Agile: OpenUP
  12. 12. Scaling Agile:Agility@Scale Scaling Factors
  13. 13. How does agile scale?The same way as all software:• By scaling the methodologyohttp://disciplinedagiledelivery.com/oSlideShare: “IBM Rational Achieving Agility at Scale,Alan Brown”oIBM Developerworks: Agility@Scale• By doing architecture“It’s not agile that’s hard to scale, it’s softwarethat’s hard to scale.” Tom McMillen, CTO intilery.com
  14. 14. Architecture in an agile lifecycle?Options for Where, as in, whenScrum / XP ☛ Architecture SpikeSprint ZeroUnified Process ☛ Inception & ElaborationPoppendieck,“Lean Toolkit…”Fairbanks,”Just Enough…”☛ Continuously withFeedback
  15. 15. Architecture in Core Agile:Architecture Spike or Sprint ZeroBefore development, have just enough architecture, designdecisions, tool & environment work to support it.
  16. 16. Architecture in UP-derivatives:Inception and ElaborationTo leave Elaboration you must:Design, implement, validate, and establish thebaseline for the architecture and test askeleton structure of the system ...This is an executable architecture.
  17. 17. Architecture in UP-derivatives:Construction• The Agile Development phase – full steam ahead• The Evolutionary Architecture practiseo Perform architecture work “just in time”o Document key architectural decisions and outstanding issueso Implement and test key capabilitieso In spite of the name, it is still assumed that the bulk of architecturework is done during elaboration
  18. 18. G. Fairbanks, 2010:Just Enough Software ArchitectureArchitecture and design activities during eachphase, addressing architecture and risk ineach sprint alongside features
  19. 19. Architecture & Agile MethodologyoAre there enterprise level agile methodologies?oHow does agile scale?oWhere & how does architecture fit in an agile lifecycle?oHow are ‘enterprise’ concerns addressedomaturityogovernanceoriskoadoptiono...
  20. 20. GovernanceArchitecture & Agile Methodology• Addressing governance is perhaps thecutting edge of agile adoption• Traditional governance may be anti-agile• You may benefit from critically assessingwhether your governance framework is cost-effective
  21. 21. Governance for Agile DeliveryNational Audit Office, July 2012• Governance should mirror the philosophy ofAgile methods – only do a task if it bringsvalue to the business and does not introducedelays• Light touch and proactive• Focus on the activities and on value, incontrast to traditional methods which checkwhat the team has done to improvepredictions and estimates and reduce thevariation between the baseline and forecasthttp://www.nao.org.uk/wp-content/uploads/2012/07/governance_agile_delivery.pdf pp8–10
  22. 22. Governance for Agile DeliveryAmbler & Lines, Disciplined Agile DeliveryQ: Is your governance strategy designed to enable thework or control the workers?“Three Bold Claims”• Agile teams are significantly easier to govern thantraditional teams.• Traditional approaches to governance are guaranteed toharm agile teams.• Disciplined Agile Delivery teams must demand goodgovernance by their organization.
  23. 23. Risk Management in AgileAgile brings two big guns to risk management• Emphasis on plenty of communicationbetween customer and development team• Early & continuous delivery of software withfeedbackThese must be in addition to – not instead of –your existing approaches. Agile doesnt
  24. 24. Risk Management in AgileMethodologies• UP-inspired approaches still follow the UPmantras: Attack risks early, before theyattack you, and the architecture is a risk.• Fairbanks’ “Just Enough SoftwareArchitecture” is a risk-centric approach:1. Identify and prioritize risks2. Apply relevant architecture activities3. Re-evaluate
  25. 25. FairbanksJust Enough Software ArchitectureA quick test : Are your risks written down?Developers probably have a written list offeatures to develop but the list of risks isoften made up on the spot.⚐Agile usually gives public visibility to progress.When risks other than non-delivery are anissue, give the same visibility to risk as isgiven to delivery
  26. 26. Risk mitigation strategies typicallyrejected in agile• Trying to predict the future in detail• Doing detailed design without code & test• Gathering detailed requirements in a settingwhere they will be outdated by the timeyouve delivered them• Believing that the right process allows you toplug anyone in as an interchangeableresource
  27. 27. Architecture with Agile TeamsQuestions & Issues• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,maturity – how• Personalo How can an agile team and an architect relateeffectively?o How do I the architect add value effectively?• Technicalo Agility as a software qualityo What kind of architecture might count as agile
  28. 28. Threats in RelationshipsThe Architect vs. the Agile Team“The chief measure of progress is workingsoftware” so what value are you adding?“Your up-front design won’t solve ouractual problems or help us respond tochange”
  29. 29. Architect & Agile Team RelationshipsThe power of metaphorArchitect is to builder & bricklayerasSoftware architect is to _______________ ?
  30. 30. Architect & Agile Team RelationshipsThe power of metaphorBut coding is design, not bricklaying.Otherwise robots would do it.If you relate to developers by tossing blueprints over thewall, saying ‘here, implement this’ then your brightestand best will go either elsewhere or will want to bearchitects instead of developers.
  31. 31. Architect & Agile Team RelationshipsThe power of metaphorsoftware delivery is to manufacturingascoding & testing is to product developmentCoding is not stamping out identical copies, it is alwaysdeveloping something new.Copying we can automate; coding we can’t.
  32. 32. The Architect vs. the Agile TeamThreats“Architect”is ahigh-prestigeword andmay implya claim tosuperiorityhttp://clutchtees.com/
  33. 33. The Architect and the Agile TeamRoles for the Architect?If the “best software architectures emerge fromself-organising teams” then your choices are• Join the team• Adopt the Consultant or Coach or Servantrole• Be a validator/peer-reviewer• Be the Architecture Product Owner
  34. 34. The Role of the Agile ArchitectHands-OnHands-Offvs
  35. 35. Architecture with Agile TeamsQuestions & Issues• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,maturity – how• Personalo How can an agile team and an architect relateeffectivelyo How do I the architect add value effectively• Technicalo Agility as a software qualityo What kind of architecture might count as agile
  36. 36. An Agile Technical Architecture–What would it look like?Three possible ways to see this question:• Doing architecture within the agile lifecycleo Methodology• Doing architecture in the spirit of agile valueso How you relate to people• Present an architecture that enables agiledevelopmento What might an agile architecture look like?
  37. 37. Coplien & Bjørnvig, 2010: Lean Architecturefor Agile Software Development• Getting the rightarchitecture enablesrapid agiledevelopment.• “Lean” does meanthinking ahead.
  38. 38. Agility as aSoftware Quality Attribute?Agility would be a kind of modifiability that enables:• Self-organising teamso Allow teams to work autonomously• Continuous deliveryo Adding features & improvements to a software system over anextended period• Responding to changeo Delivering unpredicted requirements at acceptable costWe should be able to describe scenarios/measures for agility, and describetactics to achieve it.The scenario is largely fixed: The team is presented with requirements at thestart of a sprint and responds by delivering an increment of working software
  39. 39. • Measure 1: Cross-team dependencies should be rare• Measure 2: Velocity should not nose-diveo “The team should be able to deliver software atsimilar velocity in months N1-N2 of the project asthey did in the first few months.”• Measure 3: Responsiveness to change should be higho “The team should be able to deliver on newrequirements in each sprint at similar velocity asthey can deliver on known-beforehandrequirements”Agility as a Quality Attribute:Proposed Measures
  40. 40. Tactics for Agility:The Growable Walking Skeleton
  41. 41. Lean Architecture for Agile Software:Coplien & Bjørnvigs Partitioning Steps1) DistinguishWhat the system isvsWhat the system doesA kind of “partition by rate of change”:Stable domain knowledgevs
  42. 42. Lean Architecture for Agile SoftwareCoplien & Bjørnvigs Partitioning Steps2) Partition to maximise the autonomy of teams• You cant fight Conway’s Law“Organizations which design systems ... are constrained toproduce designs which are copies of the communicationstructures of those organizations”Let the human considerations drive the partitioning, withsoftware engineering concerns secondary
  43. 43. Lean Architecture for Agile SoftwareCoplien & Bjørnvigs Partitioning Steps3) Respect domain knowledge• Partition around domains–which should in fact matchbusiness structure• Dont split a domain across geographic locations or acrossarchitectural units• Re-use existing products & product lines to bolster domainpartitioning• Co-ordinate with Conways Law; it shouldnt take a villageto raise a module.• Elicit and use the End-User Mental Model
  44. 44. Tactics for Agility:Architecture as a ‘space’ for functionalityConsider how the architecture for a hotelenables the functionalities of hotelling, e.g.eating and sleeping.It does so by providing spaces within which thefunctions can take place.So the growable skeleton should haveidentified places where an expanding seriesof use-cases can be added.(Software has expandable walls)
  45. 45. OO principles such as SOLIDXP practices & simple designYAGNIDoTheSimplestThingThatCouldPossiblyWorkAgility as a Quality Attribute:Tactics to achieve it
  46. 46. Agility as a Quality Attribute:Tactics to achieve it• An early walking skeleton with identifiablespace for use-cases to expand in• Partition by: rates of change, team structureand domain knowledge• Architect the spaces for adding functionality• YAGNI and Simple Design
  47. 47. Architecture with Agile TeamsThank You For Participating!• Methodologyo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,maturity – how• Personalo How can an agile team and an architect relateeffectivelyo How do I the architect add value effectively• Technicalo Agility as a software qualityo What kind of architecture might count as agile
  48. 48. SoftwareArchitecturewith AgileTeamsAlanGawthorpe&Chris F. Carrollphoto: http://d.lib.ncsu.edu ua023_025 copyright not knownhttp://future-thought.co.uk/abouthttp://www.cafe-encounter.net/about

×