Agile Software and Systems Engineering Tutorial

Transcription

1 Agile Software and Systems Engineering Tutorial Systems and Software Technology Conference Salt Lake City, UT April 2010 John O. Clark Chief Engineer Northrop Grumman Virginia Beach, VA Dr. Suzette S. Johnson Agile Engineering Northrop Grumman Baltimore, MD com Copyright 2010 Northrop Grumman Corporation

2 Agenda Defining an Agile Environment Creating the Team High-Level Agile Steps Capabilities Description and Release Execution Demonstration and Retrospective Delivery Some Final Notes The Great Challenges Agile Reading List 2

3 Today s Outcomes Develop an understanding of the major agile engineering practices Participate in a planning and estimating scenario Gain insight into agile testing practices from a couple practitioners Participate i t in a team retrospective ti Have fun working together! 3

4 Agenda Defining an Agile Environment Creating the Team High-Level Agile Steps Capabilities Description and Release Execution Demonstration and Retrospective Delivery Some Final Notes The Great Challenges Agile Reading List 4

5 The Need for Change Traditional Versus Adaptive Business Model Industrial la Age Knowledge Age Repeatable and Predictable Inspect and Adapt 5

6 The Knowledge Worker

7 Agile Engineering What is Agile Engineering? Includes the entire product life cycle Impacts the entire organization Inspects and adapts Focuses on the value stream Why Agile Practices? Quick reaction capabilities Adapt to change Shortened product life cycle New technological advancements Improved transparency of progress and end-to-end accountability and ownership 7

8 Agile Methods Agile is about how we believe people are best motivated to do work and about demonstrating high value on a regular basis particularly in environments that face high requirement volatility and unpredictability. Extreme Programming Dynamic Systems Development Methods Crystal Methods Agile Methods Agile Unified Process Scrum Adaptive Software Design Feature Driven Development 8

9 What is your level of experience? Scale of 1 to 5 9

10 Agile Principles Early and Continuous Delivery of Value A Working System is the Primary Measure of Progress Welcome Changing Requirements Deliver a Working System Frequently Business People and Developers Must Work Together Daily Motivated and Empowered Individuals Face-to-face Conversation Promote Sustainable Development Continuous Attention to Technical Excellence 10 Simplicity The Best Architectures, Requirements and Designs Emerge From Self-Organizing Teams Regular Team Reflection on How to Become More Effective 10

11 Agile Manifesto Individuals and interactions Is valued more than Processes and tools A working systems Is valued more than Comprehensive documentation Customer collaboration Is valued more than Controlled negotiation Responding to change Is valued more than Following a plan That is, while there is value in the items on the right, we value the items on the left more 11

12 Agile Misconceptions There is no discipline within an Agile Process False. A true Agile Process requires more discipline. Agile is only for software development False. Implementing Agile practices require culture change at all levels. Adapt to and embrace change vs. trying to anticipate the future. The solution to any problem is more process False. Too much process stifles innovation and results in endless workarounds. Agile is only for small sized software efforts False. Agile practices have been growing to the enterprise level. Project sizes of people are common. Agile is turn-key False. The transition from traditional to Agile will take time An Agile process is agile and will continually change over time The greatest challenge is culture and fear of change. 12

13 Agile Terminology Term Definition Fixed time-box in which development occurs Product Backlog Requirements/User Stories to be completed Product Burn Down Chart Product Owner Progress for the release; Focuses on the remaining user story points Owns the product backlog, assigns priority to user stories Release Scrum Master The Team User Story 13 Usually a 2 6 month timeframe; formal committed delivery of product Helps the agile team through the process and removes impediments Cross functional team Similar to a requirement As a user I want what so that purpose 13

14 Introduction to Four Popular Agile Practices Agile Unified Process (AUP) Scott Ambler, Craig Larman Feature Driven Development (FDD) Jeff De Luca, Jim Highsmith Extreme Programming (XP) Kent Beck, Ward Cunningham, Ron Jeffries Scrum Ken Schwaber, Jeff Sutherland t a 14

15 What is Scrum? Picture from 15

