Upmc tpdev1

© 2012 IBM Corporation
Jean-Yves B. Rigolet
IBM France Lab
rigolet.j@fr.ibm.com
Module NI514
En route pour une transformation agile des
équipes de développement
UPMC STL M2 – 2016/2017

2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
2
‘Software development is hard’
Grady Booch

2016
TPDEV
3
Agenda
Evolution of software delivery
Agile software development
Scrum & scrum smells
Agile pratices: TDD & CI
Scale & govern software delivery

2016
TPDEV
4
Traditional/Waterfall Development Model
 Models the development process as
moving from one step to the next.
 Delays confirmation of critical risk
resolution
 Measures progress by assessing
work-products that are poor
predictors of time-to-completion
 Delays and aggregates integration
and testing
 Frequently results in missing targets
or unused features/products
Code & Unit Test
System Test
Integration Test
Design Requirement
Requirements Def
Concept Definition
Development proceeds sequentially through a series of phases
Acceptance Test
Deployment
Maintenance

2016
TPDEV
V-Model
Extension of the Waterfall model
Coding is central
Meticulous design, development,
and documentation
Often view as too simple, giving a
false sense of security
Like the Waterfall model, It is
inflexible, offering no way to
respond to change
Testing comes late & too tight to
design
Coding
Requirements
Analysis
High Level
Design
Detailed
Specifications
Unit Testing
Integration
Testing
Operational
Testing

2016
TPDEV
6
Realities can stall software delivery
Complexities in software delivery compounded by market pressures
2010 Spending in U.S. on governance,
risk and compliance was $29.8 billion
Increasing
Mandates
62% of projects fail to meet
intended schedule
Unpredictability
in Software Delivery
50% of outsourced projects
are expected to under perform
Globally Distributed Software
and Product Supply Chains
Complex, Multi-platform
Systems and Applications
62% of companies have agile projects
requiring integration with legacy systems
30% of project costs are due to rework
and poor execution of requirements
Changing Requirements
and Time to Market
Cost
Reduction
70% budget locked in maintenance and
37% of projects go over budget
Source: Numerous sources, see speaker notes for details

2016
TPDEV
Coding
So, let's look at the V-Model again
What if?...
Requirement
s Analysis
High Level
Design
Detailed
Specification
s
Unit Testing
Integration
Testing
Operational
Testing

2016
TPDEV
Coding
… We change the way we work
Requirement
s Analysis
High
Level
Design
Detailed Specifications
Unit Testing
Integration
Testing
Operational
Testing
Goal is to reduce risks & costs while delivering better quality software

2016
TPDEV
9
Agile Manifesto www.agilemanifesto.org
February 11-13, 2001, The Lodge at Snowbird ski resort

2016
TPDEV
10
Agenda

2016
TPDEV
11
Agile software development applied
“Uses continuous stakeholder feedback to deliver high-quality,
consumable code through use cases (user stories) and a
series of short, stable, time-boxed iterations.”
This figure shows the "Four S's" that describe agile in a nutshell.

2016
TPDEV
12
Agile Basics
 Agile value-add focuses on:
– Delivering business value early and often in a project lifecycle
– Being able to incorporate requirements as they emerge and are identified as
valid
– Providing frequent delivery of new deployable business value (workable code)
– Leveraging tight, self-organizing teams
– Incorporating customer feedback early in the development cycle
 All of these create an environment that can sustain itself over time
rather than experience the peaks and valleys of the traditional
methods, which ultimately tire employees and lower overall quality.
Change should not equal crisis!

2016
TPDEV
13
What Agile software engineering is not...
A waterfall
A Big Bang with limited intermediate opportunities for stakeholder
interaction, code convergence typically late
Rigid, with change requests often viewed as interruptions
Individualistic
Document, process, or design heavy
Plan driven
A trivial cultural transition for many teams
A fad
A silver bullet

2016
TPDEV
14
What Agile software engineering is...
Iterative, typically time-boxed as short iterations
About frequent, sometimes constant, validation with stakeholders
Highly focused on mitigating risks
Adaptive; comfortable with-and even embracing-change and reprioritization
Open (communication, code, process, and so on); a team sport
Communication-intensive (for example, daily Scrums)
Suspicious of non-code artifacts
Aimed at making incremental progress: working software is the measure
Deliberate about reflecting on what works and what does not
Disciplined, scalable, and even workable across sites

2016
TPDEV
15
Agenda

