implementing an agile transformation using discipline ... ruc/implementin… · implementing an...
TRANSCRIPT
Implementing an Agile Transformation Using
Discipline Agile Delivery Michael J Lyons
World Wide Solution Deployment Architect, IBM Rational
2
Agenda
Why a transformation ? Why Agile / Lean ? Agile / DAD – What is it ? Agile Deployment Framework Agile Deployment Components
– Lifecycle / Process – People – Practices – Tools
Sample Agile Results General Transition Recommendations
2
2
3
Why a Transformation is Necessary? Involves widespread corporate change
– All aspects of IT
– The business must participate
– Human Resources
– CIO / CTO
Organizational Change principles must be implemented
Employee roles must be changed
Processes must be updated
Tools must be secured and people trained
Teams and team members can not learn Agile on their own, without a seasoned coach
Small isolated agile teams can be successful, but expanding to teams that must collaborate creates the need for an enterprise wide transformation
Have you adopted any agile techniques?
Source: State of the IT Union Survey, Dr. Dobb’s Journal, July 2009
Third-party research suggests even wider adoption
No 24% Yes
76%
Why Agile / Lean ? – they have gone mainstream
Results from Scott Ambler’s 2013 How Agile Are You?
Survey posted at www.ambysoft.com/surveys/
Recent survey on Agile adoption by Agile
criteria
4
Why Agile / Lean ? they work
Dr. Dobb’s Journal 2008 Project Success Survey
0.8
0.8
2.7
0.4
0.8
0.2
1.8
2.3
4.0
3.0
5.6
5.0
4.4
3.9
6.0
4.9
Time
Money
Functionality
Quality
Agile
Iterative
Traditional
Ad-Hoc
Detailed results online at www.ambysoft.com/surveys/
0% 20% 40% 60% 80% 100%
Traditional
Ad-Hoc
Agile
Iterative
Successful Challenged Failed
Dr. Dobb’s Journal 2010
Project Success Survey
Bottom Line: Agile teams produce higher quality work, are quicker to deliver, are more likely to deliver the right functionality, and more likely to
provide greater ROI than traditional teams
5
Unified Process (UP)
6
Hybrid: DAD adopts best practices from several agile
methods
Extreme Programming (XP)
Scrum
DAD is a hybrid process framework. DAD adopted the best practices and philosophies from a number of methodologies
Harmony
Process Disciplined Agile
Delivery (DAD)
Lean
Agile
Modeling
Agile Deployment Framework: Overview
7
Pilot Project(s)
Define Working Model
Prepare for Pilot
Establish Core Team
Assess and
Decide
Execute Adoption Strategy
Milestone 0 Solution & Plan Approved
Milestone 1 Core Team Enabled
Milestone 2.n Incremental Working Model Defined
Milestone 3.n Ready for Pilot
Milestone 4.n Ready for Roll out
Milestone 5 Adoption Complete
Release 1
Release 2
Release 3
…
Agile Deployment Framework: Initialization
8
Pilot Project(s)
Define Working Model
Prepare for Pilot
Establish Core Team
Assess and
Decide
Execute Adoption Strategy
Milestone 0 Solution & Plan Approved
Milestone 1 Core Team Enabled
Milestone 2.n Incremental Working Model Defined
Milestone 3.n Ready for Pilot
Milestone 4.n Ready for Roll out
Milestone 5 Adoption Complete
Release 1
Release 2
Release 3
…
A typical structure for a large-scale agile transition
Enterprise launch Early adopter phase
Setup
Setup overarching governance
Agree to KPIs and setup measurements
Identify target projects
Overarching strategy
Deploy environment and infrastructure for success
Agree and charter objectives
Initial training and change management
Training and onboarding materials
Mentors and champions
Center of Excellence
Process adaptation for project context
Oversight and steering
Methods and standards
Steering Benefit tracking Lessons learned
Mentor initial projects
Review and improve
Ev
alu
atio
n
1-2 months, depending on project context 1-3 months Determined by rollout plan
Scaling and change mgt
3 - 6 months per project
Create environment and infrastructure for success
Prepare mentors, Champions, and sponsors
9
10
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 production Defect trend
Continuous
Optimization
Process maturity level Adoption of agile practices
Productivity Function points per man year Sprint burndown chart
Release burndown chart
10
12
Aligned new roles, artifacts, tasks
Roles – Product owner
– Scrum master
Artifacts – Product backlog
– Blockers list
– Sprint Goal
– Task Board
– Epics
– User stories
Tasks – Various
Screen shots from published versions of SCRUM EPF and OpenUP
Role and Responsibilities – Coaches / Sponsors
Agile Coach:
– Provide advice to the team
– Provide opportunities for people to learn, even through mistakes
– Pair with the people they are coaching to provide detailed mentoring
– Help teams to solve problems
– Negotiate conflicts among team members
– Promote self-organization and self-discipline within the team
– Help the team to understand and meet their improvement goals
Agile Champions and Sponsors
– Support agile coaches
– Work closely with the business to help it understand and shift to agile development
– Work closely with IT senior managers to help them understand and adopt agile development
– Communicate to the organization the current status of the agile adoption, successes, and so on
– Help promote communication between agile coaches and teams
– Promote and defend the agile approach in their line of business
– Use collected results to show value
14
15
A practice is a documented approach to solving one or several commonly occurring problems. – Can be informally document through one white paper, or formally documented through a combination of training courses, tutorials,
process models, etc.
– One-stop-shop for relevant content, see Practice Components below
A practice can be adopted independently from other practices – Organizations can adopt one or a few practice at a time
– Avoid process war: practices can be shared across processes (e.g. OpenUp uses Scrum practices)
A practice has a positive impact on one or several business objectives – Time-to-Market, Improve Quality,
Increase Innovation, …
The adoption of a practice, and it’s
impact on business objectives, can
be effectively measured – A practice can be adopted incrementally
– Make it easy to learn about practices by making
practices stand out, do not hide them in context
of a process
Practice Components
Motivation – why do you need it
Process and methods
Tools for implementing the practice
Services aiding its implementation
Enablement – how is knowledge gained about the practice
Measurements of adoption level
What is a “Practice”?
16
IBM Rational Practices
Incrementally adopt
practices to
address key gaps
Foundation –Iterative Development –Two-Level Planning –Team Change Management –Shared Vision –Whole Team –User Story Development –Requirements Management
Later –Risk-Value Lifecycle –Test-driven development –Continuous Integration –Evolutionary Architecture –Concurrent Testing
Typical Deployment
17
Benefits of a practice-based approach
Benefits:
Offers a loosely coupled, modular way to adopt improved development techniques
Eases burden associated with large and complex processes
Independent practices can be learned separately, over time
Successful adoption can be measured as teams are ready
Result:
Easier, more effective deployment of customized and adaptable practices and processes.
Software that better meets business needs, delivered faster
Agile Deployment Framework: Mobilization
18
Pilot Project(s)
Define Workin
g Model
Prepare for Pilot
Establish Core Team
Assess and
Decide
Execute Adoption Strategy
Milestone 0 Solution & Plan Approved
Milestone 1 Core Team Enabled
Milestone 2.n Incremental Working Model Defined
Milestone 3.n Ready for Pilot
Milestone 4.n Ready for Roll out
Milestone 5 Adoption Complete
Release 1
Release 2
Release 3
…
19
Scope - Identifying the right pilots
Characteristics considered:
– Project team / Project / Business engagement / User involvement
In order to learn as much as possible from the pilots...
– At least one pilot project should include some degree of dispersed team members
– At least one pilot project should include multiple teams
– At least one pilot project should involve co-operation with one or more internal and/or external vendors
– The pilots projects should cover different platforms (e.g. SQL server, Host/mainframe etc)
– The pilots should cover different kind of project types /tasks (e.g. new development, extension of existing systems, legislative, maintenance, error handling etc.)
– At a minimum 3 pilot projects should be planned
22
Major Activities for the pilots • Joint project planning
• “Adoption Through Execution”
•A small group of agile coaches will:
•Be trained and mentored on the practices to be deployed
•Determine the changes to the practices
•Document these modified practices
•Determine and document the tool usage model
•Determine initial metrics
•Projects will execute the new process and tools:
•Experienced coaches will mentor the team members and “grow” internal agile coaches
•Best practices will be harvested and the initial process updated
•Additional practices will be adopted by the teams
24
Agenda
Why a transformation ? Why Agile / Lean ? Agile / DAD – What is it ? Agile Deployment Framework Agile Deployment Components
– Lifecycle / Process – People – Practices – Tools
Sample Agile Results General Transition Recommendations
24
2
4
IBM Software Group improvement strategy Agile delivery has been informally adopted since the early 2000s,
likely earlier
The official adoption program started in 2006.
Adoption included these activities:
– Training and education at all levels in IBM Software Group (SWG), including
practitioners, middle management, and senior management
– Mentoring or coaching at all levels, particularly on project teams
– Alignment of tools with the agile process, include a significant adoption of tools
based on IBM Jazz™. Agile delivery adoption is a long-term, multiple-year
strategy, which is still underway
– Continuous process improvement
25
26
Improving productivity in IBM SWG through improved
agility
Y1 Y2 Y3 Y4 Y5
Headcount per Product Release 74 75
68
64
58 Revenue by Headcount
Lessons learned at IBM Train people on a just-in-time (JIT) basis:
– People lose 80-90% of newly gained knowledge within 4 weeks, if they don’t immediately apply that knowledge
Support team members: – Have a Center of Excellence (CoE)
– Have coaches or mentors
– Have champions or sponsors
– Have internal discussion forums
– Bring in outside speakers
– Support internal speakers
– Promote executive awareness of agile delivery, better yet, understanding
Support coaches and champions: – Offer coaching to people in both of these roles
– The CoE can often provide this required support
27
Lessons learned at IBM (continued) Be flexible:
– Individuals have different learning strategies
– Different teams are in different situations
– Aim for repeatable results, not repeatable processes
Have manageable growth: – Don’t increase the number of agile teams too fast; otherwise, teams cannot be
adequately supported
– Don’t increase the number of agile teams too slowly; otherwise people may experiment counterproductively on their own
– Treat agile adoption like an agile project
– Establish a release plan
– Schedule iterations after which you deliver something regularly
– Demonstrate your results, both successes and failures
– Reflect on what you’ve learned and steer the project accordingly
28
29
Metrics – Rational Development
Note: Goals are either internal IBM statistics or industry benchmarks.
Metric Goal Year 1 Measurement Year 3 Measurement
On Time Delivery 65% 47% 100%
Defect Backlog 3 Months 9+ Months 3.5 months
Enhancements Triaged 85% 3% 100%
Enhancements into Release 15% 1% 21%
Customer Sat Index 91% 88% 96%
Beta Defects Fixed Before GA 50% 3% 94%
Agile / Iterative Projects 25% 5% 78%
What results can you reasonably expect? Success criteria Year 1 Year 2 Year 3
Quality 3-5% fewer defects 3-5% fewer defects 3-5% fewer defects
Labor costs 2-3% improvement 4-5% improvement 4-5% improvement
Time to value 5% faster 10% faster 5% faster
Delivered functionality 5% improved
accuracy
5% improved
accuracy
5% improved accuracy
These figures pertain to a large-scale adoption across an IT department
The results are year-on-year
Agile delivery is not a cure-all
Beware anecdotal results from single-project teams. It’s easy to replace a troubled team with experts who show significant improvements
These numbers are conservative and based on experiences in developing IBM Rational software over the years. It is possible to do better
30
31
Agenda
Why a transformation ? Why Agile / Lean ? Agile / DAD – What is it ? Agile Deployment Framework Agile Deployment Components
– Lifecycle / Process – People – Practices – Tools
Sample Agile Results General Transition Recommendations
31
3
1
General Transition Advice
Be prepared to confer with others to transfer your skills to them and to pick up new skills from them
Accept that “the rules” have changed and “you” must change too
Accept the idea that your traditional role might not exist anymore, although the team still completes activities that are associated with your traditional role
Be prepared to work in an evolutionary and collaborative manner
Be prepared to move away from a specialist role to become a generalizing specialist
Be prepared to deliver a potentially consumable solution every few weeks
32
Invest across the spectrum of improvements
Focusing on business outcomes offers the greatest return on investment
Source: IBM
Control
Efficiency
Business value
Individual Team Business Organization
Improve automation Improve processes
Improve collaboration
Increase flexibility and investment value
Implementation costs are per person per year
Cost to implement:
10%-35% Some culture change
Productivity:
25-100% Timeframe = Months
Cost to implement:
5%-10% Predictable
Productivity:
15-35% Timeframe = Weeks
Cost to implement:
25%-50% Much culture change
Productivity:
50-200+% Timeframe = Years
Cost to implement:
<5% Very predictable
Productivity:
5-25% Timeframe = Days
33
34
Planned Knowledge Transfer Activities
3 types of mentoring sessions
– Management workshops (2 hours)
– Project team workshops (2 hours)
– Role specific workshops (4 hours)
Train the trainer
– Trained local resources to deliver these mentoring sessions
Coach the coach
– Trained local resources enabled to do coaching in-house
Support framework
– Experienced agile coach allocated to each pilot for 1-2 days per week
– Support teams will be in place to provide advice, guidance and support for both method content and tools
Ensure general awareness and prepare for larger scale education through “roadshows”, articles, informal talks, etc.
Agile and the business – a different relationship
The business and IT processes must reflect one another:
– Plans must be high-level with the details coming just-in-time (JIT)
– Schedules and estimates must be given in ranges
– Traditional business approaches can eliminate most benefits of agile development
The new relationship with the business:
– Team members must be actively involved with development throughout the
lifecycle
– With greater visibility and control that teams have, teams also must become more
accountable
– Teams often don’t understand the implications of their requests; they must be
educated
35
Primary Challenge: Culture Change
Focus on delivering visible value to stakeholders regularly
– Specialists can struggle with delivering visible value at first
Focus on high-value activities
– Many traditional “best practices” are abandoned
Agile teams are self-organizing
– Many current managers struggle with self-organizing teams, and some people like
being directed
Disciplined agile teams are governed appropriately
– Your IT governance strategy will have to change
Disciplined agile teams are quality focused
– Quality is everyone’s job
36
Common Anti-patterns
Thinking you’re already agile
Focusing on a subset of the delivery process
Focusing on individual roles one at a time
Thinking that you’re in a special situation where agile practices can’t help
Danger!
37
38
Agile Transformation Best Practices
Adopt a “Stop-the-line” culture
– Eliminate technical debt
– Stop living with pain
Protect your teams
– Eliminate interruptions
– Be willing to say “No!”
– Foster a penalty-free environment
Provide support and encouragement
– Attend demos
– Encourage passion
– Promote self-directed teams
Advocate continuous improvement
– “If you’re not making mistakes, you’re not trying hard enough”
What is disciplined agile? Disciplined agile delivery is an evolutionary (iterative and
incremental) approach that regularly produces high-quality
consumable 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.
39
40
Critical Success Factors
Middle management championship is essential
– Winning over executives is easy
– Winning over practitioners is easy
– Winning over middle managers is HARD
- Architects, PMs, Test Managers and Development Managers
- These are the folks that must translate technical results into business results
Return on investment must be demonstrable in first deployments
• Incremental demonstration of value, early and often
• Disruption cost profile may dominate Value delivered profile
- You need to track and quantify both
Pilot significant change on business critical projects
• That is where the A-players are
• That is where organizational scrutiny/support is most intense
41
Summary
Why a transformation ? Why Agile / Lean ? Agile / DAD – What is it ? Agile Deployment Framework Agile Deployment Components
– Lifecycle / Process – People – Practices – Tools
Sample Agile Results General Transition Recommendations
41
4
1
42
© 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