The Process cocktail

The Purpose of AD Project is…

To provide a suitable solution for users…That consists of quality code…

And doesn’t cost too much

This Leads To• Technical Problem – building quality code

that satisfies the Users’ needs• Budget Problem – managing the project

so that it doesn’t cost too much to do so

The Technical Problem has Three Parts

• Requirements– Determine What the Software has to do…– Challenge: Satisfy the Users

• Production– Actually Build the Software – Challenge: Deliver Quality Product

• Maintenance– Modify Software to satisfy new requirements– Challenge: Maintain Quality

Agility has changed the ways we do theseAgility has changed the ways we do these

The Budget Problem has Many Issues

• How much do I want to spend to solve the Users’ problem?

• Do my developers know how to solve the problem?

• Are we making progress? Are we wasting money? Are we on schedule?

• Is the product good enough? CMM? Are other stakeholders going to be satisfied?

How do we answer these questions?How do we answer these questions?

Players• User Community

– Has problems to be solved– Usually disorganized, chaotic, group

• Customer Team– Provides requirements and validation– Should speak with “one voice”

• Developers– Actually builds the stuff– Lots of different roles here

• Business Owner– Manages resources and money– Often ignored in Development

Process…

Relationships Between the Players

Developers

Customer

User

Business Owner

Develop Product

Requirements

Reporting, Monitoring

The Processes we are Discussing

• The three processes being discussed today are modern ones that enable agility– Rational Unified Process (RUP) – Rational (IBM)– eXtreme Programming (XP) – Kent Beck– Scrum – Ken Schwaber, Mike Beedle

• These are not the only ones, but are some of the most common. Others include:– Dynamic Systems Development Method (DSDM)– Crystal Methodologies – Alistair Cockburn– Feature Driven Development (FDD) – Peter Coad– Adaptive Software Development – Jim Highsmith– ...

• Every software project has a process: somewhere between “hack it out” and “Space Shuttle software”

• Basically, processes tell you what to do, and when to do it. – Plan-driven: you determine up-front what you’re

going to do, and follow it– Evaluation-driven: at any given time figure out

what the next thing to do is, and do it– Combination: have an initial plan, continuously

updating as needed

Process

Why do We Need a Process?

• Quality code• Provide business value• Follow-on work• Correct code• Quality product offering

– Training– Help desk– Etc– …

• Management visibility • Quality of life• Accurate progress

reports• React to changing

requirements• CMM/ISO• Test Coverage

A process is needed because stakeholders have various expectations for a software project, and want some guarantee that they will get them

Formal Process vs. Team Discipline

• There is a natural tension between having a disciplined team and having formal process

• The more disciplined the team is, the less formal process you need

• Most people aren’t disciplined enough, so some process is usually necessary

• Process is useful, but we must look at why we want the process

• Every Project is different…

What Defines a Process?

• Principles/Fears – what guides you?• Activities – what do you do?• Roles – who does it?• Practices – how do you do it?• Products – what gets produced (and

persisted)?

Three Levels of Development

Business Level

Product Level

Development Level

BusinessNeedUsersUsers

CustomersCustomers

DevelopersDevelopers

Evaluating a Process

• Understand the Process: what are the Principles/Fears, Activities, Roles, Practices, and Products?

• Determine the Coverage: how well does the process span the three levels of development?

• Use Your Judgment: does this process meet your needs, for this team, for this project, at this time?

Always remember: there is no “one size fits all,” silver bullet, process out there…Always remember: there is no “one size fits all,” silver bullet, process out there…

Agility is…• The ability to move faster than those things that can harm

your project…• The ability to keep up with relevant changes…

– In requirements– In knowledge of our system– In environment

• Agility is only relevant in a context…

These Things Include…

• Changing Requirements– New Functionality– Learn more about system

• Changing Priorities– Different Stakeholders– New Situations

• Changing Environment– New OS, Languages, etc

• Changing Budgets– Fewer Developers– Do More with Less…

• More…

In Order to Succeed You Need Something to Work With

• All managers know that you need “float” in order to make a project work

• When developing software, where is the “float” that we have to work with?

