proprietary & confidential — copyright ©2006 serena software, inc. a pragmatic approach to...

Proprietary & Confidential — Copyright ©2006 Serena Software, Inc.

A Pragmatic Approach to Agile Development

John Scumniotales

Vice President, Product Management

2 Proprietary & Confidential — Copyright ©2006 Serena Software, Inc.

Application Development Distilled

New applicationrequests

Enhancementrequests

Issues

Defects

New applications

Improved applications

Fixed applications

Killed applications

Vis

ual

ize

Def

ine

Des

ign

Dev

elo

p

Bu

ild

Tes

t

Dep

loy

Str

ateg

icT

acti

cal

Predicable project execution

Repeatable processes

Managed software artifacts


Application Development Distilled

New applicationrequests

Enhancementrequests

Issues

Defects

New applications

Improved applications

Fixed applications

Killed applications

Vis

ual

ize

Def

ine

Des

ign

Dev

elo

p

Bu

ild

Tes

t

Dep

loy

Str

ateg

icT

acti

cal

Predicable project execution

Repeatable processes

Managed software artifacts… so all this process stuff is just a means to an end, NOT

the end in and of itself!

… we need to do this as efficiently as possible to maximize the value we can return to the business …


Traditional methodologies

Document driven Hand-offs between stove-

piped groups Manage scope creep, resist

new requirements Late changes at high cost Poor stabilization

predictability

System Requirements

Analysis

Requirements Analysis

Preliminary Design

Detailed Design

Code and Unit Testing

Integration & Acceptance

Testing

Installation and Turnover

Operation and Maintenance

Products

Rework

The Waterfall Chart

W.W. Royce, 1970


Agile Origins - The need for speed

In the early 90s, Object-orientation and Rapid application development environments emerged• Smalltalk, then Java and C#• Environments enabled rapid development, prototyping, and

refactoring• Design embodied in the code

Development could far out pace planning and testing processes

We either slow development down, or figure out how to keep pace

And then came the internet bubble and internet time


Emergence of agile approaches

Traditional software development approaches• Waterfall• Spiral• Incremental

Most assume that requirements are known and locked prior to design and development• Controlling change is desirable

Agile has emerged in environments where this was not possible or appropriate• Change is encouraged


Agile methodologies

Adaptive Software Development (ASD) Crystal Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Feature-Driven Development (FDD) Scrum Rational Unified Process (RUP) Test-Driven Development …


What is “agile development”?

An umbrella term that describes software development methodologies that share some/all of the following characteristics

http://agilemanifesto.org/


Are you agile?

Cross-functional teams that include the customer (or their proxy), development, test, and others

Automated and unattended build, test, and reporting that runs at least every night

Incremental approach that produces production quality capabilities at regular intervals

Test-driven development that puts quality first


The Agile Team

Cross-functional• All disciplines required to produce the product are on the

team• Involved from conception to launch• Equal treatment and respect for all

Roles• Project Manager / ScrumMaster• Product Owner• Developers• Testers• Writers• …


An agile development approach

Ongoing business and strategy activities

Definition & Construction

Launch

Conception

ReleaseCommit

RTM

Sprint 0 Sprint 1 Sprint N-2 Sprint N-1 Sprint NSprints 2 through N-3

Demo Demo Demo DemoHigh-levelplanning

Requirements Elaboration

Development & Test





Launch

Conception

ReleaseCommit

RTM




Development & Test


Conception

Initiated through ITIL/CAB, PMO or ad-hoc processes• Internally generated requests• Customer driven• Market driven

Describe what your doing and why your doing it• Customer need and/or market assessment• Business case• High-level use cases and requirements• MRD-level information• Level of formality will vary based on value/cost of the request

Typically involves formal approval processes Evangelize project (post-approval) to stake-holders, customers, and

prospects


An agile development process



Launch

Conception

ReleaseCommit

RTM




Development & Test


Definition and Construction – “Sprint 0”

High-level planning and estimation High-level backlog created from Conception deliverables Backlog is reviewed and evaluated for achievability When to use a Sprint 0?

• Long multi-release development cycle

• Significant post production activities need to be planned e.g. Marketing launch


Definition and Construction – “Sprint 0”

Each backlog item is prioritized and estimated• High-level estimates (+/- 50% accuracy)

Resource capacity plan is developed for the project Effort is compared to resource capacity and an initial

burndown is projected At the completion of Sprint 0, a Sprint review is

performed for final project approval and kick-off of the next Sprint


Example Project Backlog


Resource Capacity and Allocations


The Project Burndown


Incremental Planning

Incremental planning starts now Feature content, release targets, capacity are

continuously reviewed/discussed/debated by the project leads• Project Leads: ScrumMaster/Project Manager, dev & test

