Agile with Rational

®

IBM Rational Software

© 2010 IBM Corporation

Agile with Rational

Bartosz ChrabskiIBM Rational IT Professional


2

Agenda

Introduction

Core Agile Development – living Scrum with RTC

Scaling up Agile

Disciplined Agile Delivery - Agile in an Enterprise context

Agility@Scale – dealing with scaling factors, beyond traditional

Agile

Summary and Conclusions


Agile Methodologies or Religions?

•Scrum

•by far the most widely adopted

•Out of the box support in RTC

•Feature Driven Development

•XP

•Fairly narrow, development-

focused but also useful

•RUP

•Tackle risks up front

•Be iterative and adaptive

•Our position is to defuse the

religious/brand name debate and

focus on the practices


4

Our Practices – the Jazz Way

milestones

first

API

first

end

game

retrospectives

always have

a client

continuous

integration

community

involvement

new &

noteworthy

adaptive

planning

continuous

testing

consume your

own output

component

centric

drive with

open eyes

validate

reduce stress

learn

enable

attract

to latest

transparency

validateupdate

dynamic

teams

show progress

enable

explore

validate

live

betasfeedback

sign

off

common agile practices

common Open Source practices

scaling-up practices Our unfair advantage


5

Agenda

Core Agile Development – living Scrum with RTC

Scaling up Agile



Agile


* Most content thanks to Scott Ambler and Jean-Yves Rigolet…


Core Agile Development

Focus is on construction

Goal is to develop a high-quality system in an evolutionary,

collaborative, and self-organising manner

Value-driven lifecycle with regular production of working software

Small, co-located team developing straightforward software

Disciplined Agile Delivery

Extends agile development to address full system lifecycle

Risk and value-driven lifecycle

Self organisation within an appropriate governance framework

Agility@Scale

Disciplined agile delivery and one or more scaling factors applies:

Team size, GDD, technical complexity, org. complexity, …

Agile Scaling Model (ASM)

6


7

Core Agile Development

Core Agile

Development


Example Team: Rational Team Concert for Z/OS

DevelopmentBeijing, China

DevelopmentPornichet, France

Mgt, DevelopmentRaleigh, US

UASan Jose, US

DevelopmentAustin, US

Arch, DevelopmentParis, France

DevelopmentPerth, Australia

ResearchHaïfa, Israel

Rational Team Concert

SCM

Work Items

Build

3

4

2

6

103

8

1

37 developers


9

Our (old) Pain Points… joining a team

get my environment configured to be productive

what is happening in my team

collecting progress status

following the team‟s process

ad hoc collaboration/sharing of changes

starting an ad hoc team

is the fix in the build?

run a personal build

tracking a broken build

why is this change in the build?

reconstructing a context for a bug/build failure

interrupting development due to a high priority bug fix

working on multiple releases concurrently

tracking the code review of a fix

referencing team artifacts in discussions

how healthy is a component?

collecting project data/metrics?

keeping plans up to date

Boring and painful

Team

awareness

Build

awareness

Project

awareness


Drinking our own Champagne

• RTCz development project

– Self hosting on System z

• Access from Jazz.net

– „RTCz for System z Project‟

– Iterative, based on the Scrum template

• Geographically Distributed Development team

– 4 main Scrum teams

• RTP (Raleigh, US)

• FASL (France & Australia)

• BF (Austin, US)

• UA (San Jose)

• 2 parallel development lines

– No code maintenance

– Main development

• Release v2.0

• Post v2 development

– Product Delivery


Scrum applied

•RTCz development process

•Based on the standard Scrum process template

•Roles: Stakeholder, Product Owner, Scrum Master, Team Member

•Artifacts: Work Items, Product Backlog, Sprint Backlogs

•Minor process adaptations

•New role: PMC (Project Management Council- based on Stakeholder role)

•New Minutes work item

•Updated permissions

•PMC can update Plans

•Limited operations for externals

•New automatic tasks when joining a team

•[Joining a Team] Update your calendar with your Scheduled Absences

