Agile Bootcamp - Sketch Development...

Agile Bootcamp

Welcome

John Krewson, MBA, CSM, CSP• St. Louis, MO, USA

• IT Background: software developer, project manager, development director, product director

linkedin.com/in/krewson

: @johnkrewson

Two Rules

Have fun Ask questions

My Worst Nightmare

INTRODUCTION TO AGILE

The History of Agile

The Agile Manifesto

We are uncovering better ways of developing software 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

That is, while there is value in the items on the right, we value the items on the left more.

www.agilemanifesto.org

Principles Behind the Agile Manifesto

Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

http://www.agilemanifesto.org/

http://www.agilemanifesto.org/

Welcome changing requirements, even late in

development. Agile processes harness

change for the customer's competitive advantage.


Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the

shorter timescale.


Business people and developers must work

together daily throughout the project.


Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job done.


The most efficient and effective method of conveying

information to and within a development team is face-to-

face conversation.


Working software is the primary measure of

progress.


Agile processes promote sustainable development. The

sponsors, developers, and users should be able to

maintain a constant pace indefinitely.


Continuous attention to technical excellence and good design enhances

agility.


Simplicity -- the art of maximizing the amount of

work not done -- is essential.


The best architectures, requirements, and

designs emerge from self-organizing teams.


At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior

accordingly.


Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

Welcome changing requirements, even late in

development. Agile processes harness

change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

Business people and developers must work

together daily throughout the project.

Build projects around motivated individuals. Give them the environment and

support they need, and trust them to get the job

done.

The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.

Working software is the primary measure of

progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances

agility.

Simplicity -- the art of maximizing the amount of

work not done -- is essential.

The best architectures, requirements, and designs

emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective,

then tunes and adjusts its behavior accordingly.

Exercise: Pocket Principles

Fact or Fiction?

The cost of fixing a defect is exponentially higher once the feature

is in production.

Fact or Fiction?

Software should be developed for today, but designed for tomorrow.

Fact or Fiction?

Software development follows the same rules as building construction.

Fact or Fiction?

Rework should be avoided.

Marshmallow Challenge

Complicated or Complex?

Something that is Complex is never completely knowable, because there are too many interacting variables (e.g., how an aircraft will perform during a specific flight).

Something that is Complicated is not simple, but is ultimately knowable (how an aircraft is constructed, for example).

Defined Process

• Every piece of work is completely understood• Given a well-defined set of inputs, the same outputs are generated every time

Empirical Process

Empirical: “Derived from or guided by experience or experiment”

• Every piece of work is not completely understood• Given a well-defined set of inputs, the same outputs are not generated every time

Empirical Process Control

Inspection

Transparency

Adaptation

Transparency: keep everything visible

Inspection: review the product and the process continuously

Adaptation: continuously improve the product and the process

Empirical Process Control

What is an “Agile Project”?

Project: “A temporary endeavor undertaken to create a unique product, service, or result”

PMBOK, 4th edition

From Projects to Products

So when will it be finished?

What?

You're talking about fashion? Really, you?

Okay. But they manage to make money selling pants.

It won't be finished. That's the point. The way fashion's never finished.

Fashion. Fashion is never finished.

I'm talking about the idea of it. And I'm saying that it's never finished.

Agile’s Emphasis is different

Deliver working, valuable, software to the customer iteration over iteration

Consistency is key

Adapt the plan to deal with reality

Deliver everything, on-time, within budget, and as initially specified

“Estimation accuracy” is key

Control reality to fit the plan

The “Iron Triangle”

AGILE FRAMEWORKS,

METHODOLOGIES, AND TERMINOLOGY

What are Agile Organizations Doing?

VersionOne's 10th Annual State of Agile survey

Why Bother?

What Benefits are they Realizing?

The Heartbeat of Scrum

The Flow of Kanban

Iterative & Incremental Delivery

1 2 3

But incrementing calls for a fully formed idea

“incrementing” builds a bit at a time

Thanks to Jeff Patton for these Slides


1 2 3

Iterating allows you to move from vague idea to realization

“iterating” builds a rough version, validates it, then slowly builds up quality

Thanks to Jeff Patton for these Slides


Shout Out

What advantages can be gained by using an Iterative and Incremental approach to delivering products and services?

OVERVIEW OF AGILE ROLES

People in an Agile Organization

= = ?

