LogiGear Corporation. All Rights Reserved. 1 LogiGear Corporation All Rights Reserved Agile/Scrum Development.

Agile/Scrum Development

Table of Contents

Introduction/Course Overview 6 Chapter 1 Introduction to Agile Methodologies 13 What is Agile What do we have now? Chapter 2 Introduction to Scrum 29 Chapter 3 Roles and Responsibilities in Scrum 43 Chapter 4 The Scrum Process 51 Chapter 5 What is NOT Agile 101 Chapter 6 Wrap-up/Summary The Scrum Process 112 Chapter 7 The Main XP Practices 117 Chapter 8 Artifacts in Agile 147 Chapter 9 Project Tools in Agile 153 Chapter 10 Further Study 162

A Note About This Scrum Courseware

Part of this material is available free from Gear Stream.The parts of this course concerning the scrum process are from

GearStream.

Copyright from GearStream:Gear Stream believes that anyone interested in Scrum should

have the opportunity to learn and practice the techniques of Scrum without paying exorbitant training fees. The Scrum Alliance has done a fantastic job of building marketplace acceptance for Scrum, but in our view has not done enough to make basic Scrum education available to those not prepared to spend thousands of dollars on a two day Scrum Certification Class.

We recognize that most teams will still need professional coaching and possibly formal instruction, but that should not prevent teams from taking this material and acquiring the basic skills and knowledge to get started.

The associated Student Handbook is also available free of charge and can be downloaded at:

http://www.gearstream.com/product-content-downloads.html

Please drop us a note if you find these materials helpful.Best Regards,Brad Murphy, Founder & CEOGear Stream –“We Make Software Innovation Flow”

What are your goals?

Grab an index card and a marker.

Think about the objectives of this course.

When you finish this course, you will tell the person next to you “That was a great course, because I got/learned …”

Complete the sentence above on the index card

Time Box: 2 MinutesRead out your goals and post them on

the flip-chart one-by-one

Course Objectives

To understand the basics of the Agile, Scrum and XP Frameworks

• The foundation ideas• Principal Components• Scrum’s Processes• Scrum’s Roles & Responsibilities• How these processes and ideas affect team

dynamics

• How these ideas affect testing and tools.

To equip you to begin applying basic Scrum concepts to existing or future development projects

To help identify the areas of learning you can pursue further on your own

Class Overview

Narrow scope of this class:

Basics of Agile, Scrum and XP

…but mainly about Scrum!

Not about testing

Not a Scrum Master Certification

Not about “role of developers”

This class is mainly about running projects. Not too many practices…

Class Overview- brief

List topics to be covered:• Introduction to the course• What is Agile?

• How is it different?• What is not Agile?

• Understanding Scrum• Glossary

• A quick Sprint/project walk-thru• Important Scrum and XP Practices• Testing on agile• Artifacts in agile • Tools in agile

Class Overview- fullIntroduction to the Course

• Course goals • Ground rules

What is agile? Defining Agile, Scrum, and XP Agile manifesto and XP Values How is it different than what we have now? What is not agile- Nokia test, scrumbuts Scrum

The new glossary for software development• Roles • Artifacts • Ceremonies

A quick walk through, an scrum process • Releasing Planning

• Sprint, Sprint, Sprint, Regression/Hardening• Sprint Planning, Poker • Daily stand-ups • White Board Management • User Stories, Backlogs • Sprints • Retrospectives

The main practices (XP and Scrum) important to testers • Unit Testing, User Story Acceptance Automation • Continuous Integration

Testing on Agile projects Artifacts in agileTools in agile Further study

Course Expectations

Ground Rules• Start and end on time• Electronics (phone, laptop) only by

exception• One conversation at a time

Parking Lots• Used to help us meet workshop

objectives• Staging area for “off topic” concepts,

that we want to come back to at a more productive point in time

What else?• Remember why we move to agile…

Chapter 1

Introduction to Agile Methodologies

What is Agile?

What do we have now?

General Agile Concepts

A collection of methods designed to reinforce:• Time-Boxed activities running in

constant “waves”• Each “wave” producing fully releasable

software • Harmonizing the up and downstream

workflows of an organization to create “flow”

• The formation of cross functional teams of 5-7 people • Business• Project Management• Development• QA• Operations

General Agile Concepts

Agile Methodologies promote:• Disciplined project management

process• Frequent inspection and adaptation• Leadership philosophy that

encourages teamwork• Self-organization and accountability• Rapid delivery of high-quality

software• Alignment of development with

customer needs and company goals

“Faster” SDLCs

Agile- Ideas and a framework for better software development. It is not a methodology.

It is not how you manage a project.

It is not how you manage software development.

The most common practices:• Manage the product? project?

Development practices that are really helpful?

• eXtreme Programming (XP)

Manifesto for Agile Software Development

We are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

http://www.agilemanifesto.org/

The Agile Manifesto

The Manifesto does NOT advocate abandoning the practices on the left…

Processes and tools Individuals and interactions

Comprehensive documentation

Contract Negotiation