2016
TPDEV
16
What is Scrum?
An agile software development framework
–Structured in cycles of work called Sprints
• iterative work
• team pull from prioritized customer requirements (User Stories)
• produce a potentially shippable
A simple framework
–3 roles
• Product Owner,
• ScrumMaster,
• and the self-organized team
–3 ceremonies
• sprint planning meeting,
• daily scrum meetings,
• and sprint review meetings
–3 artifacts for prioritizing and tracking tasks
• product backlog,
• sprint backlog,
• and a burndown chart
A piece of cake?...

2016
TPDEV
17
The Scrum roles (1/2)
Product Owner
–Represents the voice of the customer
–Writes user stories, prioritizes them
–Places stories in product backlog
ScrumMaster (or Facilitator)
–Scrum is facilitated by a ScrumMaster,
–Ensure team is functional
–Remove all team impediments to deliver
–Buffer between team and influencers
–Ensure Scrum process is used as intended
Team
–Self-organized
–Responsible to deliver the product
–Made up of 5-9 people with cross-functional skills to do the actual work
Pigs are the ones committed to the project and the Scrum process

2016
TPDEV
18
The Scrum roles (2/2)
Users
–Users of the software being built
Stakeholders (customers, vendors)
–Enable the project & for whom the
project will produce the agreed-upon
benefit(s) which justify it
–Provides feeback
–Involved in reviews
Managers
–People that will set up the environment
for the product development
organizations
Chicken roles are not part of the actual Scrum process,
but must be engaged and provide feedback

2016
TPDEV
19
The Product Backlog
Owned and Prioritized by the Product Owner
Created with Stakeholders and the Delivery Team
Contains the potential work for this release
–Features, Development requirements, Exploratory work, Known bugs
Articulates the product vision
Ideally expressed such that each item shows value to the
customers or users of the product
Contains user stories at both Epic and detailed levels
Is a living list, changes over the course of the release
Is assessed and reprioritized every iteration

2016
TPDEV
20
Dynamics of a Product Backlog
Each Sprint (or Iteration)
is made up of small
automatable chunks
called User Stories
The Product Backlog
holds all the User Stories
until they are ready to be
implemented in a Sprint
 Once selected by the
team to go in a Sprint, a
User Story goes into a
Sprint Backlog

2016
TPDEV
21
User Stories detailed
A concise, written description
of a piece of functionality
that will be valuable to a software stakeholder.
As a <role>, I can <goal> so that <business value>

2016
TPDEV
22
Where User Stories Help
Value to stakeholders
–Stories target functionality valuable to stakeholders
–Story demos each iteration keeps stakeholders engaged
Simplified features
–Stories enable light-weight requirements gathering, progressive discovery
–Stories focus on feature essentials
Estimated by the team using story points
Release predictability
–Stories by definition fit in time-boxed iteration
–Stories that fail in an iteration provide early warning system
–Cadence of story completion over multiple iterations will demonstrate
release predictability

2016
TPDEV
23
Why use User Stories?
Right size for planning, works for iterative development
Defer detail until you have the best understanding you are
going to have about what you really need
Focus on user goals rather than feature attributes
Emphasize verbal rather than written communication
–Fixes many issues with “vague requirements”
Comprehensible by both you and the dev team
Stories support evolutionary development

2016
TPDEV
24
User Story Roles
As a <Role>, I want to <Goal> so that I can <Business value>
User role is a collection of defining attributes that characterize a
population of users and their intended interactions with the
system*.
–Avoid “the user”; different stakeholders have different requirements
–Mike Cohn recommends using roles so that you do not “miss” stories
–Teams can develop a set of user roles (personas) to help define relevant
stories
Examples
–As a ClearCase CTO I want Access Control Lists on all my common
objects to provide critical security to my confidential information.
–As a Jazz Admin I want to bulk modify Access Control Lists for multiple
objects to enable security updates for 1000 objects with 2 clicks.
*Source: Software for Use by Constantine and Lockwood
(1999)

2016
TPDEV
25
User Story Goals
Goal is “what the user role can do”
–Valuable to a stakeholder
–Epics – less specific about the what
–As stories are broken down, the details of what will be delivered
becomes clearer
Examples
– As a BuildForge Administrator I want BuildForge to be able to use virtual
machines for running jobs so that I can maximize the use of my infrastructure
– As a BF Admin I want to identify VMs in the server panel so that I can use existing
VM servers
– As a BF Admin I want a configuration for a static server manifest so that I can
configure VM servers without starting them