• Let’s think about this for a minute…

Scope, Functionality and Robustness

• Scope measures “how much” is in the system – the product of functionality and robustness

• Functionality is based on the problems being solved or goals being addressed– some is more important than others– Thought of as the “width” of the system– Described “mile wide – inch deep”

• Robustness measures the “depth” at which functionality is handled– Secondary versions– Error recovery– Business Rules– Refinements– The actual depth…– …

Delivering Functionality in an Agile Project

What we know to start

What we budget

What we should deliver

The Universe of Possibilities

MaxROI

RUP (Rational Unified

Process)

Process Framework

Well Engineered Development Management

Perceptions of RUP

Manageable, traceable, visible, the way things

“should be done”

Heavyweight, boring, waste of

time

RUP Principles

• Use Case Driven• Architecture Centric• Iterative and

Incremental• Uses UML• Can be Tailored to a

Project’s needs

• Develop Software Iteratively

• Manage Requirements• Use component-based

Architectures• Visually Model

Software• Verify Software

Quality• Control Changes to

Software

Jacobson Kruchten

The Real Motivation of RUP

• Making mistakes is expensive, so make sure you know what you want to do before you do it

• A good solid system has a good solid architecture

• Plans and Budgets are hard to follow, so you need many interim deliverables to make sure you’re on track (management “touch points”)

• Things change, so be iterative and incremental so that you can modify your plans as necessary

RUP Activities

• Lifetime of a system is made up of Cycles– Development, improvement, maintenance

• Phases– Inception, Elaboration, Construction, Transition

• Iteration– Project Management, Analysis, Requirements,

Design, Code, Test

• Activity

Cycles/Phases/Iterations

Lifetime is made of Cycles

Deliver v1.0

Deliver v2.0

Business Level

Product Level

Development Level

Phases Concentrate on Different Levels of

Developmentkickoff

InceptionInception

ElaborationElaboration

ConstructionConstruction

TransitionTransition

delivery 1.0

ElaborationElaboration

ConstructionConstruction

TransitionTransition

delivery 2.0

InceptionInception

RUP Roles

• Project Manager• Business-Process

Analyst• Business Designer• Business Reviewer• System Analyst• Use Case Specifier• Architect• User Interface Designer• Requirements Reviewer

• Designer• Database Designer• Architecture Reviewer• Design Reviewer• System Integrator• Implementor• Code Reviewer• Test Designer• Integration Tester• Performance Tester

RUP Practices• The actual practices are

pretty much left up to the developer

• However, there are lots of diagrams like these that show how the activities fit together…

Some RUP Products• Vision Document/ Business

Case• Glossary• Software Development Plan

– Risk List– Project Plan– Measurement Plan– CM Plan– Integration Build Plan– Test Plan

• Iteration Plans• Iteration Assessments• Use Case Model• Analysis Model• Design Model• Deployment Model• Implementation Model• Test Model

• Architecture Description (4+1)– Use case view– Analysis view– Design view– Deployment view– Implementation view

• User Interface Prototype• Interfaces• Analysis Packages• Design Subsystems• Implementation Subsystems• Components• Test Cases• Test Procedures• Test Components• Test Evaluations• Defect Lists

XP (eXtreme Programming

)

Development Practices

The Customer DrivesIt’s all about the Code

Perceptions of XP

Formalized hacking, waste of resources, no management control

Cool, trusts the developers, lets

me “do my thing”

XP Principles• Rapid Feedback• Assume Simplicity• Incremental Change • Quality Work

• Fine Scale Feedback• Continuous Process• Shared Understanding• Programmer Welfare

• Communication• Simplicity• Feedback• Courage/Aggression

The Real Motivation of XP

• Good clean code is easy to change• The Code is the only thing you can

believe• Customers make all business decisions• Developers make all technical decisions• Make iterations as short as possible so

that Customer can drive with rapid feedback

XP Activities

• Produce User Stories• Release Planning• Planning Game (iteration planning)• Development• Spike Solution• Run Acceptance Tests (unit &

functional)

XP Roles