Following a plan

Working Software

Customer collaboration

Responding to change

While there is value in the items on the LEFT, We value the items on the RIGHT more

Agile Principles

Business People & Developers

to Work Together

Welcome Changing

Requirements

Deliver Working Software Frequently

Motivated Individuals

Self-O

rganizing Teams

Enforce

-to-Face

versation

Constant Pace in

Development Efforts

Technical Excellence & Good Design

Simplicity is Essential

Agile Principles

Agile Transformation Culture Goals

Management style transitions from “Command and Control” →“Leadership and Collaboration”

Organizational culture transitions from “Process based” →“People based”

Crucial Knowledge Management transitions from “Explicit” →“Tacit”(fully expressed without vagueness ) → (implied or indicated but not actually expressed )

Agile Transformation Culture Goals

Communication transitions from “Formal” →“Informal”

Final User Role transitions from “Important” →“Fundamental”

Organizational structure transitions from “Hierarchical” →“Organic”

Practitioner Roles transition from “Strict Roles” →“Interchangeable Roles”

Main Agile Methodologies

The most well-known agile methodologies are:

• Adaptive Software Development (ASD)

• Agile Unified Process (AUP)• Crystal Clear• Dynamic System Development Method

(DSDM)• Essential unified process (ESSUP)• Feature Driven Development (FDD)• Lean Software Development (LSD)• Open Unified Process (Openup)• Extreme Programming (XP)• SCRUM

Agile compared to “what we have now”

Getting Started –Round Table Discussion

Lets take 10 minutes to discuss “traditional” software development methodologies we’ve used to date …

Focus discussion on:• Identifying strengths• Identifying weaknesses• Identifying areas for improvement

Getting Started –Round Table Discussion

This is not waterfall vs. Scrum/Agile!

That is too extreme. Most companies do not do pure waterfall, most do not do 100% agile.

Think about older processes vs. new ideas.

Traditional vs. Agile Development

Aspect Traditional Methodologies Agile Methodologies

Based onNorms and standards followed by development environment

Heuristics emerged from code production practices

Changes Some resistance to changesSpecially prepared to changes during the project

Adoption Externally imposedInternally adopted (by the team)

Process ControlLess Controlled Process, with lack of principles

Much more controlled process with many principles

Contracts Prefixed Contracts

Customer and TeamCustomer relationship is based in meetings only

Customer interacts with Development Team

Group SizeLarge Groups and probably distributed

Small groups (<10 members) and working in the same site

Artifacts Many FewRoles Many Few

Software ArchitectureIs essential and it is expressed through models Low emphasis

Defined Processes Required Planning and Closure onlyFinal Product Determined during planning Set during projectProject Costs Determined during planning Set during projectCompletion date Determined during planning Set during projectResponsiveness to Environment Planning only ThroughoutKnowledge Transfer Training prior to Project Teamwork during projectProbability of Success Low High

Benefits of Scrum

Fixed Requirements Resource Time

Plan Driven

Waterfall Agile

Value Driven

Estimated Resources Time Features

Chapter 2Introduction to Scrum

Origin & History of Scrum…

1995 –Nonaka and Hirotaka –The Knowledge Creating Company

1990’s –Ken Schwaber –Advanced Development Methods (ADM)

1995 –Sutherland and Schwaber –OOPSLA ‘95 –First Public Appearance of Scrum

February 2001: Agile Software Development Manifesto was created

Why Scrum?

Scrum –Borrowed from Rugby

The purpose of the scrum is to restart play quickly, safely and fairly, after a minor infringement or a stoppage.

Why Scrum?

According to Rugby scrum’s law:• A clear set of rules• Defined roles• Specific tips to “play”• With other elements such as a

ball, the field, etc.

The key idea behind scrum: Players devoting all of their energy to bind together … to advance as a group

What is Scrum?

A light weight, iterative project management framework for helping teams successfully execute and deliver the highest business value in the shortest time.

Particularly well suited to environments where requirements are subject to change and/or where requirements are not fully understood.

What is Scrum?

Scrum consists of a series of sprints optimally 2 or 3 weeks. No longer than 30 days.

A successful sprint always produces fully working and completed software features ready for deployment.

What is Scrum?

Between Sprints, all stakeholders evaluate progress and re-evaluate technical and business requirements & priorities.

Work is re-established and the team enters into the next Sprint.

Philosophy of Scrum?

You can’t predict or plan with absolute certainty what you will deliver, when you will deliver it, and what the cost will be

Start with initial plans surrounding estimates, dates & scope, but then focus on continuous revision of these constraints as you proceed

The goal is to deliver the best possible software given the constraints, but any cookbook approach won’t improve what “best” is.

Philosophy of Scrum?

The pulse of Scrum is key to its success

Management determines what should be done prior to every Sprint, their determination influenced by prior deliverables and changing requirements

During the Sprint, the team is left alone to produce the best software possible

This process produces a potentially shippable set of functionality at the end of each Sprint

Scrum Attributes & Characteristics

FIRST LEGTRANSPARENCY

