Debunking “Bleeding Edge”
Methodologies A to Z:
Agile – RUP – Scrum – XP
David M. Sides, PMP, OPM3, ITIL
Vice President, Sogeti
Project Consulting Practice
www.us.sogeti.com
1
Introduction & Caveats








Expectations?
Agile – RUP – Scrum – XP – To use or not? You decide.
My premise and bias: Traditional methods for 20+
years…maybe there is a better way? You tell me.
Change is hard.
True leadership is rare.
There is no “Silver Bullet”.
There are no perfect People, Processes, or Tools.
Corporate cultures are full of “Organizational Inhibitors”.
2
And now…Agile
with David Sides
Dave’s “Top 10” Stupid Agile Tricks
1. Never look back. What’s done is done.
2. Matrix manage me.
3. Make it really complex so everyone will be impressed.
4. Pay me by the pound.
5. Close your door and send an email.
6. Micro-manage me.
7. Stay in your silos.
8. They’ll get it when we’re done.
9. Stick your head in the sand.
10. We in IT know what’s best for our customer.
4
Agile









Manifesto
History
Values
How do you know?
TDD & Refactoring
SDLC
AUP
Change Management
Simple Definition
5
The Agile Manifesto
1. Never look back. What’s done is done. [At regular intervals, the team reflects
on how to become more effective, then tunes and adjusts its behavior accordingly.]
2. Matrix manage me. [The best architectures, requirements, and designs emerge
from self-organizing teams.]
3. Make it really complex so everyone will be impressed. [Simplicity--the
art of maximizing the amount of work not done--is essential.]
4. Pay me by the pound. [Working software is the primary measure of progress.]
5. Close your door. Send an email. [The most efficient and effective method of
conveying information to and within a development team is face-to-face conversation.]
6. Micro-manage me. [Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.]
7. Stay in your silos. [Business people and developers must work together daily
throughout the project.]
8. They’ll get it when we’re done. [Deliver working software frequently, from a
couple of weeks to a couple of months, with a preference to the shorter timescale.]
9. Stick your head in the sand. [Welcome changing requirements, even late in
development. Agile processes harness change for competitive advantage.]
10. We in IT know what’s best for our customer. [Our highest priority is to
satisfy the customer through early and continuous delivery of valuable software.]
6
History of Agile
In the late 1990’s several methodologies began to get increasing public attention. Each had
a different combination of old and new ideas, but all emphasized:
•
•
•
•
•
Close collaboration between the programmer team and business experts
Face-to-face communication (as more efficient than written documentation)
Frequent delivery of new deployable business value
Tight, self-organizing teams
Ways to craft the code and the team so the inevitable requirements churn was not a crisis
Who?
17 independent thinkers, competitors and
anarchists from XP, Scrum, DSDM, ASD, et al
What?
Met to try to find common ground on software
development
When?
Where?
Why?
February 11-13, 2001
How?
They skied, ate, drank, and came to terms,
naming themselves “The Agile Alliance”
Output?
The Agile Software Development Manifesto
The Lodge at Snowbird, Utah
They felt the need for an alternative to
“documentation-driven, heavyweight software
development processes”
7
Agile Values
1.
Individuals and interactions over processes and tools. Teams of
people build software they need to work together effectively.
2.
Working software over comprehensive documentation. Provide
benefits and value early and often. Don’t get paid by the pound for your
documentation; be concise.
3.
Customer collaboration over contract negotiation. Only your
customer can tell you what they want. Yes, they will change their minds and
won’t get it right the first time. Communicate, understand their needs, and
educate your customers along the way.
4.
Responding to change over following a plan. People change,
priorities change, and the business environment changes. Technology changes
over time, although not always for the better. A Project Plan is good, but stuff
happens and there must be room to change it as your situation changes.
8
How do you know if you are Agile?
Ask yourself these questions…
1.
Is the team taking a test-driven approach to development?
With Test-driven Development (TDD) you write a single test before writing just
enough code to fulfill that test. Review the test suite, see it run, and view the
actual source code. Look for a 50-50 split between testing code and production
code. A 20-80 split is clearly a problem.
2.
Are stakeholders active participants in development?
Minimally stakeholders should be available and involved on a daily basis, provide
information and make decisions in a timely manner. The team should be able to
introduce me to their stakeholder(s) immediately.
3.
Is the team regularly producing high-quality, working software?
Within a few weeks, the team should be able to show the working software that
they've built to date as well as the source code. The code should be consistent
because it will have been written to conform to a common set of guidelines and
the team will refactor when appropriate to ensure that it remains of high quality.
4.
Is the team self-organizing and highly collaborative?
Agile teams employ the most effective communication strategies available. Detailed
specifications may be sparse, but all should know and understand them. Team
members should be motivated and self-directed instead of having a project
manager do their planning for them.
9
Test-driven Design/Development (TDD)
Test–driven Design/Development (“test first”):
1. Add a test with just enough code to fail.
2. Run your tests to fail; either a subset, or if time
allows, the complete test suite.
3. Update your functional code to make it pass the
new tests.
4. Run your tests again. If they fail, update your
functional code and retest.
5. Once the tests pass, start over (you may first
need to refactor any duplication out of your
design as needed).
Refactor – Restructure your code by making small changes
to improve your design, making it easier to understand and
modify. Refactoring enables you to evolve your code slowly
over time, to take an iterative and incremental approach to
programming.
10
Agile SDLC
11
Agile Unified Process (AUP)
12
Agile Change Management
Key CM Factors:
1. Embrace change.
2. Accept the idea that
requirements will evolve
throughout a project.
3. Understand that because
requirements evolve over time
that any early investment in
detailed documentation will
be wasted.
4. Do just enough initial
requirements envisioning to
identify project scope and
develop a high-level schedule
and estimate.
5. “Model Storm” (JIT modeling)
continually during development
to explore each requirement in
the necessary detail.
13
A Simple Agile Definition
Agile is an iterative and incremental (evolutionary)
approach to software development
performed in a highly collaborative manner
by self-organizing teams
with “just enough process” (JEP)
that produces high quality software
in a cost effective and timely manner
which meets the changing needs of its stakeholders.
14
Agile Quiz