2016
TPDEV
26
User Story Business Value
Business value justifies the value of the story
–Clarifies why a feature is useful
–Can influence how a feature should function
–Helps prioritize the story in the backlog
Why the “so that” Phrase Matters
–As an IT manager I want my Enterprise Content Management system to
be represented as a library in the Windows Explorer interface
–…so that it works with existing Windows applications on my users
desktops?
–…so that it looks like another repository in the Explorer Interface?
–…so that I do not have to train my users to use a new interface?
The real business value requested by the IT departments told
us how to build the interface

2016
TPDEV
27
Overview of the Scrum process
Product Owner
provides
prioritized Stories
Team estimates
Stories
Team moves
Stories to Sprint
Product Owner
sets Sprint goal
Team exchanges
progress in Daily Scrum
Team produces
shippable increment
Team breaks
Stories into Tasks
Team reassesses estimates
‘Chickens’ give
feeback
Team analyzes
Sprint during
Retrospective

2016
TPDEV
28
The Sprint planning meeting
Goal is to get everything ready for the
Sprint
Team meeting
–But stakeholders can silently assist
Filling the Sprint backlog
–The Scrum team takes stories from the Product
backlog
–Break stories into tasks
–Give estimates
The planning poker technique
–All team members simultaneously provides
estimates
–High and low estimators briefly explain why
–Repeat 3-5 times until estimates stop converging
*Planning Poker® Cards
*image from http://store.mountaingoatsoftware.com/

2016
TPDEV
29
Scaling using Scrum of Scrums
Scrum is a good fit for both large and small
teams
Need to add a second level if:
–Several interdependent Scrum teams that need to
communicate
–Several teams working together on a single product,
with inter-dependencies.
Indefinitely scaled through multiple layers
Frequency & presence determined by the team
–Technical contributor
–No need of Product Owner or ScrumMaster, but they
can assist
Are you about to put
something in another
team’s way?

2016
TPDEV
30
Burndown Chart
Burndown charts quickly determine if an
iteration is on track
Accessible to the team
Track work daily during iteration
–Indicates whether or not iteration on track
–Adjust if iteration off track
–Useful in scrum meetings
In practice…
–Burndown will not reach an ideal line
• Work finishes sooner than planned, takes
longer than planned
• More tasks are added, some are
removed,...
–Goal is to handle deviations from the
burndown line

2016
TPDEV
31
Scrum preparation steps for success
• Ready…
 Get right people on board & the Scrum roles filled
 Fill product backlog & prioritize stories
 Development and test environment are ready
 Team knows how to transfom product stories into shippable product
increments
• Steady…
 The team estimates the product backlog items
 The product owner identifies a sprint goal and discusses the related
product backlog items with the team
 The team determines its availability
 The ScrumMaster prepares the meeting
• GO!
 Project set-up for success
 First sprint planning meeting can start now

2016
TPDEV
32
Scrum projects can fail
• Failure
– From Wikipedia, the free encyclopedia
« Failure (colloquially fail, phail or flop) in general
refers to the state or condition of not meeting a
desirable or intended objective. It may be viewed as the
opposite of success. Product failure ranges from failure
to sell the product to fracture of the product, in the worst
cases leading to personal injury, the province of
forensic engineering. »
So you need to quickly identify Scrum Smells...

2016
TPDEV
33
Some reasons Scrum projects can fail (Scrum Smells)
Not Acting Like a Team
Talking Chickens
Missing Pigs
Status not clear from Daily Scrums
Lack of Progress
Persistent Signatures
ScrumMaster Assigns Work
The Daily Scrum is for the ScrumMaster
No One Wants to Attend Retrospectives
Executive Pressure
Specialized Job Roles
Testers will not integrate with Team
Team takes complete responsibility for
testing
Reluctance to estimate Backlog Items
Is It Really Done?
Nothing Ever Gets Better Around Here
Consistently Missing Sprint Commitment
No Engineering Practices
Gorilla in the Room
Technical Debt
Let's detail some smells...

2016
TPDEV
34
#1: Not Acting Like a Team
• Fixed Roles
• Tasks are assigned
• Not helping each other
• No mentoring is going on
• Stories aren't shared and all work is being
done in parallel
• No cooperation
• Not listening to (and talking over) one and
another during meetings
• No Laughter - a team that is working well
together often laughs