Agile Roles in General

The Customer (or Product Owner) Role

● Is responsible for the profitability of the product (ROI)

● Defines and clearly communicates the vision, goals, and Product Backlog to the Team

● Collaborates with stakeholders, both internal and external

● Creates the Product Backlog and maintains it to best achieve the Product Vision and Release goals

● Ensures that the Product Backlog is visible and clear to everyone, and clearly indicates what will be worked on next

● Ensures that the Team understands the Product Backlog, collaborating with the Team by being available to it as needed

● Decides on release date and content

● Adjust features and priority between sprints, as needed

● Participates in iteration meetings

● Accepts or rejects work results

Product Manager vs. Product Owner

Product Manager (Strategic PO?) Tactical Product OwnerOne per product line One per team

Focus on Marketing Strategy and Strategic Planning (for executives)

Focus on Product Backlog and Sprint Planning (for Scrum teams)

Sales process, tools & collateral Product operational rollout & documentation

Defining market opportunities Addressing market opportunities

Customer acquisition & retention Customer & User product feedback

Product pricing & marketing strategy development Feature set optimization within set pricing constraints

Product Managers focus on predictable product management, while Product Owners focus on productive product creation.

Thanks to Arlen Bankston for this slide.

Product Management Model

Product Owner

Product Marketing Manager

UX Manager

Product Manager

What Makes a Good Product Owner?

● Available!

● Enjoys collaborating with the team

● Understands what is really important to the end users

● Good rapport with stakeholders

● Good negotiation skills

● Willingness to respect the team’s true capability to deliver an increment that is “Done”

● Willingness to invest the time required to develop backlog items and manage the Product Backlog

● Understands that he/she is in a collaborative partnership with the team

● Understands, or at least appreciates, the technical process the team is using

● Understands that the team determines the “how”, but remains engaged and asks questions

The Facilitator Role

● Is a Servant-Leader to the Customer, the Team, and the Organization

● Ensures that the team adheres to Agile values and practices

● Helps the Team and the organization adopt Agile values and practices

● Helps the team learn to self-organize and work cross-functionally

● Removes impediments to the team’s ability to keep its commitments

● Acts as a change agent

● Protects the team from interruptions and interference

● Teaches the Customer how to work within Agile to maximize ROI

● Ensures that the meetings happen, and usually facilitates them

What Makes a Good Facilitator ?● Good facilitation skills

● Patience

● Good listener

● Good “questioner”

● Leader by example

● Encouraging

● Handles conflict well

● A good teacher

● Knows how to “choose his/her battles”

● Comfortable working with and presenting to all levels in the organization

● Ability to see the big picture

● Self-confidence

● Humility

● (some technical experience helps, but not critical )

The Team Member Role

● Partners with the Customer in maximizing the value of a potentially-shippable increment, sprint over sprint

● Defines the Iteration Backlog, commits to it, and delivers it

● Manages its own work

● Self-organizes to meet commitments

● Stands accountable as a Team

● Establishes the ground rules for its own behavior

● Participates in iteration meetings

● Assists the Customer with Product Backlog grooming

What Makes a Good Agile Team?

● Self-organizing● Cross-functional ● Empowered● No titles, other than “Team Member”● Optimally, 5-10 people● Members are willing to expand their skill sets and do whatever is needed● Made up of “Specializing Generalists” (aka, “T-shaped People”)● Stable composition ● Co-located ● Members dedicated to the team

Exercise: Any 3rd grader could do it!

Sidebar: Multitasking

✓ It has been proposed that multitasking can result in the loss of 20% of “working capacity” for every project added.

✓ Multitasking creates a sort of “brownout” effect on the brain.

✓ Prolonged multitasking has been shown to actually reduce IQ

What About Traditional Roles?

Kanban

Scrum

What Part Do Managers Play?

Where Do Project Managers Fit?

● Creates and executes project work plans and revises as appropriate to meet changing needs and requirements

● Identifies resources needed and assigns individual responsibilities

● Manages day-to-day operational aspects of a project and scope

● Reviews deliverables prepared by team before passing to client

● Effectively applies our methodology and enforces project standards

● Prepares for engagement reviews and quality assurance procedures

● Minimizes our exposure and risk on project

● Manages day-to-day client interaction

● Sets and manages client expectations

● Communicates effectively with clients to identify needs and evaluate alternative business solutions