SECOND LEGINSPECTION

THIRD LEGADAPTATION

Aspects of the process that affect the outcome must be visible to those managing

the outcomes

Aspects of the process must be inspected frequently so

that unacceptable variances in the process

can be detected

If the team determines any aspect is outside acceptable limits, he/she must adjust

the process

Scrum Attributes & Characteristics

FocusesIn

VisibilityAnd ROI

It is Simple

Clear Roles &

Benefits of Scrum

ScrumDelivers highest business value features first

Embraces changing market requirements

Increases probability for successful product delivery

Product functionality delivered every 30 days

Enables low-overhead empirical management

Daily communication of status occurs

Makes impediments visible, early

Elements of Scrum

Product OwnerScrum Master

Sprint PlanningSprint ReviewSprint Retro

Scrum Meeting

Product BacklogSprint Backlog

Burndown ChartsRelease Plan

ROLES CEREMONIES ARTIFACTS

Chapter 3

Roles & Responsibilities in

The Roles Overview…

Stakeholders

ProductOwner

Scrum Master

TeamMembers

The Product Owner

Focuses on the ROI of the product

Defines the features of the product

Prioritizes features according to market value

Decides on release date and content

Adjusts features and priority every iteration, as needed

Accepts or rejects work results

The Scrum Master

Represents management to the project

Responsible for enacting Scrum values and practices

Ensures that the process is followed, including issuing invitations to Daily Scrum, Sprint Review and Sprint Planning meetings

The Scrum Master

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

The Scrum Master

Effective self-organizing teams are developed over time

A Scrum Master varies his/her behavior depending upon where the team is on the Agile Team Maturity Scale

Agile Team Maturity

LOW HIGH

More support needed, Less support and

increased Scrum Master facilitation needed,guidance and facilitation more team self

organization

The Team (Team Members)

Responsible, in each iteration, for transforming the Product Backlog into an increment of Product functionality

Self-OrganizingTypically characteristics of Scrum Teams:

• Composed by 4-9 people• Cross-Functional (e.g., programmers,

testers, user experience designer, etc.)• Members should be full-time (may be

some exceptions e.g., database administrator) No multi-tasking!

• Membership should change only between Sprints

Chapter 4

The Scrum Process

A quick project walk-thru

What is a Sprint?

A Sprint is an Iteration that is Time-Boxed

The work and goals of a Sprint (once started) remains fixed, to insure the Sprint Goals and Team commitments are achieved

Team Member composition and quality goals remain constant throughout a given Sprint

What is a Sprint?

The Sprint “Life-Cycle” Consists of: • Sprint Planning Meeting + • Define-Detail plus Build plus Test +• Sprint Review + • Sprint Retrospective

Sprints occur one after another with no break between Sprints

What is a Sprint?

A Sprint is governed by a set of rules:• A Sprint duration is typically 2–4

weeks, or a calendar month at the very most

• A Sprint is undertaken by a cross functional team consisting of between 4-9 team members

• A consistent Sprint duration leads to better predictability and team velocity

Illustration of the Scrum Flow

VISION

4 weeks

Product Backlog Sprint Backlog Sprint Working Incrementof the software

Retrospective:Reflect &

ReprioritizeBacklog

Release Cycle

Release Planning

4 Week FeatureSprint

4 Week Feature Sprint 4 Week

Feature Sprint

4 Week Release Sprint

Retrospective

User Stories

Short descriptions of functionality, told from the perspective of a user, that are valuable to either a user of the software or the customer.

User Stories

Each user story is composed of 3 aspects:

• Written description of the story (for planning)

• Conversations about the story, as foundational knowledge forming the story

• Acceptance criteria which conveys and document details that can be used to determine when a story is “complete”

User Stories

Theme, Epic, Story, Task (Mike Cohn)

Use a simple declarative statement of function that follows the INVEST model (William Wake):

• Independent• Negotiable• Valuable to users or customers• Estimatable• Small• Testable

User Stories

User Story- Requirement? Use Case?Syntax:User stories generally follow the following template:"As a <role>, I want <goal/desire> so that <benefit>" but the shorter version is commonly used as well:"As a <role>, I want <goal/desire>“

ExamplesAs a tester, I can search for test modules by name, partial or whole, so that I can find a module. As a tester, I can search a tree or module for actions by string, partial or whole name, so that I can find each occurrence of each action.

User Stories

Starting Application The application begins by bringing up the last document the user was working with.

Closing Application Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save).

http://en.wikipedia.org/wiki/User_story

User Stories

Scott Amblin IBM VSTS Scrum Process Template

User Stories

Ron Jeffries has named these three aspects card, conversation, and confirmation:• Conversations about the story serve to

flesh out the details – at the daily scrum/meeting– sit together in a bullpen– difficult for offshore

• Tests that convey and document details that can be used to determine when a story is complete.

When is it done?

Sprints need a detailed and agreed upon definition of done similar to milestone/ entrance /exit criteria in traditional development but due to the very quick nature of sprints, this criteria needs agreement then policing.

When is it done? Example