What is it?
History
When to use it?
15
The Rational Unified
Process
16
You Might Be A Texan If...
1. You can properly pronounce Corsicana, Palestine, Waxahachie, Bexar,
Mexia, Waco, Beaumont and Amarillo.
2. A tornado warning siren is your signal to go out in the yard and look
for a funnel.
3. You've ever had to switch from "heat" to "A/C" in the same day.
4. You measure distance in minutes or hours.
5. You know cowpies are not made of beef.
6. Someone you know has used a football schedule to plan a wedding
date.
7. You are 100% Texan if you have ever had this conversation:
"You wanna coke?"
"Yeah."
"What kind?"
"Dr. Pepper."
17
The RUP?







RUP is and not?
ABCDEF
History
Why?
Profile
Use Cases
PM
18
What is RUP? What is it not?
The Rational Unified Process (RUP) is an iterative software development
process framework created by the Rational Software Corporation.

The RUP is not a single concrete prescriptive process, but rather an
adaptable process framework.

The RUP does not have to be used as-is, all the time, but should be
tailored by the development organizations and software project teams that
select the elements appropriate for their needs.

The RUP is also a software process product, including a hyperlinked
knowledge base with sample artifacts and and detailed descriptions for
many different types of activities.

The RUP is included in IBM’s Rational Method Composer (RMC) which
allows customization of the process.
19
IBM Rational Method Composer (RMC) 7.2 Plug-ins
















IBM Rational Method for SOA Governance Plug-in V1.0
RUP for WebSphere Business Modeler Plug-in V1.0 (beta)
IBM Rational Method for Portfolio Management (for Initiatives) Plug-in V1.0
RUP for Microsoft .NET Plug-in V3.0
RUP for COTS Package Delivery Plug-in V2.1.1
IBM Rational Method for Program Mobilization Plug-in V1.02
RUP for Practical Software and Systems Measurement (PSM) V3.0
RUP for Maintenance Projects Plug-in V1.0
RUP for DoDAF Plug-in V1.0
RUP for Compliance Management Plug-in V1.0
The IBM Rational Unified Process for System z V1.0
The IBM Rational Unified Process with ITSM/ITUP Connection V1.0
RUP with CMMI Compliance Support V1.0 Beta 2
RUP for Asset-Based Development V3.0 and Asset-Based Dev. Governance Plug-in V1.0
The IBM Rational Unified Process for Global Dev. and Delivery Maintenance V1.0 Beta
RUP for Model-Driven Systems Development Plug-in V4.0
20
RUP = ABCDEF
6 Key Principles of Business-Driven Development

Adapt the process - A project or organization must “right-size” the process to their
needs. RUP provides pre-configured process templates for small, medium, and large
projects.