● Ensures project documents are complete, current, and stored appropriately

● Must be able to lead and drive project team to success

Composite Job Posting for a Project Manager(abstracted from various online job boards)

AGILE TEAMS

Self-organization

“The best architectures, requirements, and designs emerge from self-organizing teams.”

…the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning.

Tuckman’s Stages of Group Development

Apollo 13“Give them the environment and support they need, and trust them to get the job done.”

AGILE LEADERSHIP

Servant Leadership

Servant Leader

Servant Leadership

Servant Leader

What Motivates Us? Video“Build projects around motivated individuals.”

What Motivates Us?

STRATEGIC AGILE PLANNING

The Agile Approach to Planning

Rolling Wave Planning

• Rather than planning all the scope for a large project up front and then resisting change, scope is planned and adjusted as reality emerges.

• Adjust the plan to reflect reality; don’t try to force reality into a stale plan!

Strategic Planning: Value Discipline

Customer Intimate

Product Innovative

Operationally Efficient

Product Vision: Example

For weekend camping enthusiasts

Who cannot travel far from home

The “Home Site” web site is a smart device-enabled site

That informs campers of campsites and events within a selected distance radius of their chosen location

Unlike similar sites that have stale information

Our product is updated at least twice a day, with streaming feeds for premium customers

Roadmapping

Roadmap : a sequenced, themed plan of intent

PRODUCT PLANNING

Product backlogA prioritized list of features that the customer would like to have developed into their software product

Backlog item (Story)A high level description of an individual feature in the backlog. It is a placeholder for a future conversation about that feature

What is a Backlog?

Characteristics of a Backlog

Each iteration implements The highest priority features

High

Low Feature

s

Each new feature is Prioritized & added to the stackFeatures may be reprioritizedAt any time

Features may be removedAt any time*

Certain

Less Likely

ProbabilityRank Order

High

Low

Level of Detail

High

Low

Value

Lower LikelyLower

Three Most Common Backlogs

Product Backlog Grooming

Detailed Appropriately: The higher an item is ranked in the backlog, the closer it is to being implemented, and the more effort we put into the details.

Estimated: Product Backlog items are estimated at a coarse level by the Team.

Emergent: As Product Increments are created, and as internal and external factors shift, the Customer adjusts the content and ranking of the Product Backlog.

Prioritized: The position of an item in the Product Backlog indicates its importance relative to the other backlog items. Because of emergence, a backlog item’s rank may change.

The ongoing process of readying the Product Backlog for selection into a Sprint

Product Backlog Grooming

Iteration Backlog (Tasks)

User Stories

Product Backlog

Big Ideas, “Epics”

Product Backlog Prioritization

Financial Impact

Risk

Desirability

Cost of Delay

Financial Impact

Return on Investment (ROI) Is Profit ÷ Cost > the minimum acceptable level?

Net Present Value (NPV)Is the present value of net future cash flows positive?

Uses a market-based discount rate to convert future dollars to present value

Internal Rate of Return (IRR)What is the interest rate that makes the projected cash flows = the investment?

Minimum Marketable Feature (MMF)Uses the individual features ROI features’ estimates to sequence them for maximum project ROI

Issues with Cash flow Analysis

Must consider:• New Revenue: new revenue from new customers• Incremental Revenue: new revenue from existing

customers• Retained Revenue: revenue from existing customers we

would have lost had we not undertaken this project or implemented this feature

• Operational Efficiencies: reduced costs resulting from having undertaken this project or implemented this feature

Risk

Risk-adjusted backlog

Desirability

● MoSCoW

● Kano Analysis

● Relative Weighting

MoSCoW

From the customer’s perspective:

● Must have

● Should have (if possible)

● Could Have (desirable, but not necessary)

● Won’t have (at least now)

Kano Analysis

Items tend to migrate from Exciters and Delighters to Must Haves over time.

Relative Weighting

Considers both benefit and penalty

Weighted Shortest Job First (WSJF)

Considers:• Perceived value to the user/customer• The urgency from a timing perspective• The potential to reduce risk or discover a new opportunity

Day 1 Review

AGILE REQUIREMENTS AND ANALYSIS

How Agile Looks at Requirements

Deliver working, valuable, software to the customer sprint over sprint

Deliver everything, on-time, within budget, and as initially specified

Traditional Requirements

The product shall have a gasoline-powered engine