16 Scrum Core Practices 2 or 4 week Sprints (s) Don t add to iteration Self-directed and self-organizing Scrum master firewall teams (7 +/- 2) Time boxing Cross functional teams Impediments gone in one day Daily Scrum meetings No ospecific engineering ee g practices defined Product Backlog Release and iteration planning Product Burndown Demonstrations and Retrospective 16 Scrum Framework (Cohn, 2005)

17 Extreme Programming (XP) Core Practices game Small, frequent releases System metaphors Simple design Testing Frequent refactoring Pair programming Team code ownership Continuous integration Sustainable pace Whole team together Coding standards 17 XP Core Practices (Lindstrom & Jeffries, 2004, p. 46)

18 What Methods Are Being Used? Method Percentage Scrum 49.1% Scrum/XP Hybrid 22.3% Extreme Programming 8.0% Custom/Hybrid 5.3% Don't Know 3.7% Agile Unified Process 2.2% Other 2.2% Feature Driven Development (FDD) 2.1% Lean Development 1.9% Dynamic Systems Development Method (DSDM) 1.4% OpenUP 0.6% Agile Modeling 0.6% Crystal 0.5% 18 Research Conducted by: VersionOne Summer ,319 completed responses representing 80 countries

19 Agile System Development Lifecycle (Stories) (Stories) review & demonstration to stakeholders; Retrospectives Release system (Stories) Reference: Dr. Dobb s Journal/Scott Ambler 19

20 0: Project Start up Start building the team. Begin with at least one or two senior developers, the Scrum Master and Product Owner and one or more stakeholder representatives. Training Modeling an initial architecture for the system. You need to have at least a general idea of how you're going to build the system. Identify an architectural strategy. Work through the design details later during future iterations in model sessions. Every iteration must deliver at least some piece of business functionality Setting up the environment. You need workstations, development tools, and a work areas. Start with just enough to get the team going and continue to build on this in future releases. Determine first release date and iteration length 20

21 Agenda Defining an Agile Environment Creating the Team High-Level Agile Steps Capabilities Description and Release Execution Demonstration and Retrospective Delivery Some Final Notes The Great Challenges Agile Reading List 21

22 The Agile Team Based on Scrum Product Owner, ScrumMaster, Team Systems Engineers Hardware Engineers Integration and Test Team Program Management Stakeholders including customers Create a workplace where people want to be, where people are valued, and are full contributors to forming and supporting the direction of the company 22

23 Product Owner Defines the features of the product Manages project features and release to optimize return on investment (ROI) Product Prioritizes features according to market value Inspects increment and makes adaptations to project Communicates project progress and status Accepts or rejects work results Back-log 23 Reference:

24 The ScrumMaster Represents management Responsible for enacting Scrum values and practices Removes impediments Ensures that the team is fully functional and productive Enables close cooperation across all roles and functions Shields the team from external interferences Ensures that the process is followed 24 Teaches Product Owner and Team how to fulfill their roles Reference:

25 The Team Typically 5-9 people Cross-functional: Programmers, verifiers, user experience designers, etc. Members should be full-time Teams are self-organizing ii Ideally, no titles (but rarely a possibility) Should change only between iterations Selects the iteration ti goal and specifies work results Commits to what it feels it can accomplish Has authority to do everything within existing standards and guidelines to reach the iteration ti goal Manages itself and its work Collaborates with Product Owner to optimize value Demonstrates work results to the Product Owner 25 Reference:

26 Self-organizing, Self-managing Teams Team organizes around the work that needs to be done. Management guides the evolution of behaviors that t emerge from the interactions. Self-organization does not mean people get to do whatever they want. The team works to solve their own problems. Management does not solve problems for the teams.

27 27 Expectations of Managers Focuses on resolving organizational problems and larger program issues Establishes check points Manages uncertainty via iterative development Manages complexity via empowered teams Creates and communicates vision Enables communication Promotes constant improvement Establishes governance teams Participates in agile ceremonies Team planning sessions, Demonstrations, Retrospectives Builds trust Motivates and encourages Serves the people and removes impediments Manages contractual details

