Rapid agile release flow

and the agile testing

Shirly Ronen-HarelAug 2010

249/653/0harel/-ronen-il.linkedin.com/pub/shirlyhttp://

shirly@agilesparks.com

• The following presentation will describe a

short flow of daily uploads to production

environment while the sum of those daily

uploads results with a business and customer

release, While The testing in this case is

manual regression tests, no automation tests

exists yet.

• This is an agile team solution for dealing

with on going releases to production of

PSP’s while at the same time not released to

an end customer.

• This may fit companies working with internet

products which PSP’s must be released on

a short period of time basis and autometion

regression tests having a low coverage of

product functionality.

• Some of the rapid release flow may fit to

an internal customer tools development or

any product development.

• We are distinguishing between a daily upload

of PSP (potentially shippable product) and

a final release to customer use.

Production change request

Business release

Station- Customer release

The company holds three types of release :

1. CR :Production change request of user stories group: Release from development to production

environment:

• This is a process that is managed on a day to day basis where potentially shippable products (PSP’s)

are integrated into the code main trunk and uploaded into the production environment

• It does not mean that they are released or open to users use yet

• These small releases allow continues functional integration into the production environment without

overload users or internal customers with new frequent changes.

• Each production upload is managed as a production change request as a part of the change

management process in the organization

1. A business Release

• Milestone (sometime periodical sets of milestones) where the product organization decides to issue a

business release containing the PSP’s (potentially shippable product) that were uploaded to

production so far.

• From this point on , no new features will enter into the customer release..

• Internal customer acceptance tests can begin .

1. Station - Customer release

• a frequent small release to customer , that has a name and a number , , which was developed for

few iterations(1-3) and has a millstone and ETA for release to customer/users use.

• It is usually part of a bigger version release.

• This release is prepared for some time , including relevant marketing materials and training for users

.

CR – (user stories group) Agile development team uploads PSP’s to production , sometimes on a daily basis. This process is managed as change request process of production change control.

R – business release takes the entire CR’s so far uploaded to production and close them to a release not yet release to customer. Development and upload of CR continues but will be integrated to the next R.Customer related tests /pilot may begin at this stage.

S - Customer release:The product is release to customer including documentations and all preparations the business needed to do in order to be able to prepare customer for a quality release.

Uploads of PSP to production demands the architecture ability to

split between production and customer releases.

Release/CR/Stations

No customer releases (s) is allowed between stations (s).

There can be many CR’s released during the iteration (with a quality

definition of done)

Sometimes there are delays in delivery of business features to the R

milestone.

Once an agile team miss those R milestones ,with features to be

released , those features will be moved to the next R station.

User stories (US) Freeze

No new user stories can enter (unless major exception is required) a Sprint/Iteration

after the planning session is set and team commits to sprint goals and

artifacts.

Business release Customer release

US freeze US freeze US freeze

Code Freeze

Code freeze is set before any CR or PSP

US freeze US freeze US freeze

Backlog user stories Freeze and code Freeze

According to team WIP, Team should work on top n` user stories only.

Other user stories , that are in the backlog ,are not yet coded . They

are Only elaborated and acceptance criteria are defined.

Top 3 (n) user stories freeze

Working on top

user stories

Once a user story is

developed (and done) , the

team is allowed to pick up

the next user story and code

it (obviously- including

testing).

The next in line user story ,

ready with acceptance

criteria is entering the list

of top n worked user stories.

1

2

User Story Code Freeze

Just before a user story is done, team freeze code , and

regression tests starts(Manual tests).

User Stories Quality Tests

Each user story is

tested for its tasks,

its functionality and

with other user

stories for a group

regression tests, As

part of a mini

hardening tests

phase.

Release End Game Tests

Before business release (R) the team will perform the end game tests ,

packaging and final quality verifications.

Business release Business release

US freeze US freeze

Freeze

•Product manger is Responsible

for the product plan.

•PO : Product owner preparing

release and sprint backlog.

•Scrum team : ‘Development and

testing’ is responsible for quality.

•Code freeze is a mutual decision

between Po and scrum team.

•Upload to Staging environment is

a mutual decision between PO,

Release manager and scrum team.

•Upload to production environment

is a mutual decision between PO,

product manager and Release

manger .

•Business release is a decision for

product release to make.

R&R

The company mature agile operation performs this

flow in a days<->weeks time farms. and it works!