Zwinny rational

®

IBM Rational Software

© 2010 IBM Corporation

Zwinny Rational

Martin Stenkilde, CISSPIBM Rational Tiger Team Leader, CEE


2

Agenda Introduction

Core Agile Development – living Scrum with RTC

Scaling up AgileDisciplined Agile Delivery - Agile in an Enterprise contextAgility@Scale – dealing with scaling factors, beyond traditional Agile

Summary and Conclusions

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


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

milestonesfirst

APIfirst

endgame

retrospectives

always havea client

continuousintegration

community involvement

new & noteworthy

adaptiveplanning

continuous testing

consume yourown output

componentcentric

drive with open eyes

validate

reduce stress

learn

enable

attract to latest

transparency

validateupdate

dynamic teams

show progress

enable

explore

validate

livebetas

feedback

signoff

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 Disciplined Agile Delivery - Agile in an Enterprise context Agility@Scale – dealing with scaling factors, beyond traditional Agile




Core Agile DevelopmentFocus 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 DeliveryExtends agile development to address full system lifecycle

Risk and value-driven lifecycle

Self organisation within an appropriate governance framework

Agility@ScaleDisciplined 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

Teamawareness

Buildawareness

Projectawareness


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

Integration Streams and flows

Build definitionsBuild definitions

Source code ComponentsSource code Components

Pending updatesPending updates

Build resultsBuild results


15

Regular Deployment of Working Software

How many projects have you seen that: Were “90% complete” for

months? Delivered wonderful plans but no

software? Delivered wonderful models, but

no software? The only accurate measure of

software development is the delivery of software Deliver something at the end of

each cycle/iteration Iterations should be short At all points in time stakeholders

can see what they’ve gotten for their investment to date

Rational Build Forge


Rational Method Composer

RMC Practices: Iterative Development


16

RTCz V2 Development Rhythm

Monthly Sprints

9 iterations

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

5 development iterations

All Sprints include FVTs

End-game & Cleanup

Including SVTs, TVTs, GVTs

3 phases in all development iterations

Planning (2-3 days)

Development

Stabilization (3-4 days)


17

Test/Behavior Driven Development (TDD/BDD)

Add a test

Run the tests

Make a littlechange

Run the tests

[Fail]

[Fail]

[Pass]

[Developmentstops]

[Developmentcontinues]



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


18

Agenda

Scaling up Agile Disciplined Agile Delivery - Agile in an Enterprise context Agility@Scale – dealing with scaling factors, beyond traditional Agile




19

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” processContinuous testing and validationConsistent team collaborationRapid response to changeOngoing customer involvementFrequent delivery of working solutions

Core Principles


The disciplined agile lifecycle: An extension of Scrum


21

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


22

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


23

Concurrent, Independent Testing

Rational Testing Tools


Rational Quality Manager

Independent Testing

Const.Iteration…

Const.Iteration

TransitionIteration(s)

Effective agile teams push their working builds to an independent test team on a regular basis for investigative testing

Defects must be prioritized and put back on the team’s work stack

Defects == Requirements

Scales TDD: TDD is a form of confirmatory testing. TDD is a great start, but it’s not the full testing picture

Critical strategy for addressing non-functional requirements


Coordinate our tests in RQM

All defined in Rational Quality Manager

FVT, SVT & Performance Test Plans

Defined by developers

During the Stabilization phase

Executed by all members

Developers, release engineer, ..., and even managers

Test execution records

Creating Defects on execution failure

Formal reviews

Test cases approvals by Product Owner & ScrumMasters

Metrics & charts on quality presented at Sprint stakeholders meetings

Test case design

Test case design

Execution reportExecution report


25

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


Agile inhibitors – we can help overcome…


27

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 Requirements CompRational DOORS


Collaborate using Work items and Plans

Instant collaboration / share contextInstant collaboration / share context

Various levels of work planification

Various levels of work planification

Discuss/exchange work with members

Discuss/exchange work with members


29

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 Asset Manager



Rational DOORS


Check the project status & health

Burndown chartsBurndown charts

Various project health dashboards

Various project health dashboards

Team communicationTeam communication


31

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

IBM Rational SoftwareIntegrating 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 Repositor

y

Scrum Repo


33

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 AdoptionsThe 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


35

Agenda


…


Walker Royce’s Top Ten Agile Principles for Success1. Reduce uncertainties by addressing

architecturally significant decisions first.

2. Establish an adaptive life-cycle process that accelerates variance reduction.

3. Reduce the amount of custom development through asset reuse and middleware.

4. Instrument the process to measure cost of change, quality trends, and progress trends.

5. Communicate honest progressions and digressions with all stakeholders.

6. Collaborate regularly with stakeholders to renegotiate priorities, scope, resources, and plans.

7. Continuously integrate releases and test usage scenarios with evolving breadth and depth.

8. Establish a collaboration platform that enhances teamwork among potentially distributed teams.

9. Enhance the freedom to change plans, scope, and code releases through automation.

10. Establish a governance model that guarantees creative freedoms to practitioners.

http://www.drdobbs.com/architecture-and-design/222300750


37

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


38

© 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 commitment 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.


39

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/index.html

Drinking our own Champagne – In the concert of RTCz development, by JY. Rigolet: http://jazz.net/library/presentation/393

Technology

Zwinny rational