Agile Engineering. for Managers. Introducing agile engineering principles for non-coders

Agile Engineering for Managers Introducing agile engineering principles for non-coders Ryan Shriver > Managing Consultant > rshriver@dominiondigital.com Leader in IT Performance Improvement > www.dominiondigital.com Download this and all my presentations from theagileengineer.com

Today s Agenda Story Telling Principles of Agile Engineering Putting into Practice

Expectations?

Roles?

My Agile Journey 1995.. 2000 2001 2002 2003 2004 2005 2006 2007 2008 Scrum XP Evo Developer Software Architect Agile Coach Systems Engineer Started using XP Lead Architect - Product Development development practices J2EE extreme Programming Explained Beck Design Patterns JUnit Refactoring Fowler Martin Test-Driven Domain Driven Project Start using XP with 6 developers. In 18 months we had 40 developers, 100+ project members Automation Scaling Agility Gilb Learned how to make XP adapt firsthand, but struggled with issues not addressed by XP (size and complexity) FitNesse 3-week iterations Sun Labs Collins Contract: 4,400 2,000+ requirements user stories Evo and Scrum Lean Smart Rails Decisions Drucker What s Business Value? Production

My Agile Journey 1995.. 2000 2001 2002 2003 2004 2005 2006 2007 2008 Scrum XP Evo Developer Software Architect Agile Coach Systems Engineer Started using XP Lead Architect - Product Development development practices J2EE extreme Programming Explained Beck Design Patterns JUnit Refactoring Fowler Martin Test-Driven Domain Driven Project Start using XP with 6 developers. In 18 months we had 40 developers, 100+ project members Scaling Agility Gilb Automation Learned how to make XP adapt firsthand, but struggled with issues not addressed by XP (size and complexity) FitNesse 3-week Collins iterations Sun Labs Contract: 4,400 requirements 2,000+ user stories Evo and Scrum Lean Smart Rails Decisions Drucker What s Business Value? Production Can we build large scale systems efficiently and effectively using Agile?

My Agile Journey 1995.. 2000 2001 2002 2003 2004 2005 2006 2007 2008 Scrum XP Evo Developer Software Architect Agile Coach Systems Engineer Started using XP Lead Architect - Product Development development practices J2EE extreme Programming Explained Beck Design Patterns JUnit Refactoring Fowler Yes, but not as currently taught! Martin Test-Driven Domain Driven Project Start using XP with 6 developers. In 18 months we had 40 developers, 100+ project members Scaling Agility Gilb Automation Learned how to make XP adapt firsthand, but struggled with issues not addressed by XP (size and complexity) FitNesse 3-week Collins iterations Sun Labs Contract: 4,400 requirements 2,000+ user stories Evo and Scrum Lean Smart Rails Decisions Drucker What s Business Value? Production Can we build large scale systems efficiently and effectively using Agile?

System Background Suite of Lending Products Web-based system-of-record for billions in assets Platform O/S Database App Servers Rules OS Libraries Tools Testing Performance Java 2 Enterprise Edition Solaris, Windows, Linux, z390 Oracle, SQL Server, DB2 BEA WebLogic, IBM WebSphere Embedded Blaze Rules Engine Hibernate, Spring, Struts, Apache Commons CVS, Maven, CruiseControl, Eclipse, Jira, WIki JUnit, FitNesse, Selenium Mercury, JProfiler, verbose:gc

Software Specifications Lines of Code 673,000 Java classes 5,300 FitNesse Selenium JUnit 118,000 assertions run nightly 9,000 test scripts 637 Test classes - 3,243 test methods Libraries 97 Architecture Adapters MVC, Domain Driven, Events, Services Web Services, JMS, File

Sources of Complexity Accounting Domain Configurability of Product Range of Client Needs Implementation Complexity Performance Requirements

Our User Stories Story Estimate Story Name Unique Story Number QA Testing Estimate Color-coded sticker per application layer / components Signed and dated by QA when approved Strikethrough signifies this developer is done with their piece Developer s initials & their estimate

Our Iteration Tracking

Our Release Backlog Upcoming Stories Upcoming Iterations

Our Continuous Integration

What I Learned

What I Learned Agile technical books didn t provide much guidance on building large scale, high-performance systems

What I Learned Agile technical books didn t provide much guidance on building large scale, high-performance systems System qualities must be Priority #1 for Architects

What I Learned Agile technical books didn t provide much guidance on building large scale, high-performance systems System qualities must be Priority #1 for Architects It s never too late if you follow simple design principles and have an agile codebase Customer Search: 3.962 s => 1.056 s 2x TPS

Principles of Agile Engineering

Principles of Agile Engineering 1. Deliver Value

Principles of Agile Engineering 1. Deliver Value 2. Quantify Qualities

Principles of Agile Engineering 1. Deliver Value 2. Quantify Qualities 3. Explore Alternatives

Principles of Agile Engineering 1. Deliver Value 2. Quantify Qualities 3. Explore Alternatives 4. Last Responsible Moment

Principles of Agile Engineering 1. Deliver Value 2. Quantify Qualities 3. Explore Alternatives 4. Last Responsible Moment 5. Front-to-Back