The product shall have four wheels

The product shall have a rubber tire mounted to each wheel

The product shall have a steel body

On a sheet of paper or index card, draw a picture of the end product specified below:

(DON’T LET YOUR NEIGHBOR CHEAT OFF OF YOU! ) ☺

User Goals

The product makes it easy and fast for me to mow my lawn

I am comfortable using the product

What is a User Story?

Product Owner promises to be available when the team needs to talk

“”

A short, simple description of feature told from the perspective of the person who desires the new capability, usually a user or customer (or purchaser) of the system

- Mike Cohn

A “promise for a future conversation” Sprint Team promises to talk to the Product

Owner rather than just doing what’s in black and white or “going cowboy”

Why User Stories?

Focus on User goals vs. a checklist of requirements

Requirements can evolve

Easy to understand

Time Bound: Requirements have a shelf-life

Meeting Goals or Specifying Features?

Why is Conversation Important?

“ ”User stories take us from writing about requirements to talking about them.

- Mike Cohn

User stories:• Focus on the user’s needs, instead of a list of

specifications• Are easy to understand• Can be discovered and documented quickly• Limit the amount of investment required to formulate a

project’s “scope”

Why is Conversation Important?

Types of User Stories

• New features• Enhancements• Low-level technical items• Architectural/infrastructural items• Non-functional items, such as documentation• Defects/bugs• Break/fix• “Spikes”

Gathering User Stories

User Interview

Observation

Questionnaires

Story-Writing Workshops

Primacy-recency

What is a User Story?

Functionality ValuableUser Role

Three Parts of a User Story:

3C’s of a User Story:

Conversation ConfirmationCard

What is a User Role?

A collection of attributes

that define and characterize a population of users

and their intended interactions with the system

Characteristics of a Good User Story

Independent

Negotiable

Valuable

Estimable

Sized Appropriately

Testable

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/



Exercise: Bad Stories

1. You work for a bicycle company that is planning to build and sell a new kind of bicycle.

2. Each table group write 2 intentionally “bad” user stories, based on INVEST, and then present to the rest of the class.

3. The rest of the class will have to identify what’s wrong with the stories.

Writing a Good User Story

As a _____________

I want to be able to ______________

so that __________________ .

User Role

Statement of value

Statement of function

“As a Concerned Parent, I want to beable to view my kids recent status updatesSo that I can be informed of what they are saying.”

“As a Mobile user, I want to be able to post status updates from a mobile device, so that I don’t always have to use a computer.”

Story Acceptance Criteria

Written by thecustomer

Define “Done”Documentsthe conversations

Writing Good Acceptance Criteria

Given _____________

When ______________

Then __________________ .

Some condition

User takes some action

Other possible actions

“Given that am logged into Circle of TrustWhen I select contacts designated as my childrenThen I am presented with an option to view recent status updates.”

“Given that am a Circle of Trust user,When I send a SMS text message to my accountThen My test message is posted as a status update.”

Example: Story with Acceptance Criteria

Title: Block Social Networking Sites

Description: As a concerned parent I want to block access to selected social networking sites So that I can protect my children from undesirable online influences.

Acceptance Criteria: Given I am logged in as an Administrator and am on the Filters page When I select ‘Block Social Networking’ Then I am presented with a list of Social Networking applications that I can block.

(There would likely be more acceptance criteria, as discussion ensues.)

Writing Good User Stories

Epics

Epics

When Does Analysis Begin?

“Build a birdhouse”

As a bird loverI want a nice birdhouse that attracts birdsSo that I can enjoy watching birds

Acceptance Criteria?

Over-specification?

AGILE DESIGN

Vertical Slicing

Incremental, Emergent Design: “We don’t have to know everything before we can start anything.”

Horizontal and Vertical Slices

AGILE ESTIMATION

Let’s Paint the Room

Conventional Estimation

Seeks to directly answer the question, “How Long?”

Conventional Estimation

The Cost of Estimation

Estimation involves direct and opportunity costs.So does re-estimation.

So do obsolete requirements that have been estimated.

How Agile Estimation Differs

Agile estimation differs from conventional estimationin two fundamental ways:

vs

Can We Still Estimate in Units of Time?

Two Levels of Estimation

Estimation Units

Relative size(e.g., “Story Point”)

Task time(e.g., “Ideal Hours”)

Relative Estimation Exercise

