Arch In An Agile Org Agile Palooza

Architecture in an Agile Organization Managing our Software as a Valuable Asset while Delivering Incrementally Chris Sterling Technology Consultant, Certified Scrum Trainer, and Agile Coach

Architecture in an Agile Organization • As companies begin to embrace Agile methods, such as Scrum and Extreme Programming (XP), questions about architecture begin to emerge. – How is architecture implemented in an Agile organization? – What is the software architect's role with Agile development? – How should architecture be discussed with business stakeholders? • Too often, Agile software development methods are tagged as \"architecturally weak\" or \"disconnected from the realities of delivering large systems.\" However, leading software architects are pushing through the noise to rapidly evolve the Agile architecture discipline. • This session will focus on the experiences of two experts and the approaches they have taken to better align businesses with architecture goals. • Presented by: – Chris Sterling, Technology Consultant, Certified Scrum Trainer, and Agile Coach at SolutionsIQ 2 Copyright © 2009 SolutionsIQ. All rights reserved.

Topics to Discuss • Self-Organizing Project Teams • Practices versus Guidelines • Managing Software Debt • Coherent Architecture Strategy • Where can we start? 3 Copyright © 2009 SolutionsIQ. All rights reserved.

Questions for You... • What does “architecture” mean to you? • What issues are you having currently with architecture? • Why do we worry about architecture? 4 Copyright © 2009 SolutionsIQ. All rights reserved.

Self-organizing Project Teams

* “The best architectures, requireme nts, and designs emerge from self-organizing teams” * The Agile Manifesto - http://www.agilemanifesto.org

* Self-organizing Project Teams • Autonomy: top management provides guidance, money, and morale support • Self-transcendence: team seems on never- ending quest for “the limit” within guidelines set forth by top management • Cross-fertilization: team consisting of varying functional specializations, thought processes, and behavior patterns * From Harvard Business Review Jan/Feb 1986 “The New New Product Development Game” by Hirotaka Takeuchi and IkujiraNonaka 7

Practices versus Guidelines

Practices versus Guidelines • Practices: techniques, methodologies, procedures, and processes that are used to get the job done • Guidelines: aim to streamline particular processes according although, by definition, following a guideline is never mandatory. Guidelines are an essential part of the larger process of governance to make delivery more predictable, and presumably of higher quality 10 Copyright © 2009 SolutionsIQ. All rights reserved.

Example Practices • Code Review • Threat Modeling • Filling out Document Templates • Test-Driven Development • Pair Programming • Continuous Integration 1111 Copyright © 2009 SolutionsIQ. All rights reserved.

Example Guidelines • Increase Code Coverage • Audit Trail for all System User Interactions • Have all Source Control Check-ins Reviewed • Each Team Member Checks in an Artifact every Day • Applicable Features Pass Security Audit Policies 13 13 Copyright © 2009 SolutionsIQ. All rights reserved.

Managing Software Debt

The Problem... • Software gets more difficult to add features to as it ages • Business expectations do not lessen as software ages • Software must remain maintainable and changeable to meet needs of business over time • Lack of emphasis on quality attributes to keep software maintainable 15 Copyright © 2009 SolutionsIQ. All rights reserved.

Software Asset Liabilities • Like-to-like migrations • Limited experts capable to work on a system • Long release stabilization periods • Increasing duration of costly regression test phases • Higher costs for people to work on legacy software 16 Copyright © 2009 SolutionsIQ. All rights reserved.

Like-to-Like Migrations • “It will be easy since we worked on the original version” - although we understand the domain we will be fighting with new features, technology, tools, and processes • “We don’t have any other options” - Refactoring and test automation are potential alternatives to like-to- like migrations. 17 17 Copyright © 2009 SolutionsIQ. All rights reserved.

Increasing Cost of Release Stabilization Periods $500,000.00 $450,000.00 $400,000.00 $350,000.00 $300,000.00 $250,000.00 $200,000.00 $150,000.00 $100,000.00 $50,000.00 $0.00 Release 1 Release 2 Release 3 Release 4 Release 5 Release 6 Cost of Fixing Defects Cost for Feature Dev 19 Copyright © 2009 SolutionsIQ. All rights reserved.

Higher Costs for People • Legacy software expenses increase with time oLegacy platform programmers (COBOL) more expensive due to lack of experienced people to meet demand oMany legacy platform programmers are close to retirement oSignificant assumptions have been made by legacy platform programmers about implementation details oSpecialized tools have more of a cult following oMany people with specialized skill sets cost much higher than people with mainstream skills oChances are that highly specialized or uncommon tool platforms will not be supportable over the long run Copyright © 2009 SolutionsIQ. All rights reserved.

Software Debt Creeps into our systems and leaves our organizations with liabilities