leads, product owner This is where the term Scrum came from

• At times, the process can be brutal, but in the end a try can be scored


An Agile Development Process



Launch

Conception

ReleaseCommit

RTM




Development & Test


Kicking-off a Sprint

Product Owner and team leads identify backlog items for the sprint

The backlog items are elaborated• User Stories

• Interaction design / screen flows Feature content, release targets, capacity are re-

calibrated by the project leads Sprint is kicked-off with a team meeting to review and

discuss goals


Identify Sprint Backlog Items


User Stories are elaborated


Interaction Design / Screen flows


Sprinting - Managing the work

User Stories drive development and testing• Developers use the to determine what to build• Testers use them to determine what to test

User Stories are be broken down into tasks• Task work remaining is determined by whomever owns the

task Refines User Story work remaining and increases overall

accuracy of the burndown• Therefore, the more user stories that are implemented the

more confidence we have with the target project completion Progress, status and impediments are discussed in the

daily stand-up


Define User Story tasks


The Developer Inbox


Sprinting – The Daily Stand-up

Team meeting every day at the same time in the same place

Everyone attends – Development, Test, Product Owner• Pigs and chickens

Led by the ScrumMaster (Project Manager) <15mins Each member quickly reviews new accomplishments,

next tasks, and raises any impediments• Impediments resolved offline!

Whiteboards – the more the better


Test-driven development

Initial goal: “Get something built and get it into maintenance mode”• Jeff McKenna

The eXtreme approach – Test first development• Tests are written by developers before the code• Serve as software design• Used to validate the implementation

Minimally, tests should be delivered with the code Overtime, a significant suite of unit and component level tests is

created• (1000s of individual tests)

Open source test harnesses rock• NUnit (Java), JUnit (C#) for component and unit testing• Selenium for web UI testing


What happened to Architecture & Design?

Architecture and design can evolve Modern (RAD) environments enable designs to be rapidly

realized in code• Refactoring features enable exploration of alternative

approaches• Test-automation enables rapid application regression

testing

Mini-specs for high-risk, complex features The architectural spike (Kent Beck) But… these artifacts are disposed of as soon as we

have operational code


Test + Automation = Courage

Implementing unattended automated builds and testing are critical success factors

Ideally, the application is completely rebuilt from source every night …

… and, UI, component, unit tests are run … … and, a report is generated and broadcast with test

results The build NEVER fails

With 1000+ tests supporting the team, design and even architectural changes can be made and immediately validated


What about traditional SQA?

Absolutely essential! They are imbedded in the team Test Plans built during initial scoping stages (Sprint 0) Test Cases derived directly from the User Stories Manual test cases executed during the sprint as features

are developed Also contribute to UI and code-level test automation


You gotta have rhythm!

Releases

Sprints

Feature Drops

Automation Cycles

Nested levels of agile rhythm


The Sprint Demo Meeting

Held at the completion of every sprint Closes the previous sprint, kicks-off the next sprint For the just completed sprint

• Demonstration of delivered features by the devs or testers who built them

• Review results and discuss any changes to planed scope For the sprint about to start

• Review planned features

• Review project burndown Ready to release?

• Are the key features ready?

• Product quality/stability?





Launch

Conception

ReleaseCommit

RTM




Development & Test


Are you agile?

Cross-functional teams that include the customer (or their proxy), development, test, and others

Automated and unattended build, test, and reporting that runs at least every night

Incremental approach that produces production quality capabilities at regular intervals

Test-driven development that puts quality first


Characteristics of agile teams Customer focused

• Customer (or their proxy) on the team• Embrace customer-driven changes

High-quality software• Test-first development• Paired programming

Maniacal focus on getting product built• Not on producing artifacts• Early continuous delivery

Verbal communication over documentation• Cross-functional teams

Incremental development• Deliver production quality code• High visibility and predictability

Rhythm and pace• Continuous builds• Automation obsession


Agile adoption challenges

Large distributed development teams Outsourced projects Organizational change management Situations where the customer is not a directly involved

with product development Shrink-wrap products with thousands of customers


How to institute agile in your shop

Get Help!

• If you don’t have agile experience, get an expert Start small

• Find a reasonably sized project with limited external dependencies

Get 360 degree buy-in

• Your boss, piers, and subordinates

• Initial successes will help If your environment is stable, predictable and controlled, then why

bother

In the end, success will depend on the people


Serena Agile Product Support

Currently Available• TeamTrack accelerator for Agile/Scrum development

• Agile/Scrum project management support in Mariner 6.2

Future• Agile support for the enterprise

• Cross-product agile workflows

• More accelerator and feature content for agile development teams

proprietary & confidential — copyright ©2006 serena software, inc. a pragmatic approach to...

Documents