The Process cocktail

1
The Process cocktail
2
The Purpose of AD Project is

• To provide a suitable solution for users
• That consists of quality code
• And doesnt cost too much

3
This Leads To

• Technical Problem building quality code that
  satisfies the Users needs
• Budget Problem managing the project so that it
  doesnt cost too much to do so

4
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 these
5
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?
6
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

7
Relationships Between the Players
User
Requirements
Business Owner
Reporting, Monitoring
Customer
Develop Product
Developers
8
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
• ...

9
Process

• 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 youre
  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

10
Why do We Need a Process?
A process is needed because stakeholders have
various expectations for a software project, and
want some guarantee that they will get them

• 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

11
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 arent 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

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

13
Three Levels of Development
Users
Customers
Developers
14
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
15
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

16
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

17
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?
• Lets think about this for a minute

18
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

19
Delivering Functionality in an Agile Project
What we know to start
What we budget
MaxROI
What we should deliver
The Universe of Possibilities
20
RUP (Rational Unified Process)

• Process Framework
• Well Engineered
• Development Management

21
Perceptions of RUP
Manageable, traceable, visible, the way things
should be done
Heavyweight, boring, waste of time
22
RUP Principles
Jacobson
Kruchten

• Develop Software Iteratively
• Manage Requirements
• Use component-based Architectures
• Visually Model Software
• Verify Software Quality
• Control Changes to Software

• Use Case Driven
• Architecture Centric
• Iterative and Incremental
• Uses UML
• Can be Tailored to a Projects needs

23
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 youre on
  track (management touch points)
• Things change, so be iterative and incremental so
  that you can modify your plans as necessary

24
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

25
Cycles/Phases/Iterations
26
Lifetime is made of Cycles
Deliver v1.0
Deliver v2.0
27
Phases Concentrate on Different Levels of
Development
Business Level
Product Level
Development Level
28
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

29
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

30
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 (41)
• 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

31
XP (eXtreme Programming)

• Development Practices
• The Customer Drives
• Its all about the Code

32
Perceptions of XP
Cool, trusts the developers, lets me do my thing
Formalized hacking, waste of resources, no
management control
33
XP Principles

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

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

• Communication
• Simplicity
• Feedback
• Courage/Aggression

34
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

35
XP Activities

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

36
XP Roles

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

37
XP Practices
Business Level
Product Level
SmallReleases
AcceptanceTests
OnsiteCustomer
PlanningGame
Development Level
UnitTests
ContinuousIntegration
SimpleDesign
SustainablePace
RefactorMercilessly
CodingConventions
TestDrivenDevelopment
CollectiveCodeOwnership
PairProgramming
SystemMetaphor
38
XP Products

• Release Plan
• User Story
• Code
• Unit Tests
• Acceptance Tests

39
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

40
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

41
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)

42
Scrum

• Management Strategy
• Communication and Empowerment
• Team/Management Interactions

43
Perceptions of Scrum
44
Scrum Principles

• Built-in instability
• Change out of Chaos
• Self-organizing project teams
• Overlapping development phases
• Multi-learning
• Subtle control
• Transfer of learning

• Commitment
• Focus
• Openness
• Respect
• Courage

• Visibility
• Communications
• Remove Impediments
• No Interference

45
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
  theyre doing something real
• Short enough so that Management doesnt feel
  abandoned

46
Scrum Activities

• Sprint Planning
• Sprint
• Daily Scrum
• Sprint Review

47
Scrum Roles

• Scrum Master
• Product Owner
• Scrum Team
• Not much detail, because Scrum is a light-weight
  management process, not a development process

48
Scrum Practices

• Identify and Remove Impediments
• Identify Product Backlog
• Define Sprint Backlog
• No Interference, no Intruders, no Peddlers
• Frequent, First-Hand Observations

49
Scrum Products

• Sprint Backlog
• Release Backlog
• Product Backlog

50
Best of Breed Combinations

• Mix and match

51
Best of Breed Practices/Concepts

• These are the practices/concepts that I look for
  in a Projects process

Scrum
XP
RUP
Practice or Concept
??
?
?
Iterative and Incremental
?
??
Architecture-Centric
?
??
Validation-Centric
?
??
Developer/Customer Interaction
??
?
Developer/Management Interaction
?
?
?
Developer/Support Interaction
?
?
??
Business Owner Buy-In
??
?
?
Risk Management
?
??
Quality Code
?
??
Management Touch Points
?
??
Large Teams
?
??
Small Teams
?
??
Complex Projects
?
??
Use Cases
52
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

53
Cocktail 1 Large, Complex Projectwhat Im
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 Stakeholders fears
• Call the process Tailored RUP because thats
  what it is

54
Cocktail 1 what it looks like
Inception
Elaboration
Construction
Transition
Iteration 1
Iteration 2
Iteration 3
Iteration 4
Iteration 5
Iteration 6

• 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

55
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 teams
  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

56
Cocktail 2 what it looks like
Business Level
Use Cases
Small Releases
Product Level
AcceptanceTests
PlanningGame
OnsiteCustomer
No Interference, no Intruders, no Peddlers
Identify and Remove Impediments
Development Level
UnitTests
ContinuousIntegration
SimpleDesign
SustainablePace
RefactorMercilessly
CodingConventions
TestDrivenDevelopment
CollectiveCodeOwnership
PairProgramming
SystemMetaphor
57
Needs to Tasks Problem

• No matter what process you use, the fundamental
  technical problem is to analyze the users needs
  in order to determine development tasks

Business Level
Need
Product Level
Development Level
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
58
Needs to Tasks - RUP

• Here are the major steps in moving from a Users
  need to a collection of Developer Tasks in RUP

Business Level
Need
Detail a Use Case
Use Case
Product Level
Use Case Realization
Analyze a Use Case
Analyze a Class
Development Level
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
59
Needs to Tasks - XP

• Here are the major steps in moving from a Users
  need to a collection of Developer Tasks in XP

Business Level
Need
Magic Performed by Customer
Product Level
User Story
User Story
User Story
User Story
Iteration Planning Game
Development Level
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
60
Needs to Tasks Combined

• Heres what should it look like for the major
  steps in moving from a Users need to a
  collection of Developer Tasks

Business Level
Need
Use Case
Detail a Use Case
Product Level
Ever-Unfolding Story
User Story
User Story
User Story
User Story
Iteration Planning Game
Development Level
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
61
Principles Team Values

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

62
Principles Environment

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

63
Thats it!

• Thank you for not throwing things