• Programmer • Customer• Tester • Coach (process QA) • Tracker • Manager (supplies Pizza)

Business Level

Product Level

Development Level

XP Practices

CollectiveCodeOwnershipCollectiveCodeOwnership

UnitTestsUnitTests

PairProgrammingPairProgramming

ContinuousIntegrationContinuousIntegration

RefactorMercilesslyRefactorMercilessly

SimpleDesignSimpleDesign

CodingConventionsCodingConventions

SustainablePaceSustainablePace

AcceptanceTestsAcceptanceTests

PlanningGamePlanningGame

SystemMetaphorSystemMetaphor

OnsiteCustomerOnsiteCustomer SmallReleasesSmallReleases

TestDrivenDevelopmentTestDrivenDevelopment

XP Products

• Release Plan• User Story

•Code• Unit Tests• Acceptance Tests

Use Case versus User Story

• Use Case: Describes how an Actor interacts with the system to achieve a Goal– Focus is on user and validation– Tells a “complete story”

• User Story: A bite-size bit of functionality that has business value and can be developed in a few days– Focus is on developer and production– Part of a “complete story”

Use Case versus User Story• Use Case: Logon to System

– Actor: ATM Customer – Scope: ATM Machine – Description: After swiping the ATM Card, the user is asked for a

password. The system verifies that the card is legitimate and that the password corresponds to the card. The user is then given access to all the other ATM commands. The user is given three chances to enter a correct password; after the third time the ATM Card is kept by the machine.

• Sample User Stories– Display welcome screen until user swipes ATM Card – Display login screen until password is entered – Verify that ATM card is legitimate– Verify the password is legitimate– Implement “three strikes” algorithm for password entry– Swallow card if card is illegitimate– Swallow card if password fails– Return Card if Network Goes Down– …

User story - Sashimi method

• Story: Ok on Password screen gives full capability to anybody

• Story: fixed passwords for different capability suites

• Story: "three Strikes" algorithm• Story: Screen Capabilities by ID – still fixed

password for each capability• Story: Different Password for each ID• Story: Full Password capability (different

password per ID per capability suite)

Scrum

Management Strategy

Communication and Empowerment

Team/Management Interactions

Perceptions of Scrum

Huh?!

Scrum Principles

• Commitment• Focus• Openness• Respect• Courage

• Visibility• Communications• Remove

Impediments• No Interference

• Built-in instability• Change out of

Chaos• Self-organizing

project teams• Overlapping

development phases

• Multi-learning• Subtle control• Transfer of learning

The Real Motivations of ScrumMy View…

• Changes may be hard to make, so identify them as soon as possible

• Developers know how to develop, so just stay out of their way and let them do it

• Make 30-day iterations for two reasons:– Enough heft to allow Developers to believe

they’re doing something real– Short enough so that Management doesn’t

feel abandoned

Scrum Activities• Sprint

Planning• Sprint• Daily Scrum• Sprint Review

Scrum Roles

• Scrum Master• Product Owner• Scrum Team

• Not much detail, because Scrum is a light-weight management process, not a development process…

Scrum Practices

• Identify and Remove Impediments• Identify Product Backlog• Define Sprint Backlog• No Interference, no Intruders, no

Peddlers• Frequent, First-Hand Observations

Scrum Products• Sprint Backlog• Release Backlog• Product Backlog

Burndown Graph

020406080

100120140160180

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

days

wo

rk r

emai

nin

g

“Best of Breed”

Combinations

Mix and match

“Best of Breed” Practices/Concepts

• These are the practices/concepts that I look for in a Project’s process…

Risk Management

Quality Code

Management “Touch Points”

Large Teams

Small Teams

Complex Projects

Use Cases

Developer/Support Interaction

Developer/Management Interaction

Developer/Customer Interaction

Validation-Centric

?Architecture-Centric

Iterative and Incremental

ScrumXPRUPPractice or Concept

Business Owner Buy-In

Two Sample Cocktails

• Top-Down Process– Large, complex project– Management centered, ceremony needed

• Bottom-Up Process– Small e-commerce project– Developer centered, keep as simple as possible

• Each project must mix its own cocktail