User Stories• Defined• Validated

Code• Peer reviewed• Unit tests checked into source safe• No open bugs

Quality• Code coverage to some point- 100%,

70%, etc.• Performance/Scalability test cases

executed• User Experience approved by user

advocate.• Localization test cases complete

Documentation• Features documented for Help and User

When is it done?

There are many important aspects of this done criteria.

Prevent coding until the last hour of a sprint and saying:

“Look! Done!”

It gives the team a goal and measuring point during these really rapid cycles.

When is it done?

Also remember- nothing is done until it can be demonstrated.

Each group or team must define done since each product and process is unique.

Release Planning

Purpose: To establish a plan and goals that the Scrum

Teams and the rest of the organization can understand and communicate.

The release plan establishes:• The overall goal of the release • Prioritization of the Product Backlog• The overall release features and

functionality • The major risks of the release• The probable outcome of the release –most

notably delivery date and cost

Release Planning

Products are built iteratively, each Sprint creates an increment of the Product –beginning with the most valuable

Additional Sprints create additional increments of the product

Each increment is a potentially shippable slice of the entire product

When enough increments are created for the product to be of value: It’s ready to be released

Product Backlog

The Product Back log is the master list of all functionality desired in the product.

How does this work?• The PO shows up at the Sprint Planning

meeting with the prioritized product backlog and describes the top items to the team

• Next, the team determines which Items they can complete during the coming Sprint

• The team then moves items from the Product Backlog to the Sprint Backlog

Product Backlog

“A simple collection of index cards”

Product Backlog

Product Backlog sizing and effort estimating is done at the user story level

Story point values are used as an abstraction layer

Product backlog items are given this “relative size” by the team, based on other item sizes in the Backlog

The story point value is consistent within any Sprint, but can vary between teams and between Sprints

Product Backlog

Product Backlog Item Attributes should include:

• Description• Rank/Priority• Complexity/Cost/Size (Story Points or

S/M/L or “fib number”)• Optional attributes: Business Value ($,

L/M/H), Owner, Test, Sample Results• Other options?

Can be defined as a “User Story”, “Story Card”, “Use Case”, what else?

Product Backlog

Complexity/Cost/Size (Story Points or S/M/L or “fib number”)

For sizing I prefer: S/M/L/XL

Most common is using fib numbers (Fibonacci numbers):

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 …

A very common sequence taken from fib numbers:

0, 1, 2, 3, 5, 8, 13, 20, 40,

Sprint Planning

Sprint Planning focuses on planning the next iteration

Sprint Planning consists of two meetings:

• The What? At this meeting, what will be done in the Sprint is decided. 4-hour time-box

• The How? At this meeting, the Team figures out how it is going to build this functionality into a product increment during the Sprint. 4-hour time-box

Sprint Planning

Meeting Part 1 –The What?Input: Product Backlog, Latest Increment

of Product, Team’s Capacity/Past Performance

• The PO presents the top priority Product Backlog to the Team

• They work together to commit to what functionality is to be developed during the next Sprint

• A Sprint Goal is crafted, which will be met through the implementation of the prioritized and committed Product Backlog

Sprint Planning

Meeting Part 2 –The How?Input: Prioritized Product Backlog,

Sprint Goal• The Team figures out how it will

turn the Product Backlog into a done increment

• The teams starts by designing the work

• While designing, key tasks are identified

• Tasks should be done in less that one day

• This task list is called the Sprint Backlog

Sprint Planning Meeting

Your Invited to: Sprint Planning -Sprint #4: 9/1 –9/30

#1 -Greeting, Intros, Mtg AgendaProduct Vision & RoadmapDevelopment Status

#2 –Sprint 3 momentum Team update –availabilities and readiness‘Completed’–what & when

#3 -Product Backlog review status Distribute & review task ownership, time estimatesTeam/individual challenges and dependencies

Review –capabilities requiredChallenges & mitigationsTeam commitments!!Thank you, good job, close

Sprint Backlog

Focuses the Team to turn Product Backlog items to a “Done” Increment

Sprint Backlog items must be decomposed into tasks

Sprint Backlog might be modified throughout the Sprint

As new work is required, the Team adds it to the Sprint Backlog

Sprint Backlog

Is a highly visible, real-time picture of the work that the team plans to accomplish during the Sprint

Spring Backlog Burndown: Is a graph of the amount of Sprint Backlog remaining in a Sprint for the duration of the Sprint

Sprint BacklogRequirement Task

Who's working Status Work Left (Hours)

Member Sign in

Day 1 Day 2 Day 3 Day 4 Day 5

Database Coding Anjali Pending 1

Unit Testing Scripts Anjali Pending 2

Business Logic Anjali Pending 1

UI Test Scripts Anjali Pending 2

Front End Screens Anjali Pending 2

Load Testing Anu Pending 2

Reset Password

Unit Testing Scripts Thomas Pending 1

Business Logic Thomas Pending 1

UI Test Scripts Anu Pending 1

Front End Screens Thomas Pending 1