Balance stakeholder priorities - This includes often conflicting business goals and
stakeholder needs that compete for time and money.

Collaborate across teams - Software engineering in a globally distributed
environment and executed in an iterative-incremental approach is truly a team effort
with all stakeholders being heard.

Demonstrate value iteratively – Each delivered increment, which includes the value
of the past iteration, is used to measure the progress of the project and to encourage
feedback from stakeholders about the direction of the project. Stakeholders influence
the shape of the development effort while the project is executed.

Elevate the level of abstraction – This practice motivates the use of reusable assets
and prevents software engineers going directly from requirements to custom code.

Focus continuously on quality - Quality checks are an ongoing activity, often
performed daily, supported by the entire team. Automating test scenarios (scripts) helps
in dealing with the increasing amount of tests due to iterative development.
21
History of RUP

The roots of Rational Process go back to the original spiral model
(combination of prototyping and waterfall models) of Barry Boehm.

The Rational Approach was developed at Rational Software in in the
1980s and 1990s.

The RUP was the result of the merger of the Rational Approach and the
Objectory process (Ivar Jacobson) following Rational’s 1995 acquisition
of the Swedish Company Objectory AB.

The first version of the RUP (v5.0) was released in 1998 (chief
architect Philippe Kruchten).

The latest version of the RUP (v7.0) was released with the
announcement of the IBM Rational Method Composer (RMC) in
November 2005.
22
Why a RUP?
Problem: The developers of the RUP focused on diagnosing and analyzing
the root causes of failed software projects. They also looked at existing
software engineering processes for solutions to these symptoms. Findings:










Ad hoc requirements management
Ambiguous and imprecise communication
Brittle architecture (architecture that does not work well under "stress")
Overwhelming complexity
Undetected inconsistencies in requirements, designs, and implementations
Insufficient testing
Subjective assessment of project status
Failure to attack risks
Uncontrolled change propagation
Insufficient automation
Conclusion: Project failure is caused by a combination of several symptoms,
though each project fails in a unique way. The outcome of this study was a
system of software best practices they named the Rational Unified
Process.
23
RUP Project Profile
Performed in iterations – Elaboration-Construction-Transition
24
Rational Unified Process
Look familiar?
25
Defining What When

RUP
•
Prioritize use cases
•
By stakeholder priority
•
And by architectural coverage
26
Components of a Use Case Diagram
Actor:
Someone/something
outside the system that
interacts with the system
Use Case:
Defines a piece of
functionality of the
system
Communication – Association:
Shows the Actor and the Use Case
communicate
27
Use Case Specification:
Basic flow of events,
alternate flows, error
flows and sub-flows as
appropriate
Architecture

What is architecture?
•
High-level components and their connections
How key elements will work together to support the system
Sweeping mechanisms that impact much of the system
Common patterns applied within the design

Design can be “as-is”

Architecture always implied “to-be”

An architecture-centric process
•
•
•
•
•
•
Attacks risk with an early emphasis on architecture
Architecturally-significant requirements elicited earlier
Early builds exercise architecture
28
What about Project Management?

Project planning in the RUP occurs at two levels. There is a high-level Phase
Plan (software development plan) which describes the entire project, and
a series of detailed Iteration Plans which describe the iterations.

The RUP PM discipline focuses mainly on the following aspects of an iterative
development process:




Risk management
Planning an iterative project, through the lifecycle and for a particular iteration
Monitoring progress of an iterative project, metrics for quality and performance
However, this discipline of the RUP does not attempt to cover all aspects of
project management. For example, it does not cover:



Managing resources: hiring, training, coaching
Managing cost/budget: defining, allocating
Managing procurement: contracts with suppliers, vendors, and customers
PM gaps to be filled: Integration, Scope (Change Mgt), Cost, Resource Team
Building, Communications, Procurement
29
The RUP Quiz



What is it?
History
When to use it?
30
Scrum
31
Scrum




What is it?
History
Process
Scrum compared to a Pressure Cooker
32
What is Scrum?
Scrum is an iterative, incremental process for developing any product or
managing any work. It has been used from simple projects to complex
software. It produces a potentially shippable set of functionality at the end
of every iteration. Scrum attributes:








An agile process to manage and control development work.
A wrapper for existing engineering practices.
A team-based approach to iteratively and incrementally develop systems and
products when requirements are rapidly changing.
A process that controls the chaos of conflicting interests and needs.
A way to improve communications and maximize co-operation.
A way to detect and cause the removal of anything that gets in the way of
developing and delivering products.
A way to maximize productivity.
Scalable from single projects to entire organizations. Scrum has controlled and
organized development and implementation for multiple interrelated products and
projects with over a thousand developers and implementers.
33
History of Scrum