Managing Software Debt – an Overview Effect of Managing Software Debt over time is extended preservation of software’s value Higher Software Value Potential for depreciation is always there so discipline is essential Minimum Acceptable Value Time Copyright © 2009 SolutionsIQ. All rights reserved.

Technical Debt Issues in software implementation that will impede future development if left unresolved

* Ward Cunningham’s Definition of “Technical Debt” • Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. • Technical Debt doesn’t include deferred functionality, except possibly in edge cases where delivered functionality is “good enough” for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard). * Ward Cunningham - “Technical Debt” - http://c2.com/cgi/wiki?TechnicalDebt Copyright © 2009 SolutionsIQ. All rights reserved.

My Definition of “Technical Debt” “Technical debt is the decay of component and inter- component behavior when the application functionality meets a minimum standard of satisfaction for the customer.” Copyright © 2009 SolutionsIQ. All rights reserved.

Quality Debt A lack of quality, either technical or functional, will minimize value per feature added increasingly over time

A Fit Case Study Cost reduction using Fit for test automation and data conversion

Manual Regression Testing • Testing was taking 75 person hours during 2 full test runs consisting of: – Comprehensive manual regression testing – Data conversion and validation • Cost for testing was $17,000 each iteration 36 Copyright © 2009 SolutionsIQ. All rights reserved.

Introducing Fit into Testing Process • After 8 iterations team had introduced healthy amount of Fit fixtures and automated tests • Reduced 70+ hour test runtime down to 6 hours which now included: – Fit automated regression testing – Data conversion and validation automated with Fit fixtures • Reduced cost of testing each iteration from $17,000 to $7,000 37 Copyright © 2009 SolutionsIQ. All rights reserved.

Acceptance Test-Driven Development Functional Implement Functionality Requirement Execute Draft Acceptance Test Cases Acceptance Test Cases Review Results Verify Results Accepted Modify Acceptance Test Cases 38 Copyright © 2009 SolutionsIQ. All rights reserved.

Bug or Enhancement How is maintenance handled in Agile?

The Situation: New Features Must be in next release which is 1 month away. Involves multiple user stories currently estimated to be delivered in 3 weeks based on velocity of Team. 42 Copyright © 2009 SolutionsIQ. All rights reserved.

The Situation: Should we work on bugs or enhancements first? • Fix bug and deploy within 2 weeks • or • Finish 3 weeks of enhancements to deploy in next release • The Catch: The release is due to go out in 1 month and doing both will not fit into this timeframe. 43 Copyright © 2009 SolutionsIQ. All rights reserved.

Definition of Done Define what is involved in delivering a potentially shippable product increment each iteration

Capture Resulting Artifacts • Be careful capturing delivered artifacts in Definition of Done – Should capture resulting artifacts – Minimize capture of transitory documentation – Minimize capture of practices – Different for each Team but may include enterprise guidelines when appropriate 47 Copyright © 2009 SolutionsIQ. All rights reserved.

Configuration Management Debt Debt in this area can be unpredictable, prone to error, and cause poor decision-making on quality attributes of a system