Integration Testing Anu Pending 1

Change Password

Unit Testing Scripts Thomas Pending 0.5

Business Logic Thomas Pending 0.5

UI Test Scripts Anu Pending 0.5

Front End Screens Thomas Pending 0.5

Integration Testing Anu Pending 0.5

Change Email

Unit Testing Scripts Anjali Pending 0.5

Business Logic Anjali Pending 0.5

UI Test Scripts Anu Pending 0.5

Front End Screens Anjali Pending 0.5

Integration Testing Anu Pending 0.5

Help LinkFront End Screens Anjali Pending 0.5

Manual Testing Anu Pending 0.5

Work Remaining 21 0 0 0 0

Sprint Backlog

Estimates are done at the task level

Team uses ideal effort hours to estimate tasks

Use net hours for what capacity the team can take on –capacity planning takes care of overhead, etc.

Remember, you are not married to your estimates. Give an estimate based upon what the team knows now!

Sprint Tracking and Reporting

What gets measured gets done –focus on metrics that matter

Don’t confuse tradition with necessityShare all project information with everybody!

Possible metrics to consider:• Sprint burn-down / burn-up chart(s)• Build quality per day/week• Number of tests/tests passed per day/week• Velocity over the last X Sprints• % achievement of Sprint level commitments

Sprint Burn-down Chart

ChartTracks daily progress against Sprint

commitment:• “Of our total estimated task effort, what is

left to do?”• “Given what we have left to do and the

amount of time left, what is the best thing we can do today?”

A Burn-down Chart is:• Straightforward and easy to understand• Measures burn rate of the story in the unit

of story points• Can help predict the outcome of the

project by predicting the future velocity of the Sprints

Sprint Burn-down Chart

Sprint Review

A Sprint Review is held at the end of each Sprint

This is a review of a completed product slice

During the review, the Scrum Team and Stakeholders collaborate about:

• What was just done• What are the next things that could be done

Sprint Review

The review includes the following elements:

• PO identifies what has and has not been completed

• Team discusses what went well and wrong during the Sprint

• The team demonstrates done work and answers questions

• PO discusses Product Backlog as it stands• PO projects likely completion dates with

velocity assumptions

Sprint Review

Time-boxed to 2 hours

Team preparation is time-b0xed to < 1 hour

The review starts with a Team Member presenting the Sprint goal

The Team presents to the PO and Stakeholders only functionality that is done

Sprint Review

Stakeholders are polled to get their impressions, any desired changes, and the priority of these changes

Stakeholders can identify any new functionality that occurs to them as they view the presentation

At the end of the review, the Scrum Master announces place and date of the next Sprint Review

Daily Scrum

Time-boxed to 15 minutesBest when held first thing in the morningAll team members are required to attendPrimary object is “synchronization”Scrum Master starts meeting on time

Ask Three Simple Questions:

What Did you AccomplishYesterday?

What Will you Accomplish

Today?

What ImpedimentsAre in your

Daily Scrum Rules

Any members who are late pay $1 to the Scrum Master immediately

Only one person talks at a time

Chickens stand on the periphery of the Team and does NOT interfere with the meeting

Chickens are not allowed to talk with Team members after the meeting to ask for clarification

Manage by whiteboard

What happens at the white board:• All changes are discussed• Status of user story is detailed• Moves are made, work is assigned• Bugs can be discussed• Done is discussed

Sprint Retrospective

A review of how the last Sprint was conducted

Conducted after the Sprint Review, but prior to starting the next Sprint

Scrum Master encourages the Scrum Team to revise their processes and practices to make it more effective and enjoyable

Continue Doing

Stop Doing

Sprint Retrospective

Identifies and prioritizes the major items that went well and those that if done differently could make things even better

Results in actionable improvement measures to implement in the next Sprint

Start Doing

Sprint Retrospective Rules

Time-boxed to 3 hours

Attended only by the Team, Scrum Master and Product Owner (optional)

Scrum master facilitates the meeting

Scrum master writes down team’s answers in summary form

Actionable items that can be added to next Sprint should be devised as high-priority non-functional Product Backlog

With all the newer processes

Important note-This is how we are doing it today…

• Be very, very open to process improvement.

• Don’t write a process .doc to start a project.…

• It all may change in the next sprint- and some parts probably should! What works for some teams may not work for all teams!

• Remember- by definition- we are self-directing!

Chapter 5

What is not Agile

Scrumbuts!

Problems and Misconceptions

This is often a problem with speed. If you adopt even some of these processes, the Team will probably increase code throughput rapidly.

You need infrastructure to support this.

If you are not: automating- heavily …unit testing/TDD …doing continuous integration …very regularly with the “customer”…

… Agile, whatever this means without these practices, will be very difficult.

Scrum will show the maturity level of the team! Dr. Jeff Sutherland

There is a huge human component here that cannot get neglected!

• Tight, constant, good communication• Respect, valuing each other• Team Building!

Without focusing on these takes away form the true nature of Agile which is that people are more important than processes and tools.

Scrum- teams meant to be self-organizing. You can’t impose process or tools!