Estimate the dogs above in “dog points”:1. The minimum point size is 1 dog point.2. Based on size, select a dog that you consider to be 1 dog point.3. Using only whole numbers, estimate the other dogs relative to that dog (a dog twice as big would be a two, etc.)

___ Labrador Retriever

___ English Bulldog

___ Chihuahua

___ Scottish Terrier

___ Great Dane

___ St. Bernard

___ Dachshund

Planning Poker

Affinity Estimation

Feature Estimation – Now What?

I get it: for each feature, we estimate “How Big?”

But how does that help when the boss wants to know how long it’s going to take?

Velocity

The rate at which a team can produce working software

More accurately stated, it is measured in terms of the stabilized number of [estimation units] a team can deliver per sprint of a given length, and with a given Definition of Done.

Velocity in Everyday Life

Remaining Scope

ProjectedEnd Point

Velocity

Tracking Velocity

20 story points of working features

accepted


accepted


accepted

Velocity for this team over three 2-week sprints averages 20 story points, based on the measure of story points accepted per sprint.

Velocity is the key to “How Long?”

• Size (complexity) is estimated-A story is estimated to be 3 story points in relative complexity

• Velocity is measured-“Team A can deliver 20 story points in a 3-week sprint”

• Duration is forecast- “Based on Team A’s measured velocity of 20 story points per sprint, it will take Team A 3 sprints to deliver 60 story points.”

Capacity vs. Velocity in Planning



Notes About Velocity

• If team composition, iteration length, and definition of Done are kept stable, a team’s velocity on a project typically stabilizes after 3 or 4 iterations.

• After velocity stabilizes, it will likely still have some variability from iteration to iteration. The trend of the velocity, however, will be such that the variation from iteration to iteration will be very small.

• Changes to team composition, iteration length, or definition of Done will affect team velocity.

• Velocity is a Team measure, and shouldn’t be used as a measure of comparison across teams.

• Velocity for a Team will likely have some variation from project to another (depending on the dissimilarity of the projects), and so demonstrated velocity on one project should not be the required target for a subsequent project

Exercise: Projecting Dates/Duration

A team has a demonstrated, stabilized velocity of 15 story points per 2-week iteration. This stabilized velocity is based on a rolling, 4-iteration, historical average. The actual observed velocities over that period range from 12 to 18 story points. The remaining items in the backlog have a total story point count of 75. The product owner wants to know how long it will take to deliver the remaining backlog.

1. What is the answer to the product owner’s question?

2. What options does the product owner have if that answer is not acceptable?

Projecting Cost

Projecting Project Cost

Estimating Feature Cost

Project Duration Historical Cost per Sprint

$ $ $ $

Feature Size Historical Cost per Story Point

$ $ $ $

RELEASE PLANNING

A Release is a Series of Iterations

A release is not necessarily an external release to the customer. These can simply be strategically-grouped features that are implemented as a collection of working increments (via each iteration).

To avoid any misunderstanding, some organizations will call these internal releases by another term – perhaps, simply, “milestone”.

Benefits of a Release Cadence

When we work to a cadence of releases that are “not too long” in duration (3 months is typical):

• Projects are of a size that we can wrap our heads around• The shorter time box fosters better prioritization and a sense of forward

momentum• We have planned inspection and adaptation points• We avoid the perception of knowing everything in advance, because it is

understood that we will learn as we go and make adjustments

Overview of the Release Planning Process

Elements of a Release Plan

• The name, or title, of the release• The start and end dates of the release• The names of the Product Owner, Facilitator, and Team members• The Theme, or overarching Goal of the release• The iteration scheme within the release

• How many iterations• Each iteration’s start and end date, and theme• The projected velocity per iteration

• The projected velocity for the release (sum of the iteration velocity projections)• Could be accompanied by a projected release burndown chart

• The backlog of user stories planned for the release (can prospectively arrange them by iteration, as long as it is clear that the sequencing could change)

• Title• Estimate

• Assumptions• Risks/Issues

What will fit in the Release Backlog?

Team VelocityTotal Point Estimate

For Stories = ==➔ Release Backlog FullWhen

Schedule-based Release Planning

Scope-based Release Planning

Maintaining the Release Plan

• Update the release plan at the end of each iteration, more frequently, if needed

• Good idea to hold release retrospectives at the end of each release

Story Mapping

Story Mapping