Traditional Source Control Management Feature Complete Version 1 Integrate for Branch Version 2 Debt Main Branch Death March { Debt accrues quickly within stabilization periods 49 Copyright © 2009 SolutionsIQ. All rights reserved.

Design Debt Design decays when not attended to so put effort into maintaining your software by designing all the time

Merciless Refactoring • Refactoring: a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.* • Merciless: having or showing no [mercy - showing great kindness toward the distressed] • Relieve your distressed code through kindness and disciplined restructuring * From http://www.refactoring.com/ 54 Copyright © 2009 SolutionsIQ. All rights reserved.

Automate Testing to Support Refactoring • Refactoring cannot be done effectively without automated tests surrounding code • Start by creating automated test which fails • If difficult to create at unit level look at automated acceptance tests from functional perspective • Over time look for ways to create automated unit tests 55 Copyright © 2009 SolutionsIQ. All rights reserved.

Design Debt When the cost of adding new functionality to an existing system is more than writing it from scratch

* Architecture Risk Themes * From “Risk Themes Discovered Through Architecture Evaluations” by Len Bass, Robert Nord, William Wood, and David Zubrow • Observed that twice as many risk themes are risks of “omission” as are risks of “commission”. That is, risk themes identify decisions or investigations that were never made rather than those that were made and could lead to undesirable consequences. • No discernible relationship between articulated business and mission goals of a system and risk themes from an ATAM evaluation of that system • No discernible relationship between domain of system being evaluated and risk themes associated with development of that system 57 Copyright © 2009 SolutionsIQ. All rights reserved.

Proper Architecture Design Provides Value Software is a business asset and our job is to produce the greatest Return on Investment (ROI) by delivering high value quickly

* Abuse User Stories As a Malicious Hacker I Implement Security want to steal credit card for User Information information so that I can make fraudulent charges * From “User Stories Applied” presented by Mike Cohn Agile 2006 59 Copyright © 2009 SolutionsIQ. All rights reserved.

Platform Experience Debt How many of you are writing Legacy Code?

How to Combat Platform Experience Debt • Ignore it (I do not suggest this!) • Write automated functional tests for existing system functionality • Connect through interface to underlying system • Transfer knowledge of platform to more people • Rewrite system on more current platform • Move thin slices of functionality to more current platform over time • Start architecture upgrade discussions and involve teams through known team configuration patterns Copyright © 2009 SolutionsIQ. All rights reserved.

Virtual Architect Pattern • Pros – Share architecture ideas and needs across teams – Based on verbal communication • Cons – Usually singles out special Team Member role – Could lead to top-down architecture decisions – IT may gain extensive influence and begin to run Product Backlog prioritization for architecture needs 64 Copyright © 2009 SolutionsIQ. All rights reserved.

Integration Team Pattern • Pros – Reduces complexity on Feature Teams – Forces delivery from Integration Team instead of interface and deployment designs • Cons – Perpetuates specialized roles – Don’t always work on highest value Product Backlog items 66 Copyright © 2009 SolutionsIQ. All rights reserved.

Component Shepherd Pattern • Pros – Share more knowledge within organization to minimize platform experience debt – Work on highest value Product Backlog items • Cons – Not always optimal as using individual knowledge – Difficult to learn multiple systems across Teams 68 Copyright © 2009 SolutionsIQ. All rights reserved.

Team Architect Pattern • Pros – Team owns architecture decisions – Decisions are made close to implementation concerns • Cons – May not have appropriate experience on Team – Team could get “stuck” on architecture decisions 70 Copyright © 2009 SolutionsIQ. All rights reserved.

Coherent Architecture Strategy

Working with Legacy Software Define Analyze What Write Acceptance Might Be Executable Criteria for Affected by Specifications Requirement Requirement for How it Works Now Execute Carefully Write Failing Executable Modify Source Executable Specifications Code to Specifications to Verify Implement for How it Change Requirement Should Work 73 Copyright © 2009 SolutionsIQ. All rights reserved.

Working with Legacy Software • Focus on Writing Executable Specifications for New Requirements and Functionality that may be Affected • Stabilize Legacy Software with Black-box Tests (Executable Specifications) • Incrementally Improve the Internal Software Design • Try to Identify where Programmer Tests can be Added • Execute Regression Test Suite that Includes Executable Specifications Frequently (more than once per day if possible) 74 Copyright © 2009 SolutionsIQ. All rights reserved.

Working with COTS (Commercial Off-The-Shelf) • COTS does 80% of what we need usually • We conduct custom configurations to enable rest of what we need • Automate functional tests for all customizations • Automated functional tests can be executed against future upgrades to see what “broke” 75 Copyright © 2009 SolutionsIQ. All rights reserved.

Working with COTS (Commercial Off-The-Shelf) Create Version 1: 2: Executable Specifications COTS for Software Configurations & Customizations Execute Version 2: Existing Executable COTS Specifications Software to Find Upgrade Path 76 Copyright © 2009 SolutionsIQ. All rights reserved.

Where do we start? Knowing areas to improve on is one thing. How can we make progress from where we are today?

Some Suggestions • Focus on guidelines rather than practices to influence quality of team deliveries • Maintain one list of work • Emphasize quality • Evolve tools and infrastructure continually • Improve system design always • Check in project artifacts more often (Continuous Integration) • Automate builds from compile to deploy • Share knowledge across organization • Hire the right people to work on your software! 79 Copyright © 2009 SolutionsIQ. All rights reserved.

Principles of Agile Software Quality • The system always runs • No code is written without a failing test • Zero post-iteration bugs * From “Flawless Iterations” presented by Alex Pukinskis at Agile 2005 80 Copyright © 2009 SolutionsIQ. All rights reserved.

Thank you Questions and Answers

Chris Sterling • Technology Consultant, Certified Scrum Trainer and Agile Coach at SolutionsIQ • Consults on software technology across a spectrum of industries • Consults organizations on Agile development, management, and enterprise practices • Founder of International Association of Software Architects (IASA) Puget Sound chapter • University of Washington Lecturer: Agile Developer Certificate Program • Email: CSterling@SolutionsIQ.com • Blog: http://chrissterling.gettingagile.com 82 Copyright © 2009 SolutionsIQ. All rights reserved.

Arch In An Agile Org Agile Palooza

0 comments

Notes on slide 1

Favorites, Groups & Events