1

Debunking “Bleeding Edge” Methodologies A to Z:

Agile – RUP – Scrum – XP

www.us.sogeti.com

David M. Sides, PMP, OPM3, ITIL

Vice President, Sogeti

Project Consulting Practice

Introduction & Caveats

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

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.

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

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? February 11-13, 2001

Where? The Lodge at Snowbird, Utah

Why? They felt the need for an alternative to “documentation-driven, heavyweight software

development processes”

How? They skied, ate, drank, and came to terms, naming themselves “The Agile Alliance”

Output? The Agile Software Development Manifesto

7

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

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?

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

Ask yourself these questions…

Test-driven Design/Development (TDD)

10

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.

Agile SDLC

11

Agile Unified Process (AUP)

12

Agile Change Management

13

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.

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

16

The Rational Unified Process

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?

19

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.

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

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

6 Key Principles of Business-Driven Development

History of RUP

22

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.

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

24

Performed in iterations – Elaboration-Construction-Transition

Rational Unified Process

25

Look familiar?

Defining What When

RUP

• Prioritize use cases

• By stakeholder priority

• And by architectural coverage

26

Components of a Use Case Diagram

27

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

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

29

PM gaps to be filled: Integration, Scope (Change Mgt), Cost, Resource Team Building, Communications, Procurement

The RUP Quiz

What is it? History When to use it?

30

31

Scrum

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

34

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.

Scrum Process Flow

35

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.

Scrum Development as a Pressure Cooker

36

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.

Scrum Quiz

What is it? History When to use it?

37

38

Extreme Programming

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 ways1. Communication – Programmers talk to their customers and team members.2. Simplicity – They keep their design simple and clean.3. Feedback – Testing and feedback starts on day one.4. 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.

41

Coding 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!).

Testing 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…

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

Change the way we program.

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? 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

PlanAct Do Check

Organizational Project Management

46

Project Portfolio ManagementStrategic Alignment & Selection

Approval & FundingPrioritization

Project Team Meetings

•Tracking of Progress, Status, Forecast•Risks & Issues

Steering GroupMeetings

•Reporting of Progress, Status, Forecast•Risks & Issues Escalation

Weekly

Knowledge Management•Project Files•Best Practices•Lessons Learned

Regular

Enterprise Governance: Leadership, Organizational Structures and Enablers, Policies

Traditional System Life Cycle: Planning – Requirements – Analysis & Design – Development – Implementation – Maintenance

Project Governance: Step Gate Reviews, Milestones, Risk & Quality Management

Responsibility:•Accountability•Approvals•SignoffsProject Management Initiation – Planning – Execution (Monitor & Control) – Closing

Program Management: PMO, Methodology, Standards, Processes, Tools, Stakeholder Management, Performance Metrics & Measurement, Benefits Realization

Quality

CommunicationsRisks & IssuesScope

SOW

Time

Cost

Resources ProcurementIntegration

Iterative System Life Cycle: Inception – Elaboration – Construction – Transition – Maintenance

Closing & Caveats

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”.

47

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?

david.sides@us.sogeti.com

Who & Why Sogeti?

We work with clients to develop and deploy unique solutions to help them achieve their strategic business objectives.

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)

David M. Sides, PMP david.sides@us.sogeti.com

Global expertise & local proximity

United States Southern Europe

France

Benelux

Central Europe

Nordic

UK

A multi-national, premier provider of IT

and project management servicesGlobal reach, local touch

India

2000 in USA

16,000 worldwide

Sogeti USA locations

Houston

Dallas

New York

Baltimore

Minneapolis

Des Moines

Omaha

Chicago

St. Louis

Indianapolis

Detroit

Columbus

Cleveland

Dayton

Seattle

Cincinnati Washington DCKansas City

Phoenix

Ft. Collins

Tampa

Ft. Lauderdale

Denver

2000 IT Professionals in 23 locations across

the country