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 Suzette.Johnson@ngc.com com Copyright 2010 Northrop Grumman Corporation
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
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
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
The Need for Change Traditional Versus Adaptive Business Model Industrial la Age Knowledge Age Repeatable and Predictable Inspect and Adapt 5
The Knowledge Worker
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
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
What is your level of experience? Scale of 1 to 5 9
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 http://agilemanifesto.org/ 10
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 http://agilemanifesto.org/
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 200 600 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
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
Introduction to Four Popular Agile Practices Agile Unified Process (AUP) Scott Ambler, Craig Larman http://www.ambysoft.com/ Feature Driven Development (FDD) Jeff De Luca, Jim Highsmith Extreme Programming (XP) Kent Beck, Ward Cunningham, Ron Jeffries Scrum Ken Schwaber, Jeff Sutherland www.controlchaos.com www.mountaingoatsoftware.com t a 14
What is Scrum? Picture from www.ricerugbyclub.com 15
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)
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)
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 2008 2,319 completed responses representing 80 countries
Agile System Development Lifecycle (Stories) (Stories) review & demonstration to stakeholders; Retrospectives Release system (Stories) Reference: http://www.ddj.com/architect/207100381;jsessionid=r1i5m44b21upgqsndlpskhscjunn2jvn?pgno=2 Dr. Dobb s Journal/Scott Ambler 19
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
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
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
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: www.mountaingoatsoftware.com
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: www.mountaingoatsoftware.com
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: www.mountaingoatsoftware.com
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 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
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
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
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
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
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
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
CheckPoint What we ve covered so far Questions How are we doing? Time: 5 minutes 34
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
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
High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 37
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 Copyright2009 2010Northrop NorthropGrumman GrummanCorporation Corporation Copyright
High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 39
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
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 1 2 3 4 5 6 Formal release/delivery End of Each Retrospective Demonstration and Review Potentially releasable Day 1 of Each Meeting 2-4 hours 41
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
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
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 3.. 12 16 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
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 45 40 35 30 25 20 15 10 5 Story Points 160 140 120 100 80 60 40 20 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 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
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
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 35 30 25 story points per iteration; for a release with 6 20 iterations this is about 900 story points. The 15 10 scope is 720-930 user story points of work. 5 0 Total number of user stories planned (125) Dependencies identified Velocity for Team A Demo and Retrospective 1 2 3 4 5 6 7 Delivery Known or assumed velocity by development team and project team Total number of user stories planned Planned hours (WBS element) 160 140 120 100 80 Story Points 60 40 20 Project Velocity 0 1 2 3 4 5 6 7 Project Velocity per 47
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
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: www.mountaingoatsoftware.com 49
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
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
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
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 http://www.mountaingoatsoftware.com/article_view/27 / / 53
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
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 1 2 3 5 8 13 21? 55 Reference: www.mountaingoatsoftware.com
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
High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 57
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
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
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
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
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 40 400 62
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
CheckPoint What we ve covered so far Questions How are we doing? Time: 5 minutes 64
High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 65
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.
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
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 4 4 4 3 2 0 0 0 0 Install baseline Bill Completed 4 4 4 0 0 0 0 0 0 ICD updates Scott Completed 8 8 6 3 3 2 0 0 0 Acquire test data Bill Completed 8 5 0 0 0 0 0 0 0 Code Scott Completed 24 20 16 14 10 10 3 0 0 Develop tests Scott Completed 8 8 8 6 4 4 4 3 0 Run Tests Scott Completed 8 8 8 8 5 3 4 2 0 1 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
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
Scaling Scrum Recommendations Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 70
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
Agile Testing Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery Test Early Test Often Automate 72
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
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
Check It Out! Vision Customer Needs Product Roadmap Release Execution Agile Testing: Unit, Acceptance, and Regression Testing (#3) 8 minutes http://www.agilejournal.com/media com/media-center/educational-videos/1188-center/educational borland-part1 Demo and Retrospective Delivery Time: 10 minutes 75
High Level Agile Stages Vision Customer Needs Product Roadmap Release Execution Demo and Retrospective Delivery 76
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
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 1. 2. 3. Product owner Team Ways to focus the discussion Consider customers and others Goal we want to accomplish 78
Monitoring Progress Product Burndown for the Release Focuses on the Points (Work) Remaining 1000 Vision Customer Needs Product Roadmap Release Execution 900 800 700 Demo and Retrospective Delivery ry Points Stor 600 500 400 Planned Completed 300 200 Product Burndown 100 0 140 35 120 30 100 25 80 20 60 15 40 10 20 5 0-20 1 2 3 4 5 6 7 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
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
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
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, www.controlchaos.com Check out: Fearless Change by Manns and Rising
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
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
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
Kaizen 86
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
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
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
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 www.scrumalliance.org www.mountaingoatsoftware.com by Mike Cohn 90
91