2016
TPDEV
35
#1: Not Acting Like a Team
• Fixed Roles
• Tasks are assigned
• Not helping each other
• No mentoring is going on
• Stories aren't shared and all work is being
done in parallel
• No cooperation
• Not listening to (and talking over) one and
another during meetings
• No Laughter - a team that is working well
together often laughs
 Lead by example, mentor and help
team members with their tasks
 Breakdown silos and fixed roles
 Help change the Corporate structure
to reward team work and not heros
 Encourage pair programming, code
reviews and other practices that
increase co-operation and
communication
Scrum projects gain
efficiency from the Team as a
whole
Example
Remedies

2016
TPDEV
36
#2: Talking Chickens
- animated -
 Stakeholders talk in Daily Scrums
 Features selected outside of sprint
planning meetings
 Team cannot make purely technical
decisions without an outsider’s
blessing
 Status reports are required outside
sprint planning meetings
 Executive sponsors try to influence
the team
 Product backlog languishes or is
ignored

2016
TPDEV
37
#2: Talking Chickens
- animated -
 Stakeholders talk in Daily Scrums
 Features selected outside of sprint
planning meetings
 Team cannot make purely technical
decisions without an outsider’s
blessing
 Status reports are required outside
sprint planning meetings
 Executive sponsors try to influence
the team
 Product backlog languishes or is
ignored
 Consistently enforce the no talking
rule
 Conduct training as part of project
start
 Negotiate rules at project start
 Use retrospectives to reinforce
expectations
 Move chickens away from the pig pen
 Change the meeting time and place
 Maybe the chicken can lay an egg
 Become a barnyard dog
Scrum member living the pain
of a bad technical decision
vs.
outsiders who feel compelled
to make decisions for a team
Example
Remedies

2016
TPDEV
38
#3: Missing Pigs
• Unclear expectations?
• Competing assignments?
• Lack of commitment?
• Supervisory interference?
• Weariness?
• Fear?

2016
TPDEV
39
#3: Missing Pigs
• Unclear expectations?
• Competing assignments?
• Lack of commitment?
• Supervisory interference?
• Weariness?
• Fear?
 Role model
 Change meeting time and location
 Explanation, persuasion, and
negotiation
 Embrace technology
 Reorganize the team
Face-to-face meetings over
paper systems
Example
Remedies

2016
TPDEV
40
#4: Loss of Rhythm
 Inconsistent Daily Scrum ritual
 Daily Scrums skipped
 Meeting times vary
 Inconsistent Sprint durations
 Sprint duration changes arbitrarily mid-
sprint
 Inconsistent Sprint planning ritual
 Skipping Sprint planning meetings

2016
TPDEV
41
#4: Loss of Rhythm
 Inconsistent Daily Scrum ritual
 Daily Scrums skipped
 Meeting times vary
 Inconsistent Sprint durations
 Sprint duration changes arbitrarily mid-
sprint
 Inconsistent Sprint planning ritual
 Skipping Sprint planning meetings
 Be consistent
 Avoid noise during Scrum and focus
on delivery
 Clarify expectations
 Conduct training
 Be consistent
 Resort to mommy rules
Rhythm helps make routine
things routine
Example
Remedies

2016
TPDEV
42
#5: Lack of Progress
• Backlog keeps growing instead of shrinking
• Too much work in progress
• Features never get finished
• The 90 percent complete syndrom
• Revision or repair on “Completed” features
• “Completed” features waiting on
uncompleted features
• Stakeholders complaining about lack of
progress
• Missed deliveries

2016
TPDEV
43
#5: Lack of Progress
• Backlog keeps growing instead of shrinking
• Too much work in progress
• Features never get finished
• The 90 percent complete syndrom
• Revision or repair on “Completed” features
• “Completed” features waiting on
uncompleted features
• Stakeholders complaining about lack of
progress
• Missed deliveries
 A backlog with early visible progress,
early visible value, and on-time
completion
 Features of great value to the
customer that are easy to construct
 A “zero-defect” product
 Commitment at all times to a
“potentially shippable product”
 A willingness to ask, “If it does not
deliver useful working code, what
good is it?”
 Realization that bugs are not
inevitable
Good Sprint backlog
management
Example
Remedies

2016
TPDEV
44
#6: ScrumMaster overdrives the work
• Work is assigned by the
ScrumMaster rather than signed
up for by developers
• Team not in control of their work
• The Daily Scrum feels like it is a
status update from the team
members to the ScrumMaster

2016
TPDEV
45
#6: ScrumMaster overdrives the work
• Work is assigned by the
ScrumMaster rather than signed
up for by developers
• Team not in control of their work
• The Daily Scrum feels like it is a
status update from the team
members to the ScrumMaster
 Let the Team in control of work
 Team define assignments
 Daily Scrum by and for the team
