to be, or not to be, agile - architecting be or not to be agile.… · knowledge and experience is...
Post on 24-Jul-2020
3 Views
Preview:
TRANSCRIPT
Peter EelesIBM
To Be, or Not To Be,
Agile
The premiere software and product delivery event.June 6–10 Orlando, Florida
IBMpeter.eeles@uk.ibm.comSDP-1445A
The Development Organization’s View
The Customer’s View
Agenda
� Introduction
� Selecting a project lifecycle
� Selecting practices
� Selecting measures (and automation)
� Summary
Credentials
� Based on IBM Rational’s clients
�Large and small organizations
�A variety of business and technical domains
� Based on IBM
�We use agile ourselves!
� Based on my own experiences� Based on my own experiences
�Including the following case study …
Case Study
� A large Scandinavian bank
� 2000+ developers
� 6 business units
� Development teams are often geographically distributed
Business Objectives
Name Description Goals
Time to
market
Projects deliver faster than
today
�Complete small projects within 7 months (average
time to market is currently 14 months)
�Deliver a first increment (demo) on projects within 8
weeks from project initiation followed by subsequent
increments (demos) at regular intervals of 2-4 weeks
Cost
efficiency
Projects deliver with lower
overall cost than today
�Increase the efficiency baseline (function points per
FTE) by 10%
“Agile Adoption Programme” initiated
efficiency overall cost than today FTE) by 10%
Quality Systems exhibit the agreed
level of quality
�Decrease the error baseline by 10%
Continuous
optimisation
The development
organisation is a learning
organisation using common
processes that are
continuously updated
�Knowledge and experience is used to improve
processes
�Processes are performed in a mature and
professional way (i.e. consistently) in order to harvest
the benefits of this
Key Decisions
� Project Lifecycle
�When should we use agile?
� Practices
�What agile practices should we adopt?
� Measurement / Automation
�What should we measure?�What should we measure?
�How should we measure?
It’s not just about methods and tools
Methods
Tools(for automating aspects of
the method)
Content Deals With
Process + method content
Practices, standards, guidelines
Tool selection
Tool configuration and integrations
Roles & responsibilities
Work products
Governance policies
Tool fitness-for-purpose
Tool integrations
Licensing
Enablement(in methods and tools)
Training curriculum
Training courses
Mentoring materials
Training and mentoring
Element
Functionality ( E.g. change m
gt, requirements m
gt, testing)
Qualities (E.g. usability, scalability, reliability, cost)
Constraints (E.g. geographic distribution, migration)
See http://www.ibm.com/developerworks/rational/library/edge/08/apr08/eeles/index.html
(in methods and tools)Mentoring materials
Infrastructure(for methods, tools and
enablement)
Infrastructure specification Distribution of organization
Solution packaging
Installation and configuration
Adoption(of the environment)
Adoption approach (e.g. plan)
Install, configure, train, mentor
Migration (including org. change)
Results
Governance (e.g. measurement)
Organization(to use and support methods, tools,
enablement, infrastructure)
Organization specification Skills
Centers of excellence
Functionality ( E.g. change m
gt, requirements m
gt, testing)
Qualities (E.g. usability, scalability, reliability, cost)
Constraints (E.g. geographic distribution, migration)
Streams
Methods
Tools(for automating aspects of
the method)
Enablement
Methods
Strategy
Enablement(in methods and tools)
Infrastructure(for methods, tools and
enablement)
Adoption(of the environment)
Organization(to use and support methods, tools,
enablement, infrastructure)
Tools
Organization Implementation
(OI)
Incremental adoption
� “Deliver in waves, produce in streams”
�Organize as a sequence of waves of change
Wave 0
Strategy
Wave 1
Strategy
Wave 2
Strategy
Methods
Tools
OI
Pilots
Methods
Tools
OI
Pilots
Methods
Tools
OI
Pilots
Organise to succeed
Sponsor
Reference
Steering
Committee
Project Design Reference
Group*
Strategy Tools OI Pilots
Project
Management
* “Network of agile practitioners”
Methods
Design
Authority
Agenda
� Introduction
� Selecting a project lifecycle
� Selecting practices
� Selecting measures (and automation)
� Summary
Typical Project Lifecycles
http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf
To be, or not to be, Agile
� Management Influences
� Stakeholder Influences
� Project Team Influences
� Technology Influences
� Solution Influences
Management Influences
� Business Flexibility
�Management are willing to accept that business parameters, such as cost,
schedule and intermediate milestones, are flexible
� Empowered Teams
�Management is willing to allow the team (including the product owner) to make
key project decisions
Stakeholder Influences
� Acceptance of Agile
�Stakeholders understand and accept agile practices and the consequences of following these
� Number of Stakeholders
�The number and diversity of stakeholder relationships to be managed is limited
� Stakeholder Responsiveness
�The business representative, end users and testers are committed to spending a good deal of time working with the team in an iterative fashionspending a good deal of time working with the team in an iterative fashion
Project Team Influences
� Team skills
�Individuals on the team are team players, good communicators and are familiar with agile practices
� Embracing Change
�Team members expect and embrace frequent changes and iterative refinement of the solution
� Colocated Teams
�The project team will be colocated
� Team Stability
�Individuals will be assigned to the team for the duration of the project
� Team Roles
�Team members are able (and willing) to take on multiple roles during the project and to take on new roles if/when needed
� Agile Disciplines
�Team members have proven ability in performing disciplines that are critical for agile development with short iterations (design, testing and configuration management)
Technology Influences
� Development Environment
�The development environment (method, tools, training) will
support an agile way of working (such as automated regression
test, continuous integration and real-time dashboards) and is
sufficiently mature
� Execution Environment
�The execution environment can support regular releases
Solution Influences
� Requirements Churn
�There is a strong likelihood that there will be significant changes to requirements (and the solution) during the project
� Solution Complexity
�The required solution is relatively-complex (e.g. requires the use of unfamiliar technologies) and/or there are many different solution options
� Time-to-market
�The deadline (time) is the most important factor for the solution while the scope of the solution is flexiblescope of the solution is flexible
� Dependencies
�There are no (or only a few) dependencies on internal or external suppliers
� Release Frequency
�The solution can be subdivided in viable and meaningful business releases that can be delivered within 3-4 months
� Demonstrability
�The solution can be easily demonstrated on an incremental basis (through a user interface, for example)
Decision Framework (detail)
Decision Framework (summary)
Agenda
� Introduction
� Selecting a project lifecycle
� Selecting practices
� Selecting measures (and automation)
� Summary
IBM Practice Library
Start here!
A version of these practices is available in OpenUP
Case Study – Practices by Priority� Foundation
� Iterative Development
� Two-Level Planning
� Team Change Management
� Shared Vision
� Continuous Integration
�Whole Team
� High
� Medium
� Evolutionary Architecture
� Concurrent Testing
� Low
� Business Process Sketching
� Evolutionary Design
� Ultra Low
Process authoring and Tailoring� High
� Risk-Value Lifecycle
� Test-driven development
� Use case-driven development
� Process authoring and Tailoring
� Requirements Management
� Formal Change Management
� Component Based Software Architecture
� Design Driven Implementation
� Test Management
� Independent Testing
� Application Vulnerability Assessment
� Performance Testing
What’s in a Practice?
� Key concepts
� Work products
� Tasks
� Guidance
� Measurements
� Tool mentors
Roles, work products, tasks
� Roles
�Product owner
�Scrum master
� Work Products
�Product backlog
�Blockers list Screen shots from published versions of �Blockers list
�Sprint Goal
�Task Board
�Epics
�User stories
� Tasks
�Various
Screen shots from published versions of
SCRUM EPF and OpenUP
Agenda
� Introduction
� Selecting a project lifecycle
� Selecting practices
� Selecting measures (and automation)
� Summary
Measures help answer key questions
Agile-Related
Measures
IT-Related
Measures
Business-Related
Measures
Projects deliver
faster than today
Appropriate level of
management and
analysis activities
Agile role
adoption
Projects deliver with
lower overall cost
than today
Efficient change
request process
Agile practice
adoption
Are we meeting
business
objectives?
Are we seeing the
benefit where we
expected?
Are we agile?
Systems created or
updated in the
projects have the
agreed quality
The development
organisation is a
learning
organisation
Employee
satisfaction
Agile work product
adoption
Agile task
adoption
Agile process
adoption
Efficient
requirements
definition and
signoff
Fewer breakages
when solution
elements are
integrated
Less “solution
hardening” needed
Selecting Measures (Metrics)
� Simple criteria
�Who cares?
�Will it add value?
�Will collection be
intrusive?
Case Study – Initial Metrics
Business-related Agile-related
Cycle time
reduction
�Time spent from project initiation
to delivery of first increment
�Time spent from project initiation
to project closure
�Sprint velocity
�Blocking work items
Quality �Defects (severity 1 and 2) in �Defect trendQuality �Defects (severity 1 and 2) in
production per 100 FPs
�Defect trend
Continuous
optimisation
�Process maturity level �Adoption of agile practices
Productivity �Function points per man year �Sprint burndown chart
�Release burndown chart
Category: Cycle time reductionMetric: Sprint velocity
Objectives Sprint velocity is used to measure the performance (and therefore capability) of
the team. The velocity is useful in identifying the trend of how much work a team
can complete in a sprint.
Baseline Metric The number of points is plotted on the Y-axis and sprints on the X-axis. In initial
sprints, the team velocity is typically low but subsequently increases and
stabilises as the project proceeds. If the velocity rises or falls dramatically then it
needs the immediate attention.
Unit Velocity can be measured in term of points, days, hours, or any other unit the
team is using for estimation.
Responsibility Project Manager.Responsibility Project Manager.
When to Measure During project execution.
Manual/Automated Automated in Rational Team Concert.
Data Repository Available in Rational Team Concert.
Project Calculation Velocity, calculated as the number of units of work the team has completed in a
given sprint. Units can be points, days, hours or any other unit your team is using
for estimation.
Example See over for chart.
Target A trend of a steady or increasing number of work items being addressed over
time.
Sprint Velocity Example
Taken from RTC 2.0 project at jazz.net on 3rd December 2009
Category: QualityMetric: Defect trend
Objectives The defect trend is used to ensure that arrival and closure rates have some
correlation (i.e. that your arrivals don’t consistently outpace your closure,
resulting in a high defect backlog), to determine the remaining defect backlog, to
project the future defect arrival/close rate up to (and after) customer ship.
Baseline Metric Slope of a trend chart showing total cumulative defects (total found – total
closed) over time. Ideally, the slope should be flat or decreasing.
Unit Chart slope.
Responsibility Project Manager.
When to Measure During project execution.When to Measure During project execution.
Manual/Automated Automated in Rational Team Concert.
Data Repository Available in Rational Team Concert and Rational Quality Manager.
Project Calculation �Number of defects found for each unit of time (usually a week, but could be day
or month, depending on sprint length).
�Number of defects closed for each unit of time.
�Total cumulative defects (total found - total closed).
Example See over for chart.
Target A trend of a steady or decreasing number of defects over time.
Defect Trend Example
Taken from RTC 2.0 project at jazz.net on 3rd December 2009
Category: ProductivityMetric: Sprint burndown chart
Objectives A sprint burndown chart allows the progress of the sprint to be measured.
Baseline Metric Slope of the chart. The number of remaining units (such as work items or hours)
is shown on the Y-axis, together with the number of planned units, and time is
shown on the X-axis. Ideally, the trend of remaining units should go down as
time progresses.
Unit Chart slope.
Responsibility Project Manager
When to Measure During project execution.When to Measure During project execution.
Manual/Automated Automated in Rational Team Concert.
Data Repository Available in Rational Team Concert.
Project Calculation �Number of planned units during time I for the sprint.
�Number of actioned units during time I for the sprint.
Example See over for chart.
Target A trend of a decreasing number of remaining units over time.
Sprint Burndown Example
Taken from RTC 2.0 project at jazz.net on 3rd December 2009
Category: Continuous optimisationMetric: Adoption of agile practices
Objectives To measure the adoption of agile within a project that has selected the agile
lifecycle.
Baseline Metric Score provided by the Team Pulse survey.
Unit Ranking (from 0 to 5, where 5 represents full adoption).
Responsibility Project Manager
When to Measure During project execution.
Manual/Automated Manual.
Data Repository Central repository.
Project Calculation Derived from the Team Pulse survey which assesses the adoption of several
agile practices.
Example �The 6 team members completed the Team Pulse survey which gave an average
score over 3.0 for 4 practices, and below 3.0 for one of the practices.
�See over for example.
Target An average score > 3.0 in the Team Pulse survey.
Agile Adoption Example (detail)
Agile Adoption Example (summary)
Case Study – Automation
Automated Manual
Cycle time
reduction
�Time spent from project initiation to
delivery of first increment
�Time spent from project initiation to project
closure
�Sprint velocity
�Blocking work items
Quality �Defects (severity 1 and 2) in production per
100 FPs (FP count is manual)100 FPs (FP count is manual)
�Defect trend
Continuous
optimisation
�Process maturity level
�Adoption of agile practices
Productivity �Function points per man year (FP count is
manual)
�Sprint burndown chart
�Release burndown chart
Agenda
� Introduction
� Selecting a project lifecycle
� Selecting practices
� Selecting measures (and automation)
� Summary
Potential Relevance to You
� The general approach is broadly applicable
�Comprehensive consideration of a development environment
�Incremental adoption
�Risk-driven
�Managed as a project
� Tangible (reusable) assets� Tangible (reusable) assets
�Project lifecycle decision framework
�Practice definitions
�Metrics
�Tool configurations and integrations
�Enablement materials
Measured Capability Improvement Framework
Assess
Align proposed solution with business goals
and priorities
•Executive Business Value Workshop
(2-4 hours)
•Quick Diagnostics (1-2 days)
•Health Assessment (1-2 weeks)
Steer
Monitor projects, identify gaps, decide on corrective actions
and measure business value
•Self-Check
•Rational Insight
Act
Rapidly drive change and embed knowledge of
solution
•Rapid Deployment Packages
•Software Delivery Platform
Summary
� Agile is one of several possible lifecycles
� A successful transition to agile …
�Draws upon a small number of key principles
�Is risk-driven
�Is people-focused
�Is measured�Is measured
4
6
4
7
Daily iPod Touch giveaway
� Complete your session surveys online each day
at a conference kiosk or on your Innovate 2010 Portal!
� Each day that you complete all of that day’s session surveys, your name will be entered to win the daily IPOD touch!
SPONSORED BY
� On Wednesday be sure to complete your full conference evaluation
to receive your free conference t-shirt!
4
8
© 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, Rational, the Rational logo, Telelogic, the Telelogic 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.
www.ibm/software/rational
top related