Agile Systems Engineering and Software Engineering

Transcription

1 Agile Systems Engineering and Software Engineering Systems and Software Technology Conference April 20, 2009 John O. Clark Chief Engineer INCOSE Certified SE Professional Information Systems Sector Northrop Grumman Corporation Suzette S. Johnson Agile Practices Lead Software Systems Engineering Electronic Systems Sector Northrop Grumman Corporation

2 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts Summary 2

3 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts Summary 3

4 A New Business Model Traditional Versus Adaptive Business Model Make and Sell Model: Industrial Age Wealth based on tangible and scarce resources Scheduled activities This form of organization excels at planning and control Founded d upon Henry Ford s business concepts Predictable Efficient Inspect and Adapt Model: Information/Knowledge Age Wealth based on intangibles such as software Identifies changing customer needs and new business challenges as the happen Responding quickly and appropriately to customer needs Focuses on capabilities, adaptability, flexibility, agility, and responsiveness Industrial Age 4 Consists of dynamic teams making decentralized decisions based on a shared understanding of organizational purpose Information Age

5 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts Summary 5

6 Tech Talk #1 With your team discuss: What do you already know about Agile practices? What is your level of experience? (1=low to 5=high) What do you think it means to be Agile? What do you hope to cover today? Time: 10 minutes 6

7 What is Agile? Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Jim Highsmith, Agile Software Development Ecosystems Flexibility balanced with structure Balancing on the edge between order and chaos determines success It is not the strongest of the species that survive, nor the most intelligent, t but the ones most responsive to change. Charles Darwin, The Origin of Species What is agile about Agile is when you do the work. John O. Clark, NGIS 7

8 What is Agile? (cont) 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 methods emphasize the need for team and customer collaboration Agile development emphasizes the need for ongoing iterative development with completed, demonstrable functionality; for example: an iteration delivered at the end of every two weeks 8

9 Agile Keywords & Phrases - An Agile Program can consist of multiple, semi-independent Projects - Each Project consists of one or more Deliveries (Releases) - Each Delivery (Release) consists of one or more Iterations - Each Iteration consists of one or more Stories - Each Story consists of Tasks 9 Project 1 n e.g., a Web service - Roles: Delivery 1 Delivery 2 Delivery n 1 n Iteration 1 Iteration 2 Iteration n -2-9 months -Cost Accounting Here -2 weeks for projects in O&M 1 n -2 or 4weeks -Could be delivered -Checkpoint with Customer Story 1 Story 2 Story n -Customer Capability -Measures - Project Leads focus on delivery of their specific project - Service Area Leads (SAL) focus on inter-dependence of multiple projects - Program Management focus on overall program execution 1 n work size (points), risk -Progress = points / day = velocity Can deliver working functionality every iteration Task 1 Task 2 Task 3 -Technical reviews, implementation, verification, documentation, etc.

10 Agile System Development Lifecycle (Stories) (Stories) (Stories) Reference: Dr. Dobb s Journal/Scott Ambler 10

11 Three-month Release (Example) Initiate Project Product Roadmap Customer Needs Done by the Product Owner with the Customer Sys Eng maps stories to high level requirements (if you have them) Six two-week iterations Supported by the Scrum Master SE tasks are included as a task in a given story; such as updating DoDAF views Identify capabilities and high-level requirements (Capabilities Description Document) High Level design and User Stories Define end-to-end thread verifications Create the Product Backlog (stories/functional/nonfunctional requirements) Decide with the Team what stories can be completed in the three months. All team members are involved in this all day planning session Select stories for the iteration The Team defines the tasks for each story and the estimated hours for completion. Tasks include technical reviews, implementation, verification, documentation, etc. based upon a definition of done Design Implementation Unit Verification Integration and Component Verification (TRR) Begin 4 weeks before the start of the release or during iteration 0 for new projects. Systems architecture. As needed, develop activity diagrams, context diagrams, sequence diagrams, etc. High level requirements mapped to end-to-end threads and stories. (System Spec, System Requirements Spec, SW Requirements Spec) Not a handoff Formal System of Systems Integration and Verification at the end of each iteration (e.g., DT&E) 11 Iteration Demonstration and Retrospective