Also- the group is responsible and can’t point the finger.

Process Problems and Misconceptions

Biggest problem I see here is a Manager (Chicken) says to the Customers, Developers and Testers (Pigs)

Analysts or Marketing people (the customer)- “Stop writing these useless requirements docs and get agile!” and to Developers- “Write and release code faster!”

– With no people, seating, tool, skill, practices changes.

You are still supporting multiple products and are course on multiple teams and still have to keep your meeting schedule- but you have to get faster and be Agile! Multi-tasking does not work!

Instead of “iterations” or “quarterly releases,” we are now going to have 3 or 4 month “sprints.” And still have big teams, and project managers, and process driven structure.

That is NOT agile.

“We are going to stop writing specs and designs and only write story cards. But test teams still have to write all their test cases. We are agile!”

Scrumbut. That is NOT agile.

“We are Agile! But we don’t automate testing.”

We are using Scrum, but…Managers still drive our workWe still put in a lot of overtimeI am on 2 or 3 products

…You’re a Scrumbut

Dr. Jeff SutherlandHyperproductive Distributed Scrum

Do you have to do all?

No. not really• You won’t get the full benefit unless you

implement a lot of the practices• If you do one thing it will make other

problems more apparent.

Dr. Jeff Sutherland Hyperproductive Distributed Scrum Teams

The Nokia Test

1- First, are you doing Iterative Development?2- Iterations must be timeboxed to less than 4 weeks3- Software features must be tested and working at the end

of each iteration/Sprint. 4- The Iteration must start before specification is complete

The experience is that if you ask a lot of "Scrum" teams if they can pass this part of the test, they can't.