28 Expectations of the Customer Identifies needs/capabilities Participates in setting priorities ities We ask Is what we are doing useful to you in meeting your goals? Participates in demonstrations of functionality Provides feedback and engages in dialogue about requirements and expectations ti 28

29 Project Team Structure Transition from functional grouping to cross functional teams PM and Technical Lead Chief Engineer Chief Architect Quality Infrastructure Hardware Software Systems Integration Configuration Team Team Team Engineers and dtest Management Lead TM Lead TM Lead TM Lead TM Lead TM Lead TM TM TM TM TM TM TM TM TM TM TM TM TM Isolated progress with too many hand-offs and barriers 29

30 Project Team Structure PM and Technical Lead Chief Engineer Chief Architect Quality Progress against Capabilities or Threads end-to-end d capabilities Cross Functional Team 1 Cross Functional Team 2 Cross Functional Team 3 Cross Functional Team n Services Supports Cross Functional Teams Network/ Systems Administration Push accountability and ownership to the team level 30 An Example Configuration Mgt. Everyone trained

31 Project Team Structure PM and Technical Lead Capabilities or Threads Product Owner Chief Engineer Chief Architect Quality Cross Functional Team 1 Cross Functional Team 2 Cross Functional Team 3 Scrum Master Progress against end-to-end d capabilities Developer Developer Integrator Configuration Management Tester Cross Functional Team n Systems Engineer Developer Services Supports Cross Functional Teams Network/ Systems Administration Push accountability and ownership to the team level 31 An Example Configuration Mgt. Everyone trained

32 Today s Scenario: RestEZ Online hotel reservation system for RestEZ Based on customer needs, your team has defined a logical architecture for the online hotel reservation system. The system is a traditional 3 tier architecture: a database layer (to persist reservations), a business logic layer (to manage reservations), and a browser-based user interface (to receive customer input). 32

33 TekTalk: Roles and Responsibilities Reflecting on the section Creating the Team and the given scenario address the following: With your team, identify the team members and roles. You will need a product owner, scrum master, and team members. Keep in mind the need for cross-functional teams Identify your responsibilities Team discussion: Whose responsibility? The Product Owner is micromanaging the team making self-managing impossible. The team is struggling to understand the priorities of the work. A team member is constantly late for the daily standup. The team is not able to deliver on their commitments. Create a team name Time: 15 minutes 33

34 CheckPoint What we ve covered so far Questions How are we doing? Time: 5 minutes 34

35 Agenda Defining an Agile Environment Creating the Team High-Level Agile Steps Capabilities Description and Release Execution Demonstration and Retrospective Delivery Some Final Notes The Great Challenges Agile Reading List 35

36 Levels of Vision, Product Roadmap, Release,, Daily Product Backlog ~2-6 months (prioritized requirements by business value) Release 1 Story Story Goals &User Stories Story 1 Task Task Task Task ~2 4 weeks fixed Daily Stand Up Product Roadmap 2 3 Vision Customer Needs n 36

37 High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 37

38 Product Roadmap Release 1 Room reservations and payment User profiles for future visits Release 2 Conference offerings Online chat support Release 3 Special discounts Local information Release 4 Google maps 38 Copyright Northrop NorthropGrumman GrummanCorporation Corporation Copyright

39 High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 39

40 Agile Keywords & Phrases - An Agile Program can consist of multiple, semi-independent Projects - Each Project consists of one or more Releases - Each Delivery (Release) consists of one or more s - Each consists of one or more Stories - Each Story consists of Tasks Project 1 n e.g., a Web service Release 1 Release 2 Release n 1 n 1 2 n -2-9 months -Cost Accounting Here -2 weeks for projects in O&M 1 n -2 or 4weeks -Fixed time -Could be delivered -Checkpoint with Customer Story 1 Story 2 Story n 1 n -Customer Capability -Measures work size (points), risk -Progress = points / day = velocity Task 1 Task 2 Task 3 -Technical reviews, implement- ation, verification, documentation, etc. Deliver working functionality every iteration 40 Original creator: David Mooney, NGIS