The approach was first described by Takeuchi and Nonaka in "The New New
Product Development Game" (Harvard Business Review, Jan-Feb 1986).
They noted that projects using small, cross-functional teams historically
produce the best results, and likened these high-performing teams to the
scrum formation in Rugby.
In 1990’s Ken Schwaber, Jeff Sutherland, John Scumuniotales, and Jeff
McKenna used the approach and called it Scrum.
Although Scrum was intended to be for management of software
development projects, it can be used in running maintenance teams, or as a
program management approach: Scrum of Scrums.
34
Scrum Process Flow
Scrum focuses an entire
organization on building
successful products. Without
major changes - often within
thirty days - teams are building
useful, demonstrable product
functionality.
Scrum can be implemented at
the beginning, in the middle, or
anytime in a product development
effort that is in trouble.
A Scrum project is controlled by
establishing, measuring and
trackng key controls (backlog and
risk). Controls are critical when a
software development has
uncertainty, unpredictability, and
chaos.
Backlog should start relatively high, get higher during
planning, and then get whittled away as the project
proceeds - either by being solved or removed, until the
software is completed.
Risk rises with the identification of backlog, issues, and
problems, and falls to acceptable levels as the software is
changed.
35
Scrum Development as a Pressure Cooker
The Planning and System Architecture
phases prepare the input that is placed in
the pressure cooker. The input consists of:
• Ingredients – backlog, objects,
packets, problems, issues
• Recipe – system architecture,
design, and prototypes
• Cooking sequence –
infrastructure, top priority functions,
next priority
The Closure phase removes the final
product (executable and documentation)
and prepares it for shipment.
The Consolidation Phase cleans up the
pressure cooker and ingredients for the
next batch.
36
Scrum Quiz



What is it?
History
When to use it?
37
Extreme Programming
38
Extreme Programming




What is it?
Best Practices
History
Take it to the Extreme
39
Extreme Programming (XP)




A deliberate and disciplined approach to software development that
stresses customer satisfaction by delivering software your
customer needs when it is needed.
Empowers developers to confidently respond to changing customer
requirements, even late in the life cycle.
Emphasizes team work. Managers, customers, and developers are all
part of a team dedicated to delivering quality software.
XP improves a software project in four essential ways
1.
2.
3.
4.

Communication – Programmers talk to their customers and team members.
Simplicity – They keep their design simple and clean.
Feedback – Testing and feedback starts on day one.
Courage – They respond to changing requirements and technology often to
delver the system as early as possible.
XP essentially takes existing "best practices" to extreme levels. For
example, the practice of TDD was used as early as NASA's Project
Mercury, in the early 1960s. Refactoring, modularity, bottom-up and
incremental design were described by Leo Brodie in his book published
in 1984.
40
XP Best Practices

Planning











User stories (use cases) are written.
Release planning creates the schedule.
Make frequent small releases.
The Project Velocity (amount of work
getting done) is measured.
The project is divided into iterations.
Iteration planning starts each iteration.
Move people around (cross train).
A stand-up meeting starts each day.
Fix XP (improve the process) when it
breaks.








Designing






Simplicity.
Choose a system metaphor (naming
standards) .
Use CRC cards (Class, Responsibilities,
Collaboration) for design sessions.
Create spike solutions (simple programs
to explore potential solutions) to reduce
risk.
No functionality is added early (focus on
today’s needs).
Refactor (let it go; rejuvenate obsolete
designs) whenever and wherever possible.
Coding

Testing



41
The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed
(code in twos at the same computer).
Integrate often but only one pair integrates
code at a time (version control).
Use collective code ownership (everyone
contributes).
Leave optimization (make it work, make
it right, then make it fast) till last.
No overtime (great idea if management
and customers agree!).
All code must have and pass all unit tests
before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the
score is published.
XP History




XP was created by Kent Beck in 1996 during his work as project leader
on the C3 payroll project at Chrysler.
In 1999, Beck wrote a book on the method: Extreme Programming
Explained.
Chrysler canceled the C3 project in 2000, and although some see that
initial failure as a problem with XP, the method had caught on in the
software engineering field.
As of 2007, a number of software-development projects continue to use
XP as their method.
42
Take it to the Extreme:
Make Your Customers Notice…
Change the way we program.