ITERATION PLANNING

Iteration Planning Overview

• Tactical. Answers the questions, “What are we building over the next 2-4 weeks?”

• Results in the iteration backlog

The Iteration Backlog

• Team collects the tasks in a Iteration Backlog• Similar structure to the Product Backlog• Team members sign up for tasks -- they aren’t assigned• Estimates are assigned to tasks by the team• Any team member can add, delete or change the IterationBacklog (tasks) during the iteration, as work for the iteration emerges during the iteration

Who Participates in Iteration Planning?

Facilitator Customer

Team

Scheduling the “What”

How Much Will Fit Into the Iteration?

Detail-level Planning: The “How”

Writing Good Tasks for Stories

SpecificMeasurableAchievableRelevantTime-Boxed

Task owner should be able to achieve a task.

Task should be relevant, contributing to the story at hand.

Task should be limited to a specific duration.

“Can we mark it as done?”

Task should be specific enough that everyone understands what’s involved.

The Commitment

Work (tasks, estimates, sign-up) can change during the iteration, but the Iteration Backlog (scope) is controlled by the delivery team once the team commits.

Definition of “Done”

● Defines the work to build an increment of potentially shippable product in that organization.

● Allows transparency, and with it trust between the stakeholders and the developers.

● Establishes a common set of expectations, which maximizes transparency, and fosters trust between the stakeholders and the Team

● Can be different for different Teams within an organization

ITERATION EXECUTION AND

REVIEW

Iteration Execution Overview

The Timebox

A timebox is a defined period of time, with non-negotiable start and end points. Timeboxing:

• Promotes a sense of urgency• Encourages focus• Provides a cadence, or rhythm• Allows for consistency in measures that are used for planning

The Iteration is Protected

Adding work

Interruptions

Shortening the iteration

Lengthening the iteration

Changing Team

Composition

Changing the definition of

“Done”

Who Does What?

Facilitator Customer

Team

Executing the Iteration

• Each day, complete the necessary work (analysis, design, code and test) to deliver the committed functionality at the end of the Iteration• Track progress each day in terms of:

•How many hours remain on the tasks?•What has changed since yesterday?•Who needs help?•Who can take on more work?•What is at risk?•What is accepted?

Team Space

Information Radiators: Task Board

Information Radiators: Burndown Charts

Information Radiators: Burnup Charts

Information Radiators: Cumulative Flow

The Daily Stand-up

Key inspect-and-adapt meeting that occurs every working day:• What have you accomplished since the last stand-up meeting?• What will you accomplish before the next stand-up meeting?• What obstacles are in your way?

Standup Meeting Takeaways

• Track daily progress on meeting the iteration commitment:•“Of our total estimated effort per task, 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?”

• Observations:•Estimates go down, but can stabilize or go up!•Tasks can be dropped or split•There is no priority in tasks other than what the team decides•Abnormalities should be reported in the stand-up meeting

Tips for Productive Stand-up Meetings

✓ Have the meeting at the same time and place every day✓ Ensure that only the Team speaks at this meeting✓ Use a “talking stick” to ensure participation and only one speaker at a

time✓ Alter the 3 questions slightly, if needed. For example. “What have you

finished since we met last?”, “What will you complete before we meet next?”

The Product Increment

The Product Increment is the potentially-shippable result of the incorporation of the iteration backlog with the pre-existing increment. The Product Increment :

• Meets the definition of Done• Has been accepted by the Customer• Is Valuable• Is potentially-shippable (is not pending testing)• Is the basis for the next Product Increment

The Iteration Review

• Takes place on the last day of the iteration – no delays• Precedes the next iteration planning Meeting• Purpose is to demonstrate backlog items that are done, and to allow the stakeholders to make informed decisions as to what needs to be built next

Tips for a Productive Iteration Review

✓ Set this up as a recurring, cadenced meeting, so that Stakeholders will already have this on their calendars

✓ Keep it informal – no slideshows or prepared speeches✓ Make sure the build under review is in an integrated environment (not on a developer’s

machine) to foster trust among the Stakeholders✓ Have the Customer facilitate the meeting, since he/she is probably closer to the

Stakeholders✓ Have the members of the Team who built and tested a feature demonstrate that

feature✓ Stream the meeting for remote attendees, and record for those who legitimately aren’t

able to attend

The Team Retrospective

