The Straight Jacket of Agile Iteration

Post on 14-May-2015

5990 Views

Category:

Documents

2 Downloads

Preview:

Click to see full reader

DESCRIPTION

My presentation on Agile Vancouver conference in 2011 As the goal of Agile evangelists was to convince people to switch from long Waterfall projects, the main message was to think small – short iterations, no upfront design, and requirements that fit on a card. This presentation explores limitations and pitfalls of a purely iteration focused approach and discuss different ways to address them while still retaining the speed and flexibility of the Agile approach.

Transcript

The Straight Jacket of Agile IterationMichael Vax

VP Engineering, Partnerpedia

About myself

• 30 years in s/w development• Developer, architect, manager, VP, CTO• Discovered Agile in 2005• Implemented Agile process in 4 companies• Involved in Agile Vancouver for last six

years• Currently - VP of Engineering at

Partnerpedia

Waterfall Agile

Large Small

The main goal of Agile’s evangelists was to prove that

small works

That required simplifications

Green field projectsCustomer on site

Development team can define deadlinesSimple designEasy to change

Agile = Iterations

Iteration – Focal Point of Go Small Message

Plan DemoImplement

Iteration n-1 Iteration n Iteration n+1

Disclaimer

I love iterations!!!I love iterations!!!I love iterations!!!

Horse Blinder Vision

Plan DemoImplement

Iteration

Are real-life projects and situations more complex than examples used in Agile books?

Are we missing the Big picture if we focus on iteration too much?

There is a life beyond iteration

Plan DemoImplement

Iteration n-1 Iteration n Iteration n+1

What needs to be done before

an iteration?

What needs to be done after the iteration?

How to see the big picture while staying Agile?

How to split time between work for current iteration and future planning?

Lean Concept of Flow And Optimizing the Whole

The goal of the development process is to optimize delivery of the business value

Requirements

Release

Investment Value

Design Dev TestIdea Product

Lean Concept of Flow And Optimizing the Whole

Requirements Release

Investment Value

Design Dev TestIdea Product

Can this happen in Agile?

Requirements

Sub-optimized Flow

Requirements Release

Investment Value

Design Dev TestIdea Product

If everybody is focused on the current iteration, who is preparing for the next one?

Ready-Ready to be Done-Done

The Product Owner is asked, “Are you ready-ready?” and the team is

asked “Are you done-done?”.

“When teams concurrently make work ready for next iterations during development, we find quite often

they can cut the iteration length in half”

Not all features are the same

Feature Characteristics

Minor • Done it many times• Can be assigned to almost anybody on the team• no room to misinterpret requirement

Small • Enhancement to existing feature• Minor UI changes consistent with previous implementations• No technical challenges

Medium • Enhancement to existing feature• Crosscutting multiple modules• Some level of technical uncertainty

Large • Completely new feature or re-architecture of existing functionality with functional enhancements • Unclear domain questions – is bundle a product?• Requires selection of new technology or design patterns• New UI paradigm

Paths to code ready stories

Small Feature

Medium Feature

Large Feature

User Story

Epic Epic

User Story

Epic

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

ReadyReady for Review

Initial Definition

Legend User Story

Minor Feature

User Story

User Story

User Story

User Story

User Story

User Story

Ready-Ready Epic

• Domain questions are identified and answered

• Usage scenarios are understood• Main UI flow is defined (mock-ups) • Core technical decisions are made and

validated

Code Ready Story

• Can be estimated by team in no more that 15 minutes

• Is unlikely to be stopped or canceled due to unclear requirements or technical challenges

• Tests are defined• Domain Changes are understood, reviewed,

and consensus reached• UI mockups are reviewed by both end-users

and designers

Metric to measure Ready-Ready• Flow in implementation of a story: Is story

implemented without breaks in calendar time and context shift?

• Example:Assume a story is 3 points story. However, for various reasons it becomes 9 points story.The flow in this case is defined as 3/9 or 33%

Optimize the flow!

Focus on NOW or look ahead?

Plan DemoImplement

Iteration n+2Iteration n Iteration n+1

Design & Architecture

No BDUF != NDUG (Big Design Up Front) (No Design Up Front)

Every system has an architecture

Sub-optimized Flow

Requirements Release

Investment Value

Design Dev TestIdea Product

We can always refactor later

Really?

Complex changes can takes weeks or even months to complete

High level architectural vision instead of detailed architectural Roadmap

Think About The Future But Don’t OverbuildLean Principle - (Defer Commitment)

Prioritization of Design Work

Consider Several AlternativesLean Principle - consider several

alternatives and to keep those alternatives "open" to us as long as they remain viable

Change Case Modeling

Description (A couple of sentences or a paragraph describing the basic idea)

Likelihood (Rating of how likely the change case is to occur (e.g. High, Medium, Low or %))

Timeframe (Indication of when the change is likely to occur)

Potential Impact (Indication of how drastic the impact will be if the change occurs

Use Spikes to separate research from Implementation

Not enough planning smells

• Difficulties with story estimations on iteration planning meeting• Complete change of technical directions in the middle of iteration• Inability to answer developers questions when implementation starts• Abandon and incomplete stories• Idle development team waiting for requirements

Testing

Most of s/w projects have not been developed with TDD

Test Strategy cannot be limited to an iteration

Regression & Manual Testing Have not Disappeared

Performance Testing in Agile Project

Iter.0 Iter.1 Iter.2 Iter.3 .... Iter.x-1 Iter.x

Benchmark Test Benchmark Test Benchmark Test

• Test environment setup• Tools selection• Performance requirements• Test data preparation

Focus Test Focus Test Focus TestFocus Test

• Load tests• Stress tests• Capacity testing• Resilience testing

Performance Testing and Iterations

Iter. n-1Feature A

Iter. nFeature B

Iter n+1

Feature C

Feature A• Test requirements• Test development

PerformanceSpike

Feature A - Focus test

Feature B• Test requirements• Test development

Feature B - Focus test

Feature C• Test requirements• Test development

Performance Testing - Agile Best Practices

• Put performance tasks on a SCRUM board• Make fixing functional bugs that block performance

tests a high priority• Do not delay fixing performance issues identified by

tests• Retest after fixes are applied to know if they worked• You cannot guess where the next bottleneck is• Don’t pre-optimize before testing

Business vs. Development

Business does not plan in iterations

Business needs a Date and Commitment

How to do business level estimations in Agile?

Units of Estimations

Leve

l of U

nder

stan

ding

Low

High

Months

Weeks

Days

Hours

Look at the Flow

Requirements

Release

Investment Value

Design Dev TestIdea Product

Make it Visual

Get a picture of wall from Partnerpedia

We don’t Operate in a Walled Garden

Coordinating Branches & Teams

External Dependencies

Customers, Partners,

Other Departments

Maintain long term vision but don’t focus on small

things when looking ahead

Plan DemoImplement

Iteration n+2Iteration n Iteration n+1

Find the Balance

Questions?

Getting in touch:Email: Michael.vax@gmail.com

Twitter: michaelvaxLinkedIn: http://ca.linkedin.com/in/michaelvax

top related