Cocktail 1 – Large, Complex Project

what I’m thinking…• Start with RUP• Use 1-month iterations, a la Scrum• Use XP Practices as much as possible

– System Analyst or Architect acts as XP Customer for Construction Phase

– Adapt XP Practices as I can for other Phases

• Handle Team/Management interaction in Scrum fashion

• Tailor out as much else as I can, without running foul of any major Stakeholder’s fears

• Call the process “Tailored RUP” because that’s what it is…

• Inception– Develop use cases in pairs (analyst/architect + user)– Do just enough to develop a backlog to start with

• Elaboration– Develop architecture in pairs (analyst/architect + lead

developer)– Continue to work on Use Cases

• Construction– Multiple XP teams developing different parts of the architecture– Scrum Master for each team – with Project Manager over all…– Cross-team pairing for interface and infrastructure issues

• Transition– Integration of different parts of the architecture– Pairing to fix bugs and integrate

Cocktail 1 – what it looks like

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Inception Elaboration Construction Transition

Cocktail 2 – Small e-commerce project

• Start with XP• Use 1-month iterations, a la Scrum (shorter if your tools

can handle it and the team wants to…)• Add other Scrum practices to manage the team’s

relations to management– Scrum Master– Protect/Insulate the team

• Add Use Cases from RUP– Architect pairs with Marketing Staff to develop them– Marketing “sells” use cases to the world– Architect converts use cases to user stories for the developers

• Call the process “XP++” or “Scrum with an XP Center”

Cocktail 2 – what it looks like

Business Level

Product Level

Development Level

CollectiveCodeOwnershipCollectiveCodeOwnership

UnitTestsUnitTests

PairProgrammingPairProgramming

ContinuousIntegrationContinuousIntegration

RefactorMercilesslyRefactorMercilessly

SimpleDesignSimpleDesign

CodingConventionsCodingConventions

SustainablePaceSustainablePace

AcceptanceTestsAcceptanceTestsPlanningGamePlanningGame

SystemMetaphorSystemMetaphor

OnsiteCustomerOnsiteCustomer

Small ReleasesSmall Releases

TestDrivenDevelopmentTestDrivenDevelopment

Use CasesUse Cases

Identify and Remove ImpedimentsIdentify and Remove Impediments No Interference, no Intruders, no PeddlersNo Interference, no Intruders, no Peddlers

Needs to Tasks Problem• No matter what process you use, the

fundamental technical problem is to analyze the user’s needs in order to determine development tasks

Business Level

Product Level

Development LevelTaskTaskTaskTaskTaskTask

TaskTaskTaskTaskTaskTask

Need

Needs to Tasks - RUP

• Here are the major steps in moving from a User’s need to a collection of Developer Tasks in RUP…

Business Level

Product Level

Development LevelTaskTaskTaskTaskTaskTask

TaskTaskTaskTaskTaskTask

Need

Use CaseDetail a Use Case

Analyze a Use CaseUse CaseRealization

Analysis ClassesAnalyze a Class

Needs to Tasks - XP

• Here are the major steps in moving from a User’s need to a collection of Developer Tasks in XP…

Business Level

Product Level

Development LevelTaskTaskTaskTaskTaskTask

TaskTaskTaskTaskTaskTask

Need

User StoryUser StoryUser StoryUser Story

Magic Performed by Customer

Iteration Planning Game

Needs to Tasks – Combined

• Here’s what should it look like for the major steps in moving from a User’s need to a collection of Developer Tasks

Business Level

Product Level

Development LevelTaskTaskTaskTaskTaskTask

TaskTaskTaskTaskTaskTask

Need

User StoryUser StoryUser StoryUser Story

Iteration Planning Game

Use CaseDetail a Use Case

Ever-Unfolding Story

Principles: Team Values

• Cooperation • Communication • Trust • Honesty • Respect • Courage/Aggression • Quality work • Play to win

Principles: Environment

• Available Customer • Source Code Management • Coding Standards • Continuous Integration • Facilitate Communications • Information Radiators • Team Room

That’s it!

• Thank you for not throwing things