Questions & Answers

on Agile
Scott W. Ambler
Chief Methodologist for Agile and Lean
IBM Rational
www.ibm.com/developerworks/blogs/page/ambler
twitter.com/scottwambler
Agenda

1 Technical challenges (easy)

2 Cultural challenges (hard)

3 Business challenges (very hard)

Does agile work for all types of projects?

4.9
Quality 5.0
• Agile is based on: 0.4
2.3

— Improved collaboration Functionality

5.6
6.0
1.8 Agile
2.7
— Improved stakeholder visibility Iterative
Traditional
3.9
3.0
— Greater attention to quality Money 0.2
0.8
Ad-Hoc

— Iterative and incremental delivery 4.0

4.4
Time 0.8
0.8

• Are you doing types of projects that

wouldn’t benefit from some if not all DDJ 2008 Project Success Survey
of that?
What are pros and cons in agile environment?

• Advantages • Disadvantages
— Increased quality — Development team needs to
— Improved return on investment work in a disciplined manner
(ROI) — Development team needs to
— Increased customer actually produce working
satisfaction solutions on a regular basis
— Improved time to delivery — Customer needs to be actively
involved with the team, and be
accountable for their decisions
— Contracts need to reflect the
development process
 What phase in SDLC is the most pay-off or important to
become agile?

• The agile lifecycle is different than the traditional lifecycle

• It is important to be agile all the way through
• How to cause the most damage:
— Remain “heavy”/traditional at the beginning of the project
— Retain a traditional governance strategy
— Only add agile strategies instead of replace traditional strategies with agile ones
How do you quantitatively measure agile practices?

• It depends ;-)
• You need to identify what your goals are:
— Improve quality?
— Improve time to delivery?
— Improve return on investment (ROI)?
— Improve staff retention?
• Different goals have different measures
• Advice:
— You need multiple metrics
— Trends are usually more important than point-in-time values
— Automated metrics, such as those produced by Jazz-based tools, reduce overhead
for development teams while increasing timeliness and accuracy of metrics
— You’ll still need some manually created metrics
— Some traditional metrics still make sense — i.e. defect trend rates
— Some traditional metrics might make sense, but are probably cost prohibitive — i.e.
function points
Are there any simulation techniques and tools to predict the
benefits or performance on agile practices?

• For some agile strategies, decades of evidence exists showing that they
work better
• For other agile strategies, there is growing evidence that they work better
• But, the primary determinant of success is the people and the way they
work together
• The best way to predict the benefits/performance is to pilot them in your
environment and see for yourself. You are doing exactly that.
 How is agile working in large scale projects?

80%
Iterative 68%
55%
83%
Agile 70%
55%
74%
Ad-Hoc 58%
40%
69%
Traditional 61%
50%

Large Medium Small

Source: DDJ State of IT Union Survey July 2010

 How can we simplify the toolset?

• There is significant benefit for working with integrated and instrumented tools such as the Jazz
platform
• But:
— You need to look at the whole picture, not just point-specific issues
— You need to consider the total cost of ownership (TCO)
— You need to consider the total value of ownership (TVO)
• A common strategy is to adopt many point-specific tools at first to solve immediate, partial needs
— i.e. Hudson for continuous integration (CI)
— i.e. Redmine for project planning and coordination
• Later, adoption more sophisticated tooling such as Rational Team Concert (RTC)
— RTC addresses the point-specific functionality and more
— It does so in an integrated and instrumented manner
— The implication is that you’ll want to abandon the point specific tools at some point
• Pilot teams will take the brunt of this as you learn what tools work best for you
• You’ll want to identify a (reasonably) common toolset before rolling out agile to a larger number of
teams
As the organization is on agile@scale across the enterprise,
does agile help CMMI assessment? Especially over CMMI
ML4?

• Your CMMI assessors will need experience with agile development

• The focus of CMMI 4 level is on measurement and CMMI level 5 on acting on the
measures
— Agile provides significantly greater visibility into project teams
— Jazz-based products automate metrics gathering
• Industry data:
— The Dr. Dobb’s Journal (DDJ) 2008 Process Framework Survey reported that
there is no statistical difference in the success rates between CMMI and non-
CMMI agile projects. The implication is that CMMI doesn’t necessarily harm
agile strategies
— The DDJ November 2009 State of the IT Union survey included respondents
reporting success at applying agile and CMMI together
What is the suggested approach for maintaining the robust
SW platform and refactoring ?

• Refactorings are simple changes to your code, database schema, or user interface
which improves the quality without changing the semantics
— You make things better, you don’t add new features
— Refactorings are very small, they’re something that mature professionals do
naturally
• Agilists take an evolutionary approach to architecture
— Architecture envisioning at the beginning of a project
— Details are worked out throughout the project
— Collaboration, not documentation
• Disciplined agilists work closely with enterprise professionals
— Enterprise architects to help you understand the existing infrastructure and the
“to be” vision
— Reuse engineers to leverage or develop reusable items
How to apply agile practices in system operation and
maintenance environment ?

• Operations and maintenance can benefit from agile

strategies:
— Improved collaboration
— Improved stakeholder visibility
— Greater attention to quality
— Iterative and incremental delivery
Our team isn’t co-located, will agile still work?