• Inspect and adapt at the end of every iteration• Attended only by the 3 core roles• What went well, what could be improved• Team prioritizes improvements needed• Team chooses top 1-3 items and takes them on• “Inspect the Process -- not the People”

Tips for a Productive Team Retrospective

✓ Encourage Team Members to be candid, but respectful✓ Use visual-tactile devices to stimulate thought (e.g., affinity mapping with dot

voting, the Speed Boat game, etc.)✓ Keep in mind the objective of generating a plan of action to implement the

highest 1-3 improvements needed, with clear ownership of those items

Signs of a Dysfunctional Team

• Loss of Rhythm• Invasion of Meetings by People outside the Team• Missing Team Members• Persistent Bad Signatures• Facilitator Assigns Work• Daily Stand-Up Becomes the Facilitator’s Meeting.• Specialized Job Roles

5 Steps to a Retrospective

1. Set the stage

2. Gather data

3. Generate insights

4. Decide what to do

5. Close the retrospective

Adapted from Ester Derby’s book:

Agile Retrospectives: Making Good Teams Great

AGILE METRICS AND REPORTING

Traditional Metrics

• Not current• Not predictive• Not binary• Biased?• May not get reported

How Agile Metrics are Different

“Good” Agile Metrics

• Reinforce Agile Principles

• Measure Outcome, Not Output

• Follows Trends, Not Numbers

• Visual

• Right-sized, Easy-to-Collect, and Timely

• Conversation Starter

Common Agile Metrics: Velocity

Common Agile Metrics: Burndowns

Common Agile Metrics: Burnups

Cycle Time

Work in Process (WIP)

Tips for Managing Metrics

• Agile metrics are informative • Be sure that the value of collecting these measures outweighs the

costs. • Agile metrics should be presented in a way, preferably visual, that

elicit conversations and drive teams to ask, “What can we do better?”

• Agile metrics are lightweight and can be used by all parts of the organization to make timely business decisions.

• We should constantly inspect-and-adapt our metrics to ensure value, honesty, and transparency.

• When a metric loses its value, it should be lost. Once a metric is no longer needed or you ask yourself, “Why do we have this metric?”

QUALITY

How Agile Organizations View Testing

• The testers are part of the team (called “Team Members”, same as the people that write code or design the UI)

• Testing is continuous – not deferred to the end• Bugs don't accumulate – they're fixed as they are encountered• Quality is everyone's responsibility• Assuming a robust definition of “Done”, the code will have already been Unit

Tested and to some degree, functionally tested (automated), before a manual tester executes the first test case

Assuring Quality

Practice Quality Benefit

Collective Code Ownership Shared understanding of the system

Coding Standards Less chance of confusion, leading to errors

Test-Driven Development (TDD) Every line of code is tested as it is written

Pair Programming Real-time code review and error checking

Source Control Avoid overwriting each other’s changes

Automated Build & Integration Quickly find out if new changes break the build

Automated Testing Quickly test new changes, without manual testing

RISK MANAGEMENT

Managing Risk Through People & Process

Risk Agile ResponseCustomer won’t be happy Customer inspects results every iterationAll features won’t be completed The backlogs are prioritized for value

Estimates will be wrong Small features; relative estimation Overcommitting Planning based on the observed velocity trend

Changing requirements Allowed, between iterationsNew/Added requirements Allowed, between iterationsMissing the delivery date Time-boxed iterations and projectsGetting into a “death march” Time-boxed iterations and projects

“Resources” not available Stable, cross-functional teamsQuality will be poor Quality is managed daily; risk-adjusted backlog

Managing Risk Through Engineering

Practice Risk Management BenefitCollective Code Ownership No knowledge silos

Coding Standards Less chance of confusion, leading to errors

Test-Driven Development (TDD)

Every line of code is tested as it is written

Pair Programming Real-time code review; knowledge transfer

Source Control Avoid overwriting each other’s changesAutomated Build & Integration

Quickly find out if new changes break the build

Automated Testing Quickly test new changes, without manual testing

Scrum with Legos

Starlings

http://starlings.mp4

Course Wrap-up

Q&A

Class Retrospective

Please take 2 minutes to provide your feedback using the following link:

https://www.surveymonkey.com/s/7PZSQSJ

WRAP-UP

Agile Bootcamp - Sketch Development...

Documents

Transcript of Agile Bootcamp - Sketch Development...