Self-organization is one of the
underlying principles of
Scrum
Example
Remedies

2016
TPDEV
46
#7: Specialized Job Roles
• Project team has highly specialized job
roles or descriptions such as:
– Architect,
– Designer,
– DBA,
– or Tester,…
• Team includes dedicated “testers”
• Scrum teams doesn’t show a “we’re all
in this together” attitude
• Scrum team does not need to be
comprised entirely of generalists

2016
TPDEV
47
#7: Specialized Job Roles
• Project team has highly specialized job
roles or descriptions such as:
– Architect,
– Designer,
– DBA,
– or Tester,…
• Team includes dedicated “testers”
• Scrum teams doesn’t show a “we’re all
in this together” attitude
• Scrum team does not need to be
comprised entirely of generalists
 Work assigned only by Team
 Daily Scrum to re/assign work
 Each specialist must accept general
responsibility for the system as a
whole
 “I’m going to do whatever I can to
help” attitude
“We’re all in this together”
attitude
Example
Remedies

2016
TPDEV
48
#8: Reluctance to estimate Backlog
• Individuals guessimating
• No re-estimate during Daily Scrum
• Team refuses to play the planning
poker technique

2016
TPDEV
49
#8: Reluctance to estimate Backlog
• Individuals guessimating
• No re-estimate during Daily Scrum
• Team refuses to play the planning
poker technique
 (Re-) do release planning with whole
team
 Make release burn-down visible
 Retrospective focus on the difference
release targets and estimation
 Focus estimation on an area in which
there is the clearest need for it
 Use estimation to identify uncertainty
 Plan spikes for areas of uncertainty
 Retry estimation, review uncertainty
 Make commitments based on
estimates
 Review how team met commitments
Missing releases or
substantial feature reduction
tracking
Example
Remedies

2016
TPDEV
50
#9: Executive Pressure
• Executive's demand the team
commit to releasing a set of
"minimum" features by a certain
date.
• Executive's attend the team's
meetings
• Executive's communicate directly
with team members to remind them
of deadlines

2016
TPDEV
51
#9: Executive Pressure
• Executive's demand the team
commit to releasing a set of
"minimum" features by a certain
date.
• Executive's attend the team's
meetings
• Executive's communicate directly
with team members to remind them
of deadlines
 Speak privately with the Executive
and suggest that their approach is
likely to have the opposite of the
desired effect
 Ask the Executive what they really
need and use that to help guide the
team
 Get the Product Owner to negotiate
priorities with the Executive
To support it, commitment
has to come from the Team
Example
Remedies

2016
TPDEV
52
#10: Gorilla in the Room
• One person (Sr Developer, Tech Lead,
Executive) dominates conversations
and meetings
• People won't speak until the Gorilla
has spoken
• Team members defer to the Gorilla's
opinion

2016
TPDEV
53
#10: Gorilla in the Room
• One person (Sr Developer, Tech Lead,
Executive) dominates conversations
and meetings
• People won't speak until the Gorilla
has spoken
• Team members defer to the Gorilla's
opinion
 Gorilla to speak last on any issue
 Ask the Gorilla to ask questions rather
than making statements
 Is the Gorilla a required attendee?
Ask to be absent for a meeting or two
 In the case of stakeholder it may be
necessary to ask to permanently
leave meeting (since even without
speaking they can have tremendous
impact on the team)
The wisdom of the Team
vs.
the beliefs of a single person
Example
Remedies

2016
TPDEV
54
Agenda

2016
TPDEV
55
Test Driven Development (TDD)
 Overview of the TDD
practice
Method to design software,
not just a testing method.
1) Technique where a test case
covering a code change or new
functionality is written first.
2) Then just enough code to
make the test pass is
implemented.
TDD requires automated
unit tests
*From Kent Beck, author of the book Test Driven Development: By Example, Kent Beck, Addison-Wesley Longman, 2002
 2 simple rules*
– Never write a single line of code
unless you have a failing
automated test.
– Eliminate duplication.