41 Define the Release and Cycle Vision Customer Needs Product Roadmap Release Execution 3 Month Release Cycle Demo and Retrospective Delivery started in Dec. 1/04/10 3/31/10 Day 1 A.M. = Release Mtg P.M. = 1 Mtg Formal release/delivery End of Each Retrospective Demonstration and Review Potentially releasable Day 1 of Each Meeting 2-4 hours 41

42 Create the Product Backlog A list of all desired work on the project Vision Customer Needs Product Roadmap Release Execution Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Demo and Retrospective Delivery Product Vision Customer Needs Business value 80 As a vacationer, I want to search room availability 70 As a vacationer, I want to change my reservation 60 As a vacationer, I want to cancel my reservation 50 As a vacationer, I want to pay with a credit card 42

43 for the Release Release Vision Product Roadmap Mission Needs (Government) Government Identify Capabilities from the Product Backlog Written at a level that the team can complete in one iteration Owned by the Product Owner Whole Team Systems Engineers High Level Design, Use Cases High-Level Requirements Define end-to-end d capability tests User Stories Release Meeting User Story updates Acceptance Criteria Estimates Commit Begin prior to the start of the release Systems architecture Systems engineering High level requirements mapped to end-to-end capabilities and stories. The Release Plan Six two-week iterations Select stories for the iteration Supported by the Scrum Master SE tasks are included as a task in a given story The Team defines the tasks for each story and the estimated hours for completion based upon a definition of done Design Code/Build Unit Verification Integration and Component Verification Not a handoff Formal System of Systems Integration and Verification at the end of each iteration (e.g., DT&E) Demonstration and Retrospective 43

44 the Release Product: Hotel Website for RestEZ Vision Customer Needs Product Roadmap Release Execution Use Case Flow: Make Room Reservations Demo and Retrospective Delivery Business Value 80 As a vacationer, I want to search room availability User Stories Test Objective Story Points 70 As a vacationer, I Test 8 want to save my request Objective 60 As a vacationer, I want to pay with a credit card Test with Visa Test with AmEx Test The Release Plan What is our velocity? How many story points can we commit to? Owned by the Project Manager with the opportunity to reprioritize each iteration 44

45 Velocity (Based on history) Velocity is the amount of work a development team completes in an iteration (story points completed) Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Velocity is a range; Look for the high, the low, and the mean. Velocity for Team A Project Velocity Story Points Project Velocity per Team A Velocity High: 45 story points Low: 30 story points Mean: 37 story points Project Velocity per High: 155 story points Low: 120 story points Mean: 137 story points 45

46 Release Meeting Meeting is time-boxed Vision Customer Needs Product Roadmap Release Execution Usually 1 day depending on length of the release Occurs with the entire project team Demo and Retrospective Delivery INPUT Product Backlog Business Value Technology Current Product Velocity Release Meeting OUTPUT Stories with Relative Effort Stories with Acceptance Criteria Stories Accepted for the Release 46

47 Commit to the Release Plan Capabilities/Goals identified Vision Customer Needs Product Roadmap Release Execution High level requirements and initial user stories mapped User stories (functional and non-functional 45 requirements) 40 Ex.: Project Teams average about 137 user story points per iteration; for a release with 6 20 iterations this is about 900 story points. The scope is user story points of work. 5 0 Total number of user stories planned (125) Dependencies identified Velocity for Team A Demo and Retrospective Delivery Known or assumed velocity by development team and project team Total number of user stories planned Planned hours (WBS element) Story Points Project Velocity Project Velocity per 47

48 User Stories What is a User Story? Vision Customer Needs Product Roadmap Release Execution Functional stories often based off a scenario of a use case On large projects a user can be another system Non-functional stories Definition of Done Design, Write tests, code, unit tests, documentation, etc. No credit for partial work either done or not done Estimation (2 options) Demo and Retrospective Story Points Bigness of the task Considers: complexity, uncertainty, effort Estimated by the team Relative values As vacationer, I want to search for available rooms. Delivery 48

49 User Stories to Convey Meaning Requirements might say The product shall have a gas engine The product shall have four wheels The product shall have a rubber tire mounted to each wheel The product shall have a steering wheel The product shall have a steel body Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Source Mike Cohn: 49