Don't Know,
1%
Some Very
Distant, 29%
Co-Located,
42%

Within Driving
Distance, 13%
Same
Building, 17%

Source: Ambysoft 2009 Agile Practices Survey

What is the difference between an agile coach and a
ScrumMaster / Team Lead

• Coaches coach the whole team (including ScrumMasters) on

how to adopt agile
• ScrumMasters facilitate the agile work flow, do the planning,
monitor progress, help do the work, …
 Why User stories and why not use cases ?

• You can use any type of requirement

artifact that you want:
— User stories
— Features
— Use cases
— Usage scenarios
— Defect report
— Screen sketches
— …
• But:
— The artifact needs to be small,
implementable in a single
sprint/iteration
— The artifact needs to be simple,
because details are gathered on a
just-in-time (JIT) basis
Agenda

1 Technical challenges (easy)

2 Cultural challenges (hard)

3 Business challenges (very hard)

As an agile team members, what attitudes should people
have?

• Agilists are:
— Collaborative
— Life-long learners
— Self-organizing
— Focused on delivering concrete value to the stakeholders on a
regular basis
— Focused on quality
— Open and honest
— Willing to share their skills
— Willing to learn skills outside of their “specialties”
 If you consider the oriental culture, it's more like vertical
culture (i.e. command and control). Do you think agile
would work in that environment? Do you have such an
experience? If yes, how would you solve the issues ?

• Yes, there are examples of oriental organizations adopting agile

— i.e. The IBM China Development labs
• Challenges:
— Adopting agile requires a paradigm shift
— Cultural issues are always the most difficult to overcome
• You will need to recognize that your existing culture:
— Is an impediment to success
— Can be changed
— Needs to change
— Is not a valid excuse
• Advice:
— You need to educate and coach everyone involved, including senior management
— You need to educate your customers and help them to learn how to be agile
What is best way of changing the senior management mind-
set to be agile environment ?

• Senior management needs to:

— Be educated and mentored on agile
— Understand that they need to change too
— Understand that agile works significantly differently than traditional
— Recognize that agile works better
— Support the agile adoption process, even during periods when the
process isn’t going so well
What is the optimal adoption rate?

• It depends!
• Every organization is different
• You start with pilot projects to:
— Identify what challenges your organization faces
— What your strengths are
— What works for you
• Implications:
— Your plans will need to evolve over time
— Your strategy will need to evolve over time too as you learn
 How do project managers fit in?

• Agile teams are self organizing

— Agile teams plan and estimate their own work
— Agile team members collaborate to do the work, they don’t need to be told
— Agile teams find a sustainable pace, thereby increasing their overall productivity
• Agile teams need leaders, not managers
— The ScrumMaster/Team lead facilitates, not dictates
• Agile teams coordinate daily via stand-up meetings
— This may take some time to get used to
— Anyone interested in the “project status” is welcome to attend
• Many traditional project management activities are better done by the team, not the
“manager”
— This strips away a lot of the questionable bureaucracy
• The implication is that project managers need to transition to an agile role
— Many PMs become ScrumMasters
— Some PMs become agile team members
How do business analysts fit in?

• Analysis is so important, agilists do it every single day

• But, there is rarely enough analysis work required to justify the existence
of someone focused just on that
• Agile teams avoid writing detailed requirements specifications due to the
risk associated with doing so
• The implication is that existing business analysts need to transition to an
agile role
— Many BAs become Product Owners
— Some BAs become agile team members
• The world has changed, BAs must change with it
Agenda

1 Technical challenges (easy)

2 Cultural challenges (hard)

3 Business challenges (very hard)

 How do agile teams deal with fixed cost/price?
• Customers are welcome to set whatever
cost they like
• Agilists work in priority order, delivering
the best return on investment possible for
that defined amount
• Customers must prioritize the
requirements, and understand the
implications of doing so
• Customers are welcome to change the
requirements or prioritization of
requirements at any point in time, but that
will deprioritize some existing
requirements
• The implication is that customers need to
be actively involved and accountable for
the decisions that they make
 How do agile teams deal with fixed schedules?
• The customer is in complete control of the
scope, schedule, and price
• They can vary, or fix, any of them
• The more factors that they fix, the greater the
risk to the project
• The more factors that they fix, the more “best
practices” developers will apply to push the
risk onto the customer
• Effective development project teams work
with customers in a collaborative partnership
• Dysfunctional development project teams
work with customers on a strictly specified
contractual approach
— This is bad for both the customer and the
development team
 How do agile teams deal with fixed scope?
• Fixed scope projects are a sign of significant dysfunction
• Changing requirements are a competitive advantage, not something to be avoided
• Advice:
— Educate your customers on the problem with this approach

Detailed requirements specs

Always increase project risk
7%
Often
13% Never Traditional “change mgmt”
45%
approaches are little more than
“change prevention” strategies
Stakeholders want software
which fulfills their needs, not
software that fulfills a spec
Sometimes
16%
The real goal is to understand
Rarely and then implement
19%
Source: Chaos Report v3, Standish Group, requirements, not document
www.agilemodeling.com/essays/examiningBRUF.html them
 www.ibm/software/rational

© Copyright IBM Corporation 2011. 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.