Keep it simple. Don’t be slick and clever. Software engineered to be
simple and elegant is more valuable than software that is complex and
hard to maintain. A typical project will spend about 20x more on people
than hardware.







A project spending $2M/yr on programmers will spend about $100k on technology. Say we
save 20% of the hardware costs by some very clever programming tricks. The source code
will be harder to understand and maintain, but we are saving 20% or $20k/yr.
If instead, we wrote our programs such that they were easy to understand and extend, we
could expect to save no less than 10% of our people costs = $200k, significantly more.
Really listen to your customers and act on their feedback. Too often
a customer will see a real opportunity for making a system useful after it
has been delivered. Use customer feedback while there is still time to
change functionality or improve user acceptance.
Co-locate and collaborate to improve communications and velocity.
Buddy-up (pairs) to reduce risk and increase quality. Two heads are
better than one.
Write and execute tests early and often. Automate tests so bugs don’t
get through twice.
Live with change, embrace change, no…Seek Change!
43
Extreme Programming



What is it?
History
When to use it?
44
Recap
So…is there anything really new under the sun?





Agile
The RUP
Scrum
XP
Waterfall
Is Deming still relevant?
Act
Plan
Check
Do
How do I do it?
 People: Education, training, and certification
 Process:



Set and manage expectations.
Prepare for change
Technology: Is it about Tools?




Agile – Version One, Serena, Axosoft
RUP – Rational Method Composer, ClearCase
Scrum – ScrumWorks, ScrumZ, Serena, Axosoft
XP – Version One, XPWeb
45
Organizational Project Management
Enterprise Governance: Leadership, Organizational Structures and Enablers, Policies
Project Portfolio Management
Strategic Alignment & Selection
Approval & Funding
Prioritization
Weekly
Regular
Program Management: PMO, Methodology, Standards, Processes, Tools, Stakeholder
Management, Performance Metrics & Measurement, Benefits Realization
Project Team
Meetings
•Tracking of Progress,
Status, Forecast
•Risks & Issues
Knowledge
Management
•Project Files
•Best Practices
•Lessons Learned
SOW
Time
Integration
Resources
Quality
Steering Group
Meetings
•Reporting of Progress,
Procurement Status, Forecast
•Risks & Issues
Escalation
Scope
Cost
Risks & Issues
Communications
Project Management Initiation – Planning – Execution (Monitor & Control) – Closing
Responsibility:
•Accountability
•Approvals
•Signoffs
Project Governance: Step Gate Reviews, Milestones, Risk & Quality Management
Traditional System Life Cycle: Planning – Requirements – Analysis & Design – Development – Implementation – Maintenance
Iterative System Life Cycle: Inception – Elaboration – Construction – Transition – Maintenance
46
Closing & Caveats









Expectations? Q&A? Bs&Cs? Evaluations? PDUs?
Agile – RUP – Scrum – XP – Waterfall explained?
To use or not? You decide.
My premise and bias: Traditional methods for 20+
years…maybe there is a better way?
Change is hard.
True leadership is rare.
There is no “Silver Bullet”.
There are no perfect People, Processes, or Tools.
Corporate cultures are full of “Organizational Inhibitors”.
david.sides@us.sogeti.com
47
Who & Why Sogeti?
40+ years of global experience –
global reach, local touch
Comprehensive service offerings to
solve client business & IT challenges
Complemented by our alliance
relationships with Microsoft, IBM and
others
Leveraging our global delivery
capabilities to keep client costs down
Quality delivery always
Industry-leading, knowledgeable,
experienced and certified professionals
in Project Management and IT
development (150+ PMPs)
We work with clients to develop and deploy unique solutions
to help them achieve their strategic business objectives.
David M. Sides, PMP david.sides@us.sogeti.com
Global expertise & local
proximity
16,000
worldwide
2000 in
USA
Benelux
UK
United States
Nordi
c
France
Central
Southern Europe Europe
Indi
a
A multi-national, premier provider
of IT
and project management services
Global reach, local touch
Sogeti USA locations
Seattle
Minneapolis
Des Moines
Chicago
Detroit
Cleveland
Omaha
Denver
Columbus
Dayton
Indianapolis
Ft. Collins
Kansas City
St. Louis
Cincinnati
New York
Baltimore
Washington DC
Phoenix
Dallas
Houston
2000 IT Professionals
in 23 locations across
the country
Tampa
Ft. Lauderdale