50 User Stories to Convey Meaning Vision Customer Needs Product Roadmap Release Execution As a <lawn service provider> I want to mow lawns quickly and easily. Demo and Retrospective Delivery As a <lawn service provider> I want to sit comfortably while mowing lawns. 50 Reference: Mike Cohn, mountaingoatsoftware.com

51 Requirements to User Stories Vision Customer Needs Product Roadmap Release Execution The system shall provide the capability for making hotel reservations. Demo and Retrospective Delivery As a premiere member, I want to search for available discounted rooms. As vacationer, I want to search for available rooms. As vacationer, I want to save my selections. 51

52 Non-Functional Requirements? Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery As a vacationer and user of the hotel website, I want the system to be available 99.99% of the time As vacationer, I want web pages to download in <4 seconds Stories for non-functional requirements As the hotel website owner, I want 10,000 concurrent users to be able to access the site at the same time with no impact to performance Describes system behavior or characteristics ti 52 Reference: Mike Cohn, mountaingoatsoftware.com

53 A User Story is Comprised of Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery A written description of the story, used for planning and as a reminder Conversations about the story that serve to flesh out the details of the story Tests that convey and document details that can be used to determine when a story is complete / / 53

54 Writing User Stories Often written by the Product Owner or as a team Brainstorm to generate ideas Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Some stories start out as epic stories; break them down Stories should be drafted and estimated prior to the release planning meeting Independent Negotiable Valuable Estimatable Sized Testable 54

55 Estimating Technique: Poker Estimating the user stories for a release. A release is one or more iterations. Vision Customer Needs Product Roadmap Release Execution Going into the estimation phase, stories for the release have been identified and each has verification objectives; Stories have been discussed with the team. Steps Each estimator t is given a deck of cards, each card has a valid number such as (1, 2, 3, 5, 8, 13, 21,?) The teams read the stories An average story is selected The story is read to the team and discussed briefly Each estimator selects a card to reveal his estimate Cards are turned over so everyone can see them Differences in estimates are discussed; especially outliers Re-estimate until estimates converge Demo and Retrospective Delivery ? 55 Reference:

56 TekTalk: Estimate This! Backlog Item Create a 50 slide presentation on agile practices Relative Estimate Read a James Patterson novel (500 pages) Read a bedtime story to a child Write a 6-8 page article on your latest software project and lessons learned 56 Time: 10 minutes

57 High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 57

58 Detailed Release Vision Customer Needs Product Roadmap Release Execution Initiate Project Product Roadmap Six two-week iterations Identify capabilities and high-level requirements (Capabilities Description Document) High Level design, Use Cases, and User Stories Define end-to-end capability tests Create the Product Backlog Release Meeting Select User Stories for the Demo and Retrospective Begin prior to the start of the release Systems architecture Systems engineering High level requirements mapped to end-to-end capabilities and stories. Detailed Delivery Supported by the Scrum Master SE tasks are included as a task in a given story The Team defines the tasks for each story and the estimated hours based upon a definition of done Design Build Unit Verification Integration and Component Verification Not a handoff Formal System of Systems Integration and Verification at the end of each iteration Demonstration and Retrospective 58

59 Example of Done Designed Design Review Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Refactored Coded Code Review Unit Tested Functional Tested Integration Tested Regression Tested Security Tested User/Stakeholder Tested Documented

60 Release Plan to Plan Example: Hotel Website Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Release Plan Business Value Story Points Plan (Stories with Tasks) Hours 80 As a vacationer, I want to search room availability 21 Design Review 4 Write Tests 8 70 As a vacationer, I want to 8 change my reservation Code 24 Automate Test 8 60 As a vacationer, I want to cancel my reservation 8 50 As a vacationer, I want to pay with a credit card 3 60

61 Meeting Vision Customer Needs Product Roadmap Release Execution Meeting is time-boxed Usually ½ day depending on length of the iteration Demo and Retrospective Delivery INPUT User stories with business value User stories with estimates Team capacity Team velocity Meeting OUTPUT Goals Stories for the iteration Tasks with hours for each user story 61