The next part of the test checks whether you are doing Scrum (in Nokia's opinion):

5- You know who the product owner is 6- There is a product backlog prioritized by business value 7- The product backlog has estimates created by the team 8- The team generates burndown charts and knows their

velocity 9- There are no project managers (or anyone else)

disrupting the work of the team

Wrong Agile

No documentation to test from

No definition of done

Do enforcement of done

Not including test engineers in sizing and estimation process

No enforced/measurable unit testing

No automatic builds/continuous integration

No significant automation

The team that does not understand testing

Everyone else stops documenting, but same doc demands on test engineers

Chapter 6Wrap-Up / SummaryThe Scrum Process

Review: Planning At A Glance

Product VisionYearly by Product owner

Product RoadmapBi-yearly by product owner

Release PlanQuarterly by product owner

and teams

Sprint PlanBi-weekly by teams

Daily PlanDaily by individuals

Review: Scrum At A Glance

Product Owner –Sets Priorities

Scrum Masters – Manages Processes& Removes Blocks

Stakeholders – Observe & Advise

Product Backlog•Requirements & Issues•Anybody can contribute•Only PO can set priorities

Sprint Goal•One sentence summary•Declared by PO – accepted by team

Sprint Planning(Scrum Master)

•Discuss backlog, existing product,, technology & business conditions•Determine highest priorities•Sets sprint Goal•Team turns selected items into Sprint BacklogOutback – Sprint Goal & Sprint Backlog

Blocks List•Lists of unmade decisions•Updated Daily

Sprint Backlog•Lists of tasks•Owned by Team•Only modified by Team

Increment•Final Version of the product•Shippable functionality

Team – Develops Product

Daily Scrum(Scrum Master)

•Held same time everyday•Attended by all – Stakeholders to not speak•Answer Questions•What did you do yesterday?•What will you do today?•What is in your way?•Output – Team updates Sprint Backlog•Scrum Master updates•Blocks List

Sprint Review(Scrum Master)

•Attended by all•Informal, informational meeting (4 hours)•Team demos Increment•All Players discuss•Hold Retrospective•Determine next Sprint Planning Mtg

MeetingsArtifactsPlayers &

Responsibilities

Review: Scrum At A Glance

Development ProcessSprint – 30 Days each

Product Backlog Increment

Sprint Planning Meeting

Sprint Goal

Daily Scrum Sprint Backlog

Blocks List

Product

Increment

Daily Work

Sprint Review Meeting

Product Backlog

REPEAT PROCESS

Chapter 7The main XP Practices

XP Values

• Communication• Feedback• Simplicity• Courage• Respect

XP Practices

Extreme programming has been described as having 12 practices, grouped into four areas:

• Feedback– Pair programming– Planning game– Test-driven development (TDD)– Whole team

• Continuous process– Continuous integration– Refactoring or design improvement– Small releases

• Shared understanding– Coding standards– Collective code ownership– Simple design– System metaphor

• Programmer welfare– Sustainable pace

http://en.wikipedia.org/wiki/Extreme_Programming

eXtreme Programming (XP) is a set of practices to help software development. Many of these practices are the foundation of the most successful agile organizations.

As one set of practices, developed in 1996 by Kent Beck, published in 1999.

These practices are not new. Unit testing has been around as long as code itself. Yet the principles and practices together, formalized into eXtreme Programming have the most powerful impact on software development.

It then elaborates fourteen principles and twenty-four practices.

One of the most striking is its strong emphasis on testing.

While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code (unit testing, TDD). The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.

The New MethodologyMartin Fowler

Unit Testing:

A developer testing code at the code level, having knowledge of the code to design the tests, is a tremendous practice, when implemented, measured and managed. It is always a significant step toward higher software quality.

Unit testing also has its limitations.

XP was one of the first popular methods to promote ‘Test-First Development’/ test driven Development (TDD)

• Before any code is written, a unit test is written to verify that code.

• Developers work on a piece of code until it passes it’s associated unit test.

• XP also promotes extensive use of test automation for regression purposes.

• Every bug should have an associated automated test which can be run to assure that it does not return.

Some of the key steps in an XP project include:

• Developing ‘User Stories’, which are similar use cases. An important point is that these are written by the customers, and do not necessarily describe the interface of the application.

• Acceptance tests are developed based on the user stories (does the software correctly implement the user story)?

• User stories are intended primarily for estimating the length of the project, not for exhaustively describing the functionality.

Different Testing phases in XP

How does testing fit in with Test Driven/Test-First or eXtreme Programming?

• TDD- Unit tests• Acceptance tests from User stories…

Most XP thinkers talk about two testing phases.

XP two levels of Testing

Functional Testing (QA)• Each feature of the system, which is defined by

something we call a User Story, like a Use Case, must have one or more functional tests that test it.

• The functional tests are the responsibility of what we call the "customer“ (also responsible for defining the requirements).

• The implementation and running of functional tests should be performed by the Software QA group.

http://www.xprogramming.com/qa/xp_q_and_a_QA.htm

This is different than the Team, and not done during a sprint. It is what might now get called “User Acceptance Testing” of Business Acceptance Testing.”

Ron Jefffries www.xprogramming.com

Testing in Agile

XP does suggest a separate phase for end-to-end, environment testing- after the development phases. This is where most teams do security and performance testing. Great place for more “tester testing.”

Testing in Agile

Common names for this are:• Release Sprint• Hardening sprint• …regression (E2E), performance,

security sprint

Continuous Integration

Continuous Integration is a key aspect of rapid development:

• Build often• Automated builds• Automated unit tests re-run• Automated build acceptance (smoke)

testing• Automated functional/regression testing• Harness for testing: include low level

unit tests, include functional tests.

Continuous Integration

Example:Daemon finds updated code in version

control (vss, perforce, sourceforge, clear case)

• Make/Ant build script• Run all unit tests• Run selenium tests• Send a report

Example tools:

CruiseControl, BuildBot, Bamboo, QuickBuild, and many more.

Agile/Scrum

All sounds good?

… all these practices, when implemented well can be a great boost to product and teams.

Testing in Agile/XP

The first part of this discussion is about process and practices.

Now, in part two, more specifically, what does all this mean for testing?

Testing in Agile- So far

Developer testingUnit testing- automated, re-run oftenAcceptance testing- can be automated,

validation (not testing) based on user story.

Continuous Integration-Build Validation

Does this amount of testing mean there are no bugs?

Self organizing teams that may or may not include test engineers

What kind of testing do we do?

Validation comes in automated tests.

“Validate it works” is happy path. This is only one way to execute the code. As we all know, there are may way to execute non-trivial code.

Testing in Agile

Everyone working on the project has to have a good understanding of the benefits and shortcomings of unit testing!

Testing in Agile

Remember, there are limitations to unit and acceptance testing

This is not:• End-to-end• Workflow• User scenario• Usually one path- the happy path. • Alternative paths

Who does this? When?

Testing in Agile

Most companies these days have shifted away from calling people who execute tests “QA.”

That’s good!

There is also a much broader understanding that all team members contribute to software quality.

It is sometimes common for the ownership of quality to belong to the Product Owner, not the Team.

Testing in Agile

People on the project need to understand: • Very short cycles prevent, for better or

worse, more broad and profound testing.

• Architect and design-as-you-go may make testing more difficult.

• Separate phase, or sprint, for end-to-end, workflow, user scenario test case execution.

Exploratory Testing

The skill most needed in agile software testing is excellent exploratory testing skill.

Discovery, research, testing to diagnose, all our gray box testing skill should be the focus of the manual test effort during a sprint.

Use of domain knowledge for testing, the context of the use, understanding of the business is crucial and knowledgeable testing needs to happen during the development cycles.

Testing in Agile

Testers on the team need to focus on:

• Exploratory• Scenario

Unexpected, successful and error pathsTasks using alternative paths, Repeating steps, editing data Skipping sub-tasks

• User focused/ Business testing• End-to-end/ System testing• Interoperability tests

Multiple moving partsDependencies

Automation is essential

Wherever you can, you must have large, effective, automated regression testing!

Best if it can be rolled into the continuous integration/build validation tests run against every build.

Where it is not possible to have large automated suites, automate build acceptance tests as much as possible.

Testing in Agile

If you do not have significant TA (GUI, black box, gray box, scenario, etc.) automation, Agile will fail.

No team can keep up with the rapid release of code without significant automation.

Also focus on developing excellent test data for both automated and manual tests• Run the same scenario with five different pieces of data• Boundary conditions• Null• Illegal data• Unexpected data

… all the great data testers are famous for testing! Often not the focus of unit testing.

Testing in Agile

Most importantly in agile projects, people who test must be• fast • responsive

For this, manual is just not going to cut it anymore.

You have to be in the same room, conversing, running tests, planning automation, building excellent data, automating, focused and fast!

Rapid SDLCs and Testing

What are the effects of a more Agile SDLC on testing:

• The Team commits to delivery!• A much heavier reliance on developer

Unit Testing.• “Testing” has to be universally

understood.• An absolute necessity on Test

Automation.• A larger reliance on Regression Testing. • Regular, well-understood

communication on Test Coverage.• Probably less test documentation. • Separate phase for environment,

platform, performance end-to-end scenario tests.

Chapter 8Artifacts in Agile

Artifacts in Agile

Agile practices come from earlier changes in management thought.

Particularly Lean Manufacturing.

See:http://en.wikipedia.org/wiki/Lean_manufacturing

Andhttp://en.wikipedia.org/wiki/Lean_software_development

These practices look for “waste” in the manufacturing process.

Many people believe excess documentation is a waste!

This is often the case with test plans, test cases and our source documentation: requirements, technical specifications, etc.

Artifacts in Agile

To simplify:If it does not go to the customer- it is a waste,

you do not need it.If it is not crucial, most important to the

project- it is a waste, you do not need it.

Lean: user storiestest ideas on the back of a user storyno bug reports (“a bug is a unit test you

forgot to write” – bugs become unit tests that must pass before release. They are discussed at the daily scrum- not in a database.

Artifacts in Agile

Requirements?Engineering Specifications?Architecture Docs?

Status reports?

Artifacts in Agile

On many agile projects, there is no test plan

On some projects, the number of test cases documented drops a lot!

Test cases – do we write them?Test plansIf you do not write these, can you

measuring testing or decide when testing is complete?

Chapter 9Project Tools in Agile

Tools in Agile

Excellent, full, transparent communication is absolutely essential to being successful at agile. To be successful at offshoring agile we need new and better tools to help us.

Briefly look at ALM (application lifecycle management) tools.

Tools in Agile

What do they do?Coordinate all other tools and coordinate all

communication.Most tools are an umbrella for:Tracking user storiesTracking effort- estimated and actualPrioritizing backlogCalculating and graphing burndownTracking user complaints/call centerTracking test casesTracking bug reportsMeasuring velocityManaging the WhiteboardUnit testingContinuous integration reporting

Tools in Agile

Rally is the most common.

Tools in Agile

Other popular:Collabinet ScrumWorksVersionOneThoughtWorks Studios’ MingleIBM Rational Team ConcertAtlassian’s JIRA

Tools in Agile

Open Source• M-ASE • Story Server• TWiki

XPTrackerPlugin • UserStory.NET • XPlanner• XpCgi • XPWeb • XPSwiki

Commercial• Rally • AgilePlan • VersionOne • Iterate • Scope Manager • ScrumWorks • DevPlanner • XpPlanIt

Chapter 10Further Study

More Study

The Scrum Guide:http://www.scrum.org/scrumguidesThe best, brief overview of Scrum available.

XP:http://www.extremeprogramming.org/

Agile Alliancewww.agilealliance.org

Lean Manager & Practitioners Classeswww.poppendieck.com/courses.htm

SCRUM Master Classwww.controlchaos.com/certifiedscrum/

For More Free Agile & Lean Courseware

http://www.gearstream.com/product-content-downloads.html

“We Make Software Innovation Flow”

Exercise

Why did we do this?

What 5 things did you learn?

_______________________________________

LogiGear Corporation. All Rights Reserved. 1 LogiGear Corporation All Rights Reserved Agile/Scrum Development.

logigear corporation

agile slide

important scrum

techniques of scrum

scrum courseware

scrum glossary

scrum alliance

scrum process

Documents

© 2012 LogiGear Corporation. All Rights Reserved Robot...

© 2008 ZOLL Medical Corporation. All rights reserved.

0 Copyright © ORIX Corporation All rights reserved.

MIS Corporation. All Rights Reserved

LogiGear Press Kit 2020

© 2012 Unisys Corporation. All rights reserved. 1 Unisys...

Copyright Oracle Corporation, 1998. All rights reserved....

©2008, Promega Corporation. All rights reserved. ©2007,...

Copyright all reserved by TAU Corporation

©2013 Microsoft Corporation. All rights reserved..

Giving Good and Bad News Introduction ©2013 LogiGear...

Download Case Study - LogiGear

Copyright © 2006 Tohatsu Corporation. All rights reserved.....

© 2013 Eaton, All Rights Reserved.. © 2012 Eaton...

©2012 Microsoft Corporation. All rights reserved..

2011 LogiGear Global Testing Survey · 2010 – 2011...