2016
TPDEV
56
Test-driven development cycle
TDD is a programming practice in which all production code is
written in response to a test. The cycle is as follows:
1) Pick one of the requirements in your requirements list and write a test.
2) Run the test to make sure it fails. It's easy to inadvertently write a unit test
that passes without putting the code in that implements the requirement. A best
practice is to ensure the test fails before the implementation code is written.
3) Add or modify just enough code to make the new test and all previous tests
pass. You will not run all of the tests in the project, but you will run all of the
tests in the given class or package.
4) Once the new test and all the previous tests pass, refactor the code if
necessary to "eliminate code smells" such as duplicated code.
5) Then, write another test.
6) Keep going until requirements are met.
7) When needed, refactor the code to “eliminate code smells”, like duplicated
code, and fix any broken tests before adding any new functionality.

2016
TPDEV
57
Continuous Integration (CI) Main Characteristics
Set of software development practices, behaviours and principles
 CI objectives:
– For automating and improving the integration and validation of software
continuously
– Allowing engineers can detect and fix problems early
– To deliver quality software
CI enables development teams to:
– Reduce risk
– Improve efficiency
– Generate deployable deliverables at any time
–Enable transparent view of project health
– Establish greater confidence in the software product from the development
team

2016
TPDEV
58
Walk-through of a Basic Continuous Integration
Implementation
1) An engineer picks up a new piece of
work (a defect or a new feature)
2) The engineer changes code and
satisfies themselves that the code seems
to work.
3) Once the engineer is satisfied that the
code is unlikely to break any other code,
the engineer is ready to commit/check-
in/deliver their unit-tested code to the
source code repository.
4) The engineer checks whether either they need to fix the broken build (a top
priority) or they can move on to their next task/defect.
5) Builds can be scheduled to run a complete set of test suites against the latest set
of changes.

2016
TPDEV
59
All Continuous Integration Practices (1/2)
Build
–The team can initiate a build on-
demand
–The team can initiate a build
without human intervention
–A build runs whenever code is
integrated
–The build fails if any test or
inspection fails
–Broken builds are fixed as soon as
possible
–The compilation and packaging of
your build are automated*
–Keep the build fast*
Code and Unit Test
Coding and design standards are
enforced
Developers write automated unit tests*
Developers check-in unit tested code
Developers integrate code frequently *
Static analysis is part of the build
Deployment
Avoid getting broken code
Automated deployment is in the build*
* Those practices above indicated by an asterisk are recommended by Martin Fowler in his paper on Continuous Integration.

2016
TPDEV
60
A More Typical Continuous Integration Cycle

2016
TPDEV
61
Agenda

2016
TPDEV
8 Years Ago: Our 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

2016
TPDEV
Canada
Toronto,Ottawa
,Montreal, Victoria
London/Staines
Milton Keynes
Hursley
Warwick
York
Haifa
China
Beijing
Shang Hai Yamato
Taipei
Paris
Pornichet
Beaverton
Kirkland
Seattle
Foster City
San Francisco
SVL/San Jose
Almaden
Agoura Hills
El Segundo
Costa Mesa
Las Vegas
Rochester
Boulder
Denver
Lenexa,KA
Tucson
Pheonix
Austin
Dallas
Andover
Bedford, MA
Bedford, NH
Lexington
Westborough
Westford
Cambridge
Cork
Dublin
Galway
Boeblingen
India
Bangalore
Pune
Hyderabad
Gurgaon
Cairo
Rome
Gold Coast
Sydney
Canberra
Fairfax
Raleigh
Charlotte
Lexington, KY
Atlanta
Boca Raton
Tampa
Perth
Krakow
Warsaw
Sao Paulo
Malaysia
Delft
Stockholm
Pittsburg
Poughkeepsie
Princeton
Somers
Southbury
NY, NY
Singapore
Helsinki
El Salto
 Over 150 Rational development projects
(~2800 users) using Rational Team Concert
 Plus an additional 700+ projects around IBM
-- hosting 8500+ users!
 Boarding time for new projects -
less than one day
 Applicable to agile/iterative and
waterfall projects
 Rational Development
 Rational Customer Support
 WebSphere Development
 Lotus Development
 Tivoli Development
 IBM Research Division
 IBM Global Business Services
 IBM Systems and Technology
Group
Agility @ scale at IBM

2016
TPDEV
64

2016
TPDEV
65
Team work
3 team members
7 weeks following agile principles
Using TPDEV resources & knowledge
User story:
As a student, I can use a collaborative app so that
I can get valuable tips for my studies

Upmc tpdev1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Upmc tpdev1

Similar to Upmc tpdev1 (20)

More from Jean-Yves Rigolet

More from Jean-Yves Rigolet (9)

Recently uploaded

Recently uploaded (20)

Upmc tpdev1