62 Team Capacity Capacity is the team members available hours to work in an iteration Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Revisited each iteration Compare planned task hours to Example for a two-weekweek iteration capacity hours Team Member Hours per day Total hours in the iteration Bill 5 50 Scott 5 50 Chris 8 80 Andy 7 70 Cindy 7 70 Mike 8 80 TEAM TOTAL

63 TekTalk: and Estimation Scenario: Based on customer needs, your team has defined a logical architecture for an online hotel reservation system. The system is a traditional 3 tier architecture: a database layer (to persist reservations), a business logic layer (to manage reservations), and a browser-based user interface (to receive customer input). Your product owner started to create the product backlog and has provided 2 Epic stories for the first release. With your team complete the following: Read through the stories. Write 2-3 additional stories for each epic story. Include acceptance (testing) criteria. Using Poker identify story points for each story (not epics). Question: How will the team decide how many stories it should assign to an iteration? How do you know which stories to select? Time: 30 minutes 63

64 CheckPoint What we ve covered so far Questions How are we doing? Time: 5 minutes 64

65 High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 65

66 Execution: Design, Build, Test Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Release Plan Story A Story B Story C Story n Itera ation Plan Iterat tion Design Design Story A Build Test Story C Build Design Story D Build Design Test Test It eration Dem and Re onstration etrospectiv n ve Fixed time frame Unit Testing/Component Testing Continuous Integration Test Automation Peer/Code Reviews 66 Reference: Hallett, D. (2006). An introduction to agile and iterative project management.

67 Managing the Backlog Any team member can add, delete or change the iteration backlog Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Individuals sign up for work of their own choosing Work is never assigned Estimated work remaining is updated daily Work for the iteration emerges If work is unclear, define a iteration backlog item with a larger amount of time and break it down later Update work remaining as more becomes known 67

68 A Team s Burndown User Story: As a vacationer, I want to search room availability Week1 Demo and Retrospective 0 Tasks Owner Status Mon Tues Wed Thur Fri Mon Tues Wed Thur Design Review Scott Completed Install baseline Bill Completed ICD updates Scott Completed Acquire test data Bill Completed Code Scott Completed Develop tests Scott Completed Run Tests Scott Completed Vision Customer Needs Product Roadmap Release Execution Delivery The Team 68 Manages its work and progress Meets daily to discuss progress and commit to plan Hours Managed by the Team

69 The Daily Standup SCRUM Daily Standup 1. What did you do since the last stand up? 2. What will you do today? (Commitment) 3. Is anything in your way? SCRUM of SCRUMS Standup (usually two or three times per week) 1. What has your team done since we last met? 2. What will your team do before we meet next? 3. What s in your team s way? 4. What are you about to put in another team s way? Vision Customer Needs Parameters Product Roadmap Release Daily Attendance required and critical 15-minutes Stand-up Not for problem solving Execution Demo and Retrospective Delivery

70 Scaling Scrum Recommendations Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 70

71 Execution: Design, Build, Test Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Developer s Environment Test and Release SoS Environment QA Code Integration Tests End-to-End Unit/Component Product Testing Testing Data Feed Testing Integration Testing Field System 71

72 Agile Testing Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Test Early Test Often Automate 72

73 Theory and Practice Agile testing is about people and communication Test documents are often incomplete, out-ofdate, ambiguous Test results should be big, public, easy-to-read charts Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Testers are embedded with coders The reasons? Speed, accountability, transparency, transfer of knowledge Automated testing is a must Early, Often, Automate t 73

74 Agile Story/Test High-Level Flow Requirements Provided Vision Customer Needs Product Roadmap Release Execution Develop Use Cases Demo and Retrospective Delivery Typically during release planning Write user stories Write test objectives/cases Team develops Integration Individual user story tests verified Demonstration Test Case Testing Regression Testing Performance Testing Enter defect report N Test Pass? Y Verified and Validated 74