•[Joining a Team] Update your Work Environment


Sprint planning detailed

First days of each Sprint

Sprint directions from Product Owner

Analyze Stories with the Architects

All Scrum team members are involved

1 Sprint planning per Scrum team

Check time budget

Verify absences in RTCz

From Product Backlog...

Query Work items

Team members try to fully understand User Stories with the help of the Architects

Give estimates using the Planning Poker technique

...To Iteration Plan

Fill Sprint backlog with selected Stories based on team velocity and priorities


Continuous Integration Rational Build Forge

Rational Team Concert Daily builds are a good start

Agilists update and test their code

constantly

Therefore they need to build the system

constantly

Compile

Regression testing

Static code analysis

Critical points:

Must be automated

Don‟t forget database integration

Need a protocol for automatically deploying builds to higher-level sandboxes

Doesn‟t mean that you‟re deploying into production every 2 weeks


Share & build source codeIntegration

Streams and

flows

Build definitions

Source code

Components

Pending updates

Build results


15

RTCz V2 Development Rhythm

Monthly Sprints

9 iterations

Initial iteration (training, envt set up,...)

5 development iterations

All Sprints include FVTs

End-game & Cleanup

3 phases in all development iterations

Planning (2-3 days)

Development

Stabilization (3-4 days)


16

Test/Behavior Driven Development (TDD/BDD)

Add a test

Run the tests

Make a little

change

Run the tests

[Fail]

[Fail]

[Pass]

[Development

stops]

[Development

continues]

Rational Build Forge


Rational Application Developer

Automated acceptance testing drives your detailed requirements efforts

Automated developer testing drives the detailed design of the system

Tests form the majority of your detailed specifications

You‟ll still need some high-level models to provide overviews

This is the first time in IT history that developers are motivated to keep the specifications up-to-date

An example of single sourcing information


17

Agenda

Scaling up Agile



Agile


* Most content thanks to Scott Ambler and Jean-Yves Rigolet…


18

What is disciplined agile delivery?

Disciplined agile delivery is an evolutionary

(iterative and incremental) approach that

regularly produces high quality solutions in a

cost-effective and timely manner via a risk and

value driven lifecycle.

It is performed in a highly collaborative, disciplined,

and self-organizing manner within an appropriate

governance framework, with active stakeholder

participation to ensure that the team understands

and addresses the changing needs of its

stakeholders.

Disciplined agile delivery teams provide repeatable

results by adopting just the right amount of

ceremony for the situation which they face.

“Fits just right” process

Continuous testing and validation

Consistent team collaboration

Rapid response to change

Ongoing customer involvement

Frequent delivery of working solutions

Core Principles


The disciplined agile lifecycle: An extension of Scrum


20

Agile Requirements ManagementRational Team Concert

Rational Requisite Pro

Rational Requirements Comp

RMC Practices: Requirements Management, Use-Case Driven Development

Requirements are prioritized

by stakeholders

Requirements are estimated

by the development team

Requirements will evolve

throughout the project

Stakeholders see working

software each iteration

Stakeholders can change the

level of funding as appropriate

Stakeholders determine when

“enough is enough”

Rational DOORS


21

Agile Model Driven Development (AMDD) Rational Design Tools

Rational Requirements CompRational Requirements Composer

RMC Practices: Shared Vision, Evolutionary

Architecture, Evolutionary Design, TDD,

Component Software Architecture


22

Domain Complexity

Straight-forward

Intricate,emerging

Compliance requirement

Low risk Critical,audited

Team size

Under 10developers

1000‟s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

HomogenousHeterogeneous,

legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

Agile scaling factors

Disciplined Agile

Delivery

Flexible Rigid

Organizational complexity


23

Geographical Distribution

Distributed teams

Increase communication risk

Increase risk of delivering the wrong

product

Leverage people in disparate locations

Require greater discipline

Require improved tooling

Best practices

Initial architecture envisioning

Invest in travel

Invest in communication/collaboration

technologies



Rational Method Composer

Rational Requirements CompRational DOORS


Collaborate using Work items and Plans

