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

Transcription

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

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

3 Expectations?

4 Roles?

5 My Agile Journey 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

6 My Agile Journey 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?

7 My Agile Journey 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?

8 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

9 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

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

11 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

12 Our Iteration Tracking

13 Our Release Backlog Upcoming Stories Upcoming Iterations

14 Our Continuous Integration

15 What I Learned

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

17 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

18 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: s => s 2x TPS

19 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: s => s 2x TPS I wish I had known sooner about the exponential importance of qualities...i was busy focusing on user stories

20 Principles of Agile Engineering

21 Principles of Agile Engineering 1. Deliver Value

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

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

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

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

26 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

27 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

28 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

29 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)

30 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!!!!

31 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

32 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

33 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?

34 Test-Driven Development

35 Test-Driven Development Design Implement Test?

36 Test-Driven Development Design Implement Test?

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

38 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?

39 Front-to-Back

40 Front-to-Back Client System

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

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

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

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

45 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

46 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?

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

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

49 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?

50 Explore Alternative Designs Time Don t decide here Decide here

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

52 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?

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

54 Response Time Specification

55 Response Time Specification Name: Web Response Time

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

57 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

58 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

59 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

60 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 Benchmark [Release 1; Average Load; Test Lab; 95th percentile]: 2.5 seconds

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

62 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?

63 Focus on Delivering Value to Stakeholders Stakeholders Values Objectives Resources

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

65 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?

66 Case Study of Focusing on Stakeholder Value Jens Egil Evensen

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

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