75 Check It Out! Vision Customer Needs Product Roadmap Release Execution Agile Testing: Unit, Acceptance, and Regression Testing (#3) 8 minutes com/media-center/educational-videos/1188-center/educational borland-part1 Demo and Retrospective Delivery Time: 10 minutes 75

76 High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 76

77 The Review Demonstrates new functionality Transparency and information sharing Informal Time-boxed Everyone invited What has been tested and what stories are accepted Revisit the backlog Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 77

78 Retrospective Take a look at what is and is not working well Time-boxed Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Done after every iteration Facilitated by the Scrum Master Focus is on process improvement Whole team participates ScrumMaster Worked well Could be improved Actions and Priorities Product owner Team Ways to focus the discussion Consider customers and others Goal we want to accomplish 78

79 Monitoring Progress Product Burndown for the Release Focuses on the Points (Work) Remaining 1000 Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery ry Points Stor Planned Completed Product Burndown A project team s burndown (team of teams) Based on story points planned Updated and reviewed each iteration As stories are accepted and tests passed, requirement progress is updated Story Points iteration 0 iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 Story points baseline Burndown (Pts Remain) A team s product burndown 79

80 End of the Release Similar to end of iteration every iteration is potentially releasable Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Hardening iteration Stories demonstrated and accepted Version description document updated Many disciplined agile teams have a parallel testing effort during construction iterations where defects are found and feed back into the process. In addition, the working software becomes a working system QA testing or DT&E II 80

81 Agenda Defining an Agile Environment Creating the Team High-Level Agile Steps Capabilities Description and Release Execution Demonstration and Retrospective Delivery Some Final Notes The Great Challenges Agile Reading List 81

82 Starting the Transition Communicate the need Communicate how agile practices will affect the enterprise and the people Create an agile leadership team with a transition backlog Provide training Provide a way for people to ask questions and resolve issues Get input Identify the Product Owner, ScrumMaster, and team members Define agile related metrics and mechanisms for gathering g and managing g with them Begin creating the Product Backlog Assess compensation policies to encourage teamwork Start working through Transition Product Backlog Set up brown bag sessions 82 Reference: Ken Schwaber, Check out: Fearless Change by Manns and Rising

83 Thoughts about tools Agile PM/Story Management Excel spreadsheets Wiki Jira/Greenhopper plug-in Rally or VersionOne Mingle Others. Configuration Management and Build Subversion, IBM ClearCase Design and Modeling Rhaposdy Rational Systems Modeler Systems Engineering Requirements Database: ReqPro Continuous Integration Tools Hudson CruiseControl Testing JUnit for Java NUnit for C# Both are very popular and widely used frameworks for writing and running tests (both unit and integration) Cobertura provides JUnit test coverage metrics ti HP Quality Center Rational Quality Center 83

84 Your Greatest Challenges Transitioning leadership and management roles (the paradigm shift from command and control to empowered teams) Culture change Distributed teams Scaling Systems-of-systems level Earned value Estimation Contracts Customer learning and frequent customer engagement CMMI/ISO 9000 Buy-in from stakeholders 84

85 TekTalk: Retrospective Reflect on today s session. What worked well Suggestions for improvement What do you think are the greatest challenges when transitioning to Agile practices? What are three important take-aways from today? Time: 15 minutes 85

86 Kaizen 86

87 Outcome Reflection Develop an understanding of the major agile engineering practices Participate in a planning and estimating scenario Gain insight into agile testing practices from a couple practitioners Participate i t in a team retrospective ti Have fun working together! 87

88 Final CheckPoint Agile is about creating an adaptive organization that is able to respond to the changing needs of customers and industries Agile is not just about software development Agile practices affect the entire organization There are several Agile methods under the umbrella of Agile Practices Agile development emphasizes the need for ongoing iterative development with completed, demonstrable functionality at the end of every iteration Agile methods emphasize the need for team and customer collaboration 88

89 Special Acknowledgments Many of the ideas in this presentation originated from: My initial training by Ken Schwaber and Mike Cohn The Agile Journal Other contributions/research are noted throughout the presentation My experiences with nearly 10 programs and projects across Northrop Grumman 89

90 An Agile Reading List Adaptive Enterprise by Steven Haeckel Agile and Iterative Development: A Manager s Guide by Craig Larman Agile Estimating and by Mike Cohn Succeeding with Agile by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Testing by Lisa Crispin and Janet Gregory Scrum and The Enterprise by Ken Schwaber Weekly articles at by Mike Cohn 90

91 91