Principles of Agile Engineering 1. Deliver Value 2. Quantify Qualities 3. Explore Alternatives 4. Last Responsible Moment 5. Front-to-Back 6. Test-Driven Development

Principles of Agile Engineering 1. Deliver Value 2. Quantify Qualities 3. Explore Alternatives 4. Last Responsible Moment 5. Front-to-Back 6. Test-Driven Development 7. Reduce Feedback Cycles

Discussion of Principles As I introduce these principles and we ll discuss ways managers can ascertain whether their team are doing them. Insight for managers wanting to help their teams Many of these mitigate risks (project, delivery)

Putting into Practice Work top-down AND bottom-up Start small and focus on making life better for team Provide resources (time, money, experts, books, lunches) Make principles and practices highly visible Design way to capture and share knowledge and team norms easily (especially for new hires) REWARD!!!!

Reduce Feedback Cycles Examples Communication Release Build Integration Testing The only sustainable competitive advantage is the ability to learn faster than the competition. - Arie de Geus, author of The Living Company

Reduce Feedback Cycles Examples Communication Release Build Integration Testing Benefits Learn Quicker Adapt to Today Reduce Delivery Risk Maximize Opportunities Competitive Advantage The only sustainable competitive advantage is the ability to learn faster than the competition. - Arie de Geus, author of The Living Company

Questions to Ask How long does a local build take? How often is the entire system built and unit tested? If a change is made that breaks the build or some tests, how long before it s detected? How long before it s fixed? How long does it take to create a shippable product, once all changes are in source control?

Test-Driven Development

Test-Driven Development Design Implement Test?

Test-Driven Development Design Implement Test? Test Design Implement Test

Questions to Ask Do we use an automated unit testing framework? Is the team norm to write failing tests before writing code? Does everybody do this? How often do you run all the unit tests locally? What s our code coverage? (ask to see report) Does our QA team use TDD for acceptance tests? Is refactoring a normal part of the development process or reserved for special occasions?

Front-to-Back

Front-to-Back Client System

Front-to-Back Client System User Interface Layer Business Logic Layer Data Access Layer Operating System

Front-to-Back Client System User Interface Layer Business Logic Layer Data Access Layer Operating System Database System

Front-to-Back S P I K E Client System User Interface Layer Business Logic Layer Data Access Layer Operating System Database System

Front-to-Back Client System S S S P I K User Interface Layer Business Logic Layer P I K P I K E Data Access Layer E E Operating System Database System

Questions to Ask Are we shipping fully-working and tested features each Sprint? Are we designing & building entire layers before integrating or just building what we need now? Are all the currently implemented layers integrated today? If not, why not?

Last Responsible Moment Maximize time to gather data and make decision Design for Unknowns Decision based on today s conditions

Questions to Ask Do we need to make that decision now? Why not next month? How would your designs change if we delayed that decision a month? What data are you basing that decision on? Can you explain it to me? Are we keeping as many options open as possible?

Explore Alternative Designs Time Don t decide here Decide here

Explore Alternative Designs Alternative Design Prototypes Time Don t decide here Gathering Facts Team Learning & Knowledge Decide here

Questions to Ask Can you produce at least two viable design options? What criteria are you using to base your decision on? Can I see your requirements, constraints and assumptions for this design? What happens in a month if our chosen design option doesn t work? How long will this delay us?

Quantify Qualities All system qualities can (and should) be quantified

Response Time Specification

Response Time Specification Name: Web Response Time

Response Time Specification Name: Web Response Time Scale: Time in seconds from request until response for [Defined Transactions]

Response Time Specification Name: Web Response Time Scale: Time in seconds from request until response for [Defined Transactions] Meter: As measured from [Defined Users] computer running Mercury Load Agent Target [Release 2; Average Load; All call centers; 95th percentile]: < 1 second desired by Acme Fail [Release 2; Average Load; All call centers; 80th percentile]: > 3 seconds contractually required by Acme

Response Time Specification Fail 3 25% 2.5s Target 1 First Baseline 500 ms Response TIme Fail 0 % Target 100%

Questions to Ask Are the top non-functional requirements identified and prioritized? Can I review them? What non-functional requirements, if not met, are Deal Killers? What s their level of specification? Are Target and Failure levels present and quantified? Do your Failure levels match contractual SLA s?

Focus on Delivering Value to Stakeholders Stakeholders Values Objectives Resources

Focus on Delivering Value to Stakeholders Stakeholders Values Objectives Resources Features!= Value Anything Legal and Ethical Separate Ends from Means

Questions to Ask Do you know who your stakeholders are? Can you prioritize them? Do you know what what they find most valuable? Can it be expressed with measurable objectives the team can focus on? Does your entire team know this? Will the current set of prioritized features deliver value quickly? Does your team think creatively and work collaboratively to solve problems?

Case Study of Focusing on Stakeholder Value Jens Egil Evensen

What did we learn? Principles of Agile Engineering Techniques for putting into practice Quantifying qualities can be light-but-rigorous

Thank You Questions? Ryan Shriver > Managing Consultant > rshriver@dominiondigital.com Leader in IT Performance Improvement > www.dominiondigital.com Download this and all my presentations from theagileengineer.com