12 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts Summary 12

13 Agile Benefits Deliver a working system early Interact with the customer to determine and constantly review requirements Avoid significant rework by only doing just-in-time detailed design Avoid dead-end design decisions Raise quality by moving verification forward in the process Become responsive by supporting scope adjustments every iteration Increase estimating accuracy by working in small chunks Decrease risk by always having a working system Increase throughput via real-time visibility Increase team communication 13

14 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 Is valued more than Responding to change Following a plan That is, while there is value in the items on the right, we value the items on the left more 14

15 Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of a valuable system. 2. A working system is the primary measure of progress. 3. Welcome changing requirements, even late in development. 4. Deliver a working system frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 5. Business people and developers must work together daily throughout the project. 6. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 7. The most efficient i and effective method of conveying information to and within a development team is face-to-face conversation. 8. Agile processes promote sustainable development. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. ( 15

16 Agile Misconceptions There is no discipline within an Agile Process False. A true Agile Process requires more discipline. Documentation is a requirement. Compliance is mandatory. 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. Agile environments includes everyone: management, contracts, hardware, software, integration, etc. 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. l Project sizes of people are becoming more 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. 16

17 Challenges Implementing Agile Buy-in from engineers Transitioning leadership and management roles (the paradigm shift from command and control to empowered teams) Follow through/action by management Instilling discipline Culture changes and fear of change Organizing distributed teams Scaling for large team implementation Integrating at the systems-of-systems level Earned value for large implementations Estimating complexity, especially when needed for future work Customer learning and frequent customer engagement Meeting CMMI requirements how to do this in an Agile environment 17

18 What I need for Agile to work Automated verification (inspection, analysis, demonstration, test) Communication preferably face-to-face Daily with team High customer engagement Rapid feedback Cut out bureaucracy Focus on barely sufficient Short iterations (e.g., 2 weeks) Emphasis on the people p Disciplined practices Quality working system that meets customer expectations is the goal 18

19 Who is the Team? Roles, Ceremonies, and Artifacts in an Agile Environment ( Phase Product Owner With Customer SE and/or Developers (The Team) Systems Engineer Managers or Product Owner Scrum Master (The Team) Activity Reporting Acceptance Planning Phas ses High-Level (Initiation) (4-6 6 weeks prior to start) Release Identifies the high- level requirements /Epic stories Communicate the Epic stories for the release Approves the plan Writes rough estimates on how much effort the work will take Develops use cases, context diagram, etc. Estimate budget Facilitate story writing workshop Writes the release plan Integrated Master Schedule created Asses the scope and determine if it should be done Create user stories, sequence diagrams, block diagrams, etc. against the requirements Estimate the work Budget and Estimates Release schedule Management The Team Customer and Product Owner Iteration Write the iteration stories with acceptance criteria Estimate the user stories Facilitate story writing workshop Develop iteration level stories and break down into releases and first couple iterations Prioritize user stories Identify velocity Plan is accepted e and Repea at Revis The Iteration Design and Develop Testing Create iteration plan Code Code Reviews Write unit and component tests Integration Daily Stand-up Capability Testing Fix bugs Daily Stand-up Change management Daily Stand-up Grooms the backlog prior to start of next iteration Daily Stand-up Track team velocity Remove impediments Ensure the process is followed Daily Stand-up Track progress Daily Stand-up Communicate with customer and product owner regularly Daily team stand ups The formal test team confirms stories are closed and acceptance tests met. Unit test reports Verbal Iteration Burn down Acceptance tests Unit test reports Defects Product Owner/QA Customer/ Product Owner The Team Formal I&T team 19 Reviews and Retrospective Demonstration Decide whether to deploy Demonstration Story Done Retrospective Demonstration Change management Requirements traceability matrix updated Drop schedule updated Demonstration Updates Release Burndown Earned value metrics collected Demonstration Leads the retrospective IMS Updated The iteration always ends on time Decision whether to deploy Velocity reports Release burn down Requirements progress Earned value metrics Product Owner Customer

20 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts 20

21 Overview of the Most Common Agile Practices Scrum (most often used) Ken Schwaber, Jeff Sutherland com Extreme Programming (XP) Kent Beck, Ward Cunningham, Ron Jeffries Agile Unified Process (AUP) Scott Ambler, Craig Larman Feature Driven Development (FDD) Jeff De Luca, Jim Highsmith 21

22 Comparison of Agile Methods 22

23 Scrum Core Practices Planning game (product, release, Sprint backlog mgmt) 2 or 4 week Sprints Self-directed and selforganizing teams Daily Scrum meetings Don t add to iteration Scrum master firewall Time boxing Blocks gone in one day Chickens and pigs Teams of seven Continuous integration Daily build Sprint review Design to standards d 23

24 Extreme Programming Core Practices Planning game Pair programming Small, frequent releases System metaphors Simple design Testing Frequent refactoring Team code ownership Continuous integration Sustainable pace Whole team together Coding standards 24

25 Agile Unified Process Core Practices Agilized UP Serial in the large Iterative in the small Use-case di driven Modeling Staff knows what they re doing Simplicity Agility Focus on high-value activities Tool independence Manage Requirements Meant to be tailored 25

26 Feature Driven Development Core Practices Feature lists/cards Iterative, feature-based delivery Plan, build, & design by feature FDD values design first (modeling) Shared space Self-discipline Simplify Do what s barely sufficient methodology Self-organizing teams 26

27 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts Summary Backup: Scrum Highlights 27

28 What is a Scrum? Scrum comes from the game of rugby. It is the action of the team to get an out of bounds ball back into play. The team must unite to gain a competitive advantage. Picture from 28

29 Scrum origins Jeff Sutherland Initial scrums at Easel Corp in 1993 IDX and 500+ people doing Scrum Ken Schwaber Advanced Development Methods (ADM) Scrum presented at OOPSLA 96 with Sutherland Author of three books on Scrum Mike Beedle Scrum patterns in PLOPD4 Ken Schwaber and Mike Cohn Co-founded Scrum Alliance in 2002, initially within the Agile Alliance 29

30 Scrum Implementations Microsoft Intuit (1,200 +) Yahoo (2,000+) Nielsen Media Google First American Real Estate Electronic Arts BMC Software High Moon Studios Primavera Lockheed Martin John Deere Philips Lexis Nexis Siemens Sabre Nokia Salesforce.comcom Capital One Time Warner BBC Turner Broadcasting DoD IBM (25,000+) 30

31 Characteristics Self-organizing teams Product progresses in a series of month-long sprints Requirements are captured as items in a list of product backlog No specific engineering practices prescribed Uses generative rules to create an Agile environment for delivering projects One of the Agile processes 31

32 Scrum Terminology Scrum Master The person or persons in charge of the tracking and the daily updates for the scrum (equivalent to a project manager). Sometimes referred to as a Scrum Facilitator. Scrum Team A cross-functional team (developers, SE, DBAs, and verifiers) responsible for developing the product; similar to an integrated product team. Product Owner The person responsible for maintaining the Product Backlog via continuous interaction with Clients and Stakeholders. User Story A customer focused description of valued functionality; similar to functional requirements and includes success criteria. Also captures non-functional requirements. The format is typically As a [user] I want to [action] so that [purpose]. Some teams write features instead of stories; example Calculate the total of a sale for the feature set Selling a new car Product Backlog The stories (requirements) to be completed. Sprint (Iteration) A time period (usually 2 to 4 weeks) in which development occurs on a set of stories that the Team has committed to. Also referred to as an iteration Sprint Backlog The Team's interpretation of the product backlog containing concrete tasks that will be done during the next sprint to implement some of the top items in the Product Backlog. Burn Down Chart 32 Daily progress for a sprint or release for a given product Story Points Product Burndown iteration 0 iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 Story points baseline Burndown (Pts Remain)

33 Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies: Release Planning, Sprint (Iteration) Planning, Iteration Review, Iteration Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Iteration Backlog, and Burndown Chart Points Story P Product Burndown iteration 0 iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 Story points baseline Burndown (Pts Remain) 33 Reference:

34 Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies: Release Planning, Iteration Planning, Iteration Review, Iteration Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Iteration Backlog, and Burndown Chart 34

35 Product Owner Defines the features of the product Manages project features and release to optimize return on investment (ROI) Prioritizes features according to market value Inspects increment and makes adaptations to project Product Back-log Can change features and priority every 30 days Communicates project progress and status Accept or reject work results 35 Reference:

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

37 The Team 37 Typically 5-9 people Cross-functional: - Programmers, verifiers, user experience designers, etc. Members should be full-time - Membership may be exceptions (e.g., database administrator) i t Teams are self-organizing - Ideally, no titles but rarely a possibility Should change only between sprints Selects the iteration 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 goal Manages itself and its work Collaborates with Product Owner to optimize value Demonstrates work results to the Product Owner Reference:

38 Roles and Responsibilities Integrity Owners Product Owner Team Scrum Master 38 Ensures the integrity of the design and implementations across the goals within his area of ownership Has no predefined team Adds to the Product Backlog Defines the features of the product Manages project features and release to optimize return on investment (ROI) Prioritizes features according to market value Inspects increment and makes adaptations to project Can change features and priority every iteration Communicates project progress and status Cross-functional, seven plus/minus two members Selects the iteration 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 goal Manages itself and its work Collaborates with Product Owner to optimize value Demos work results to the Product Owner Ensures that the team is fully functional, productive and improves quality Enables close cooperation across all roles and functions and removes barriers Shields the team from external interferences Ensures that t the process is followed Teaches Product Owner and Team how to fulfill their roles Does not make decisions for the team

39 Tech Talk #2 Scenarios: 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). Reflecting on the section Scrum Roles and Responsibilities Identify your role for the team you are working with today; keep in mind the need for cross-functional teams Identify your responsibilities What do you do? The daily stand-ups are lasting thirty minutes. A team member is not working on one of the features. No one is taking the dreaded task. The team doesn t know what to work on next. Create a team name Time: 15 minutes 39

40 Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies: Release Planning, Sprint (Iteration) Planning, Iteration Review, Iteration Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Iteration Backlog, and Burndown Chart 40

41 Levels of Planning Product Backlog (list of prioritized requirements) Assigned to Release 1 Epic & stories Epic & stories Assigned to Story Story Story Story Iteration 1 Task Task Task Task Epic & stories Epic & stories Epic & stories Epic & stories Epic Iteration 2 Requirements and Stories Product Release 2 Roadmap Iteration 3 Release 3 The product roadmap is built upon the vision of the product owner or program manager. It focuses approximately a year into the future and consists of multiple releases. It consists of high level requirements or capabilities. This list of requirements create the Product Backlog. The Capabilities Description Document describes the capabilities for the release. The high h level l requirements are identified/decided upon for a release. Time: The Release is typically 3-9 months and consists of multiple iterations. The release consists of integrated product features. The Sprint (Iteration) planning is conducted by the team based upon the prioritized backlog. Stories/Features are identified and planned, usually in the form of stories. Iterations are usually 2 4 weeks. Stories are mapped to the requirements. Stories/Features are broken down into tasks that can be completed in a day or two. Tasks are owned by the team. 41

42 Product Backlog The requirements A list of all desired work on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint 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 Release Planning Meeting Meeting is time-boxed Usually 1 day depending on length of the release Occurs at the beginning of the Release with the entire project team Product Backlog with Relative Value Vision Technology Current Product Release Planning Meeting Backlog items with Relative Effort Stories with Acceptance Criteria Stories Accepted for the Release 43

44 From Product Backlog to Sprint Backlog Example: Hotel Website Release backlog Relative Value Relative Effort 80 As a vacationer, I 21 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 Priority/Value Size & Complexity Owned by the Project Manager with the opportunity to reprioritize each iteration Sprint (Iteration) Backlog (Tasks) Design Review 4 Write Tests 8 Hours Code 24 Automate Test 8 Priority/Value The Daily Scrum Yesterday I started on the interface. Today I plan to The one thing standing in my way Stories must have a mission/business value; higher points means greater value Focus on high value items first Determined by the Product Owner/Project Manager who understands d the customer and mission i needs Measure of size and complexity Often method is points Influenced by (a) how hard it is and (b) how much there is to do 44

45 Estimation Business Value Stories must have a business value; higher points means greater value Focus on high business value items first Often the lowest business value items are not done Determined by the Product Owner who understands the customer and business needs Measure of size and complexity Often method is points Influenced by (a) how hard it is and (b) how much there is to do Points are relative values Helps teams determine their velocity that is, how much work can they complete in a given Sprint Preferred over ideal days because one s ideal days cannot be added to someone else s ideal days 45

46 Iteration 0: Project Initiation & Start up The goal of this iteration is to: Gathering initial support and funding for the project Initially model the scope of the system Start to building the team. Begin with at least one or two senior developers, the Scrum Master and Product Owner and one or more stakeholder representatives. 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. 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. 46

47 Developing the Architecture Architecture (i.e., high-level design) is a high-priority nonfunctional requirement Must be completed early so that that functional, performance, and detailed design requirements can be implemented satisfactorily Every Sprint must deliver at least some piece of business functionality To prove that the architecture or infrastructure works To prove to customer that work they care about is taking place Basis for estimating Reference: Ken Schwaber, 47

48 Sprint (Iteration) Planning Meeting Meeting is time-boxed Usually ½ day depending on length of the iteration Product Backlog with Relative Value Team Capabilities Technology Current Product Iteration Planning Meeting Iteration ti Goal Stories with Verification Objectives Iteration Backlog (Tasks associated to a story) 48

49 From Product Backlog to Sprint Backlog Example: Hotel Website Release backlog Relative Value 80 As a vacationer, I want to make a room reservation 70 As a vacationer, I want to change my reservation 60 As a vacationer, I want to cancel my reservation Relative Effort Sprint (Iteration) Backlog (Tasks) Hours Design Review 4 Write tests 8 Code 24 Automate Test 8 The Daily Scrum Yesterday I started on the interface. Today I plan to The one thing standing in my way 50 As a vacationer, I 3 want to pay with a credit card Priority/Value Size & Complexity Owned by the Project Manager with the opportunity to reprioritize iti each iteration Priority/Value Stories must have a mission/business value; higher points means greater value Focus on high value items first Determined by the Product Owner/Project Manager who understands the customer and mission needs Measure of size and complexity Often method is points Influenced by (a) how hard it is and (b) how much there is to do 49

50 Sprints Scrum projects make progress in a series of sprints Sometimes called iterations Typical duration is 2 4 weeks or a calendar month at most A constant duration leads to a better rhythm Product is designed, implemented, and verified during the sprint No changes during a sprint CHANGE 50

51 Sprint: Design, Build, Verify Based on a definition of done Product Backlog Iterati on Planning Written as User Stories (Mike Cohn) As a (user), I want (action) so that (success criteria). Two-week time frame 51 Reference: Hallett, D. (2006). An introduction to agile and iterative project management.

52 Managing the Sprint Backlog Any team member can add, delete or change the sprint backlog Individuals sign up for work of their own choosing Work is never assigned Estimated work remaining is updated daily Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known 52

53 Agile Story Tracking and Decomposition Written at the capability level and can be completed in one Release Written at a level that the team can complete in one iteration Owned by the Product Owner Epic Stories Every Epic has validation criteria User Stories Every story has validation criteria Verification Cases, Unit Verifications Validation Criteria for a given Epic Story Sum of all the derived verification cases to fulfill the Release level validation criteria Tasks written by the Team <=8 hours of work Based on a definition of done Owned by the Team Tasks 53

54 Daily Scrum meetings Parameters Daily Attendance required and critical 15-minutes Stand-up Not for problem solving Three questions: 1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way? Chickens and pigs are invited Help avoid other unnecessary meetings Only pigs can talk 54

55 Scrum and the Enterprise 55

56 Tech Talk #3 How do you see this different from your existing practices? What do you think are the greatest challenges when transitioning to Agile practices? What are three important take-aways from this overview? Time: 10 minutes 56

57 Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies: Release Planning, Sprint (Iteration) Planning, Iteration Review, Iteration Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Iteration Backlog, and Burndown Chart Points Story P Product Burndown iteration 0 iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 Story points baseline Burndown (Pts Remain) 57

58 Levels of Planning Product Backlog, Release, Iteration (Sprint) Product Backlog (list of prioritized requirements) Used to create Assigned to Iteration 1 Release 1 Epic & stories Epic & stories Epic & stories Epic & stories Epic & stories Epic & stories Assigned to Epic Story Story Story Story Iteration 2 Task Task Task Task Product Release 2 Roadmap Iteration 3 Release 3 The Release is typically 3 months and consisted of two or four-week iterations. The Release consists of integrated product features. Iteration planning is conducted by the team based upon the prioritized backlog. Features are identified and planned, in the form of stories. Stories are broken down into tasks that can be completed in a day or two. Tasks are owned by the team. 58

59 Product Backlog EPIC Story: As a vacationer, I want to make a room reservation. 80 As a vacationer, I want to search room availability As a vacationer, I want to change my 8 reservation 60 As a vacationer, I want to cancel my reservation 50 As a vacationer, I want to pay with a credit card 8 3 Priority/Value Size & Complexity 59

60 Product Backlog A list of all desired work/requirements on the project Usually a combination of story-based work ( let user search and replace ) support-based work ( improve exception handling ) Ideally expressed such that each item has value to the users or customers List is prioritized by the Product Owner with Relative Value identified for each item No two items can have the same value For prioritization and identifying ROI Relative value is the business value Relative effort (a.k.a story points) is determined by the team 60

61 From Product Backlog to Sprint Backlog Example: Hotel Website Product backlog 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 Points Sprint (Iteration) Hours backlog Design Review 4 Write tests 8 Code 4 Write online help piece 8 The Daily Scrum Yesterday I started on the interface. Today I plan to The one thing standing in my way 50 As a vacationer, I want to pay with a credit card 3 Priority/Value Size & Complexity Priority/Value Stories must have a mission/business value; higher points means greater value Focus on high value items first Determined by the Product Owner/Project Manager who understands the customer and mission needs 61 Owned by the Project Manager with the opportunity to reprioritize each iteration Measure of size and complexity Often method is points Influenced by (a) how hard it is and (b) how much there is to do

62 From Product Backlog to Iteration Backlog Identify the Iteration stories from the Product Backlog Scrum team takes each story for the Iteration and identifies what tasks are necessary Team self-organizes around how they will complete the story Scrum Masters don t assign tasks to individuals Scrum Masters don t make decisions for the team Iteration Backlog (tasks associated to a story) is created 62

63 Iteration Backlog and Burndown Focus on hours remaining Tasks Design review Write Tests Code Mon Write online help 12 Tues Wed Thur Fri Hours Mon Tue Wed Thu Fri Managed by the Team 63

64 Product Burndown Product Burndown Sto ory Points 800 Based on Story Points Planned Iteration on1 Iteration2 Iteration n3 Iteration n4 Iteration n5 Ideal Burndown Real Burndown Based on Story Points Completed Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Points completed each iteration Iteration1 Iteration2 Iteration 3 Iteration 4 Iteration 5 Ideal Burndown Real lburndown

65 INVEST in Good Stories Independent: Try to write stories that are not dependent on other stories Negotiable: Stories are not a contract Valuable: Stories should be written to reflect value to users, customers, product owners; not developers. Estimatable: Must be able to estimate stories Sized: Sized for eight days or less Verifiable: Need to be verifiable Examples As a user of the MVA website I want to be able to pay my ticket online with a credit card so I don t have to send a check in the mail. This is a good user story As a user of BestBooks website I want to be able to search for a book so that I can make a purchase. This is an Epic level user story that needs to be decomposed. There are many possible queries that could be implemented. Reference: 65

66 Estimating Technique: Planning Poker Estimating the user stories for a release. A release is one or more iterations. 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 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 estimate until estimates converge ? 66 Reference:

67 Team Velocity Velocity for Team A High: 45 story points Low: 30 story points Mean: 37 story points Iteration Velocity is the amount of work a team completes in an iteration. ti Velocity varies slightly over each iteration. Look for the high, the low, and the mean. Compare velocity against team capacity. 67

68 Integration and Verification Integration Team Integration Team Integration Team Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 The Integration Team (IT) integrates and verifies the work of the lower level teams each iteration. If any integration or verification fails, the levels below must fix it before doing any new work. The lower levels get their Product Backlog items from the IT. The teams are responsible for working with the IT to integrate their work. This is not a hand-off, but a partnership. Integration and Verification is upfront in the Agile process not last. Each team, including IT, has their own Product Owners and ScrumMasters. 68

69 Tech Talk #4 Planning a Release 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 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. Review your team roles. Do you have the resources and skills you think you will need to do this work? Using Planning Poker identify story points for each iteration story. Question: How will the team decide how many stories it should assign to an iteration? How do you know which stories to select? Remember: Epics can take more than 1 iteration to complete. Iteration stories must be completed within the iteration based on your organization s definition of done. *Assume one-week iterations 69 Time: 30 minutes

70 Scrum Premises Basic truths about team performance Teams and people do their best work when they aren t interrupted; Teams improve most when they solve their own problems; and, Broad-band, fact-to-face communications is the most productive way for teams to work together. 70 Reference: Ken Schwaber,

71 Scrum Premises (cont.) Basic truths about team composition Teams are more productive than the same number of individuals; The optimum size team is around seven people, and no more than nine; Products are more robust when a team has all of the crossfunctional skills focused on the work; and, Changes in team composition ruin productivity. 71 Reference: Ken Schwaber,

72 Scrum Premises Basic truths about team motivation People are most productive when they manage themselves; People take their commitment more seriously than other people s commitment for them; People have many creative moments during down time; People always do the best they can; and, Under pressure to work harder harder, developers automatically and increasingly reduce quality. 72 Reference: Ken Schwaber,

73 Tech Talk #5 What do you think are the greatest challenges when transitioning to Agile practices? What are three important take-aways from this overview? Time: 5 minutes 73

74 Agenda A New Business Model What is Agile? Agile Benefits, Manifesto, Principles, Misconceptions, Challenges, Needs, and Teams Overview of the Most Common Agile Practices An Example: Scrum Background Terminology Scrum Framework Roles Scrum Framework Ceremonies Scrum Framework Artifacts The Daily Scrum, Sprint Review, Sprint Retrospective Summary 74

75 Summary Use an Agile approach when Complexity of the product is high Requirements frequently change or are not all known Requirements not well understood Need to constantly inspect and adapt to changes There is a desire for more frequent deliveries of a working system 75

76 Summary (cont.) 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 two weeks Agile methods emphasize the need for team and customer collaboration 76

77 Summary (cont.) Agile Systems Engineering Activities: Develop the context diagrams, activity diagrams, and use cases, as needed, during the release planning period Traceability of requirements from high level requirements to user stories if applicable Work with the team break down and analyze requirements into stories or features Change management Responsible for internal and external interfaces across the system An integrated team member Improved communication and visibility Anyone on the team can sign up for a SE task SE related activities are the responsibility of the team and part of the iteration backlog ScrumMaster role is good fit 77

78 A Scrum Reading List Adaptive Enterprise by Steven Haeckel Agile and Iterative Development: A Manager s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber Weekly articles at by Mike Cohn 78

79 Acronyms AUP Agile Unified Process DT&E Developmental Test and Evaluation FDD Feature Driven Development ROI Return on Investment SE Systems Engineering TRR Test Readiness Review XP Extreme Programming 79

80 80