Instant collaboration /

share context

Various levels

of work

planification

Discuss/exchange

work with

members


25

Team Size

Large teams

Increase management complexity

Increase communication overhead

Best practices

Initial architecture envisioning

Architecture drives team organization

Architecture ownership team

Program management team

Stakeholder team

Requirements management


Rational Method Composer

Rational Asset Manager


Rational Quality Manager

Rational DOORS


Check the project status & health

Burndown

charts

Various

project health

dashboards

Team communication


27

Regulatory Compliance

Recognize that this is a reality for many

teams

Best practices

Read and understand the regulations

Automate as much as possible

Embed compliancy into your culture

Lean development governance


Rational Policy Tester


Rational DOORS


Integrating with existing Governance systems

Highly regulated industries require

strict control, auditability, archive…

Rigorous Change Management

Auditable builds, archives..

May require integrating with

existing CM, SCM, and Build

systems

Teams can do their daily work in

more agile tools and deliver to the

“mother ship” as needed

Bridges can be automated or

manual

Our example team does this with

our formal support system

Corporate

Repository

Scrum

Repo


29

Technical Complexity

Complex applications

Are the norm, not the exception

Legacy systems and data sources are often

less than perfect

Legacy asset owners struggle with agile

approaches

Best practices

Multi-disciplined teams

Multi-disciplined people – Generalizing

specialists

Code refactoring

Database refactoring

Iterative development

Continuous integration

Short iterations

Rational Design Tools


Rational Asset Manager

Rational Testing Tools



Rational DOORS


Managing Technical Complexity – Tracking Adoptions

The RTCz team builds on

the Jazz Foundation

Jazz Foundation

architectural changes and

API evolution need to be

coordinated across

adopters

The Jazz teams have

instituted formal Adoption

tracking


31

Agenda


Q&A


32

Agile does scale, and IBM Rational can help

In addition to the development practices of Scrum and other Agile

methodologies, Disciplined Agile Delivery practices can help

deliver complex software and systems in a repeatable and

predictable way.

Rational provides tools that support these practices.

Rational and our customers are using these tools to successfully

scale Agile in many different dimensions.

Delivering greater value

from your investments in software


33

© Copyright IBM Corporation 2010. All rights reserved.

The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM‟s sole discretion based on market opportunities or other factors, and are not intended to be a comm itment to future product or feature availability in any way.

IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.


34

Resources

Agile/Scrum

Agile Manifesto: http://agilemanifesto.org/

Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development

Wikipedia: http://en.wikipedia.org/wiki/Scrum

Scrum Alliance: http://www.scrumalliance.org/

Scrum Community: https://scrumcommunity.pbwiki.com/

Rational agile development: http://www-01.ibm.com/software/rational/agile/

IBM Rational Team Concert for System z

Jazz community: https://jazz.net/projects/rational-team-concert-z/

Articles & papers:

In tune with IBM Jazz and IBM Rational Team Concert entreprise development tools, by

JY. Rigolet: http://www-949.ibm.com/software/rational/cafe/docs/DOC-2943

Easier, faster collaborative development by globally distributed teams, series by R.

Radcliffe:

http://www.ibm.com/developerworks/rational/library/09/rationalteamconcertsystemzjazz1/in

dex.html

Drinking our own Champagne – In the concert of RTCz development, by JY. Rigolet:

http://jazz.net/library/presentation/393

http://agilemanifesto.org/

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

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

http://www.scrumalliance.org/

https://scrumcommunity.pbwiki.com/

https://scrumcommunity.pbwiki.com/

http://www-01.ibm.com/software/rational/agile/



https://jazz.net/projects/rational-team-concert-z/







http://www-949.ibm.com/software/rational/cafe/docs/DOC-2943





http://www.ibm.com/developerworks/rational/library/09/rationalteamconcertsystemzjazz1/index.html

http://www.ibm.com/developerworks/rational/library/09/rationalteamconcertsystemzjazz1/index.html

http://jazz.net/library/presentation/393

Technology

Agile with Rational