Cockburn Classification
Cycles and Ceremony
Few documentations
Few steps
… Ceremony
SCRUM
XP
INCEPTION
Purpose:
High level objectives,
business case, vision, and
scope defined and
agreed.
10% of significant
requirements defined in
detail.
Identify key risks.
Estimate elaboration
effort.
Possible Activities:
Requirements workshop.
Start Vision and Risk List.
Use case model and
supplementary specs.
Prototyping.
https://www.slideshare.net/ERICEV/rup-2248862
Common Mistakes in
Implementing UP
❑ Software Architecture Document (SAD) “finished” before end of elaboration.
❑ Not conforming to the official UP workproduct names or phase names.
❑ Iterations too long. Should only be two to six weeks.
❑ Iterations are not timeboxed. As in Scrum and XP, redefine goal rather than time.
❑ Iteration doesn’t end in an integrated and tested baseline.
❑ Each iteration ends in a production release.
❑ Elaboration phase goal is to create throwaway prototype.
❑ Development Case too complex; too many workproducts.
❑ Predictive planning.
❑ Must do LOTS of modelling and UML diagrams and use a CASE tool.
Key Practices
More sequential
Criticality (defects cause
UP is suitable for
projects for all sizes
and criticality
❑ Develop in short timeboxed iterations.
Examples of UP projects
loss of…) ❑ Program high risk and high value elements early (such as the core architect),
(no iterations) UP Large - Canadian Automated Air Traffic Control Systems Medium - Ogre Nextgen Economic Modelling System
preferring re-use of existing components. ❑ Ten years, 400 people, Ada and C++. An L400 life ❑ Two years, 15 people, Java Technologies, an E20
Life
L6 L20 L40 L100 … ❑ Ensure delivery of value to customers. critical project on the Cockburn classification. project on the Cockburn classification.
(L) ❑ Decision Support System used by oil/gas asset holders
❑ Accommodate change early in the project. ❑ A large test bed for the practices that later known as
❑ Work together as one team. Rational Unified Process (RUP). The chief architect (eg, potential oil fields).
Essential E6 was Dr. Kruchten (who drove the adoption of the ❑ Development involved 19 iterations that were on
Cycles
E20 E40 E100 …
Money(E) practices), also the lead architect of the RUP. average were four weeks.
More documentations
Six Best Practices ❑ Included the Scrum practice of demonstration to
UP
❑ Was first attempted as a “waterfall” project, failed,
Severity
Formal steps
… and then restarted under the new process direction external stakeholders at the end of each iteration.
Discretionary D6 D20 D40 D100 … ❑ Prime developer: Valtech USA.
Money(D) of Kruchten as an iterative project.
❑ Timeboxed iterations (two to six weeks). ❑ Prime Developer: Raytheon Systems Canada.
❑ Program high risk and high value elements early (such as the core architect), Originally, Hughes Canada Systems Division. Small – QUICKcheck point-of-sale
Comfort (C)
C6 C20 C40 C100 … preferring re-use of existing components. ❑ One year, six people, Java technologies.
Unified Process ❑ Continuously verify quality ❑ A self-checkout POS system for grocery stores.
1-6 7-20 21-40 41-100 … ❑ ❑ Prime developer: Kyrus.
(UP) 1
Visual modelling (even a little) before programming:
▪ Sketches of UML and then photographed.
Project size ▪ Regular reverse engineering (generate diagrams from code) to gain big-picture view of
software.
❑ Manage requirements.
❑ Manage change.
More short iterations (5 days)
Life cycle Non-Software Workproducts Roles Practices
One may support many
disciplines; UP encourages
adoption of practices from
ELABORATION CONSTRUCTION TRANSITION other methodologies.
Requirements Design
(iterations) (iterations) (iterations) Customer Development
Summary of objectives, Design Object model (static and dynamic)
Requirements Design
Purpose: Purpose: Purpose: Vision
Core, architectually System completed (in System identified as ready features, business case. Model of the packages and objects. Maybe Repeated
significant parts of system small parts) and ready for for deployment. reverse engineered from code. Early architecture,
Manage prefer existing
coded and tested. deployment.
All detailed requirements Implementer Tester requirements. components.
Supplementary not elsewhere. Features, Data Writes tests, Writes and
80% of major Efficient and predictable Deploy system. Spec. rules, constraints, non- Model Stakeholder designs, code. develops system
requirements evolved and development, building on functional, etc. Customers, product managers,… tests.
defined in detail. the stable architecture Refactors. Requirements
coded in elaboration. workshops. Model Visually.
Significant risks identified Stories or scenarios of SW Arch. Short learning aid to
Use-case Model
and mitigated. using the system. Document understand the system.
Emphasizes functional
Enough stability and SW Architect Systems Analyst
information to estimate
requirements.
Establishes and Requirements Implementation Test and Verification
duration and effort. maintains analysis.
architectural vision.
Implementation Test & Verification Coding Continuously
Possible Activities: Possible Activities: Possible Activities: Standards. verify quality.
Testing, programming, Testing, programming, Beta or release candidate
designing in short designing in short testing and feedback. Test Plan
iterations. iteration. Database User Interface
Designer Designer
Requirements workshops, Stakeholder evaluation Final programming and
refining the vision. and steering; ideally only documentation.
minor requirements Configuration & Change Management Other
Refining the environment changes. Educating, marketing,….
Project Management Project Management Configuration and Change
(process and technical). Management Environment Management Environment
SW Dev. Overall and composite Customised process
Create all documents. Deployment (system goes Dev Case
Plan plan, Milestones, description. The Manage
live).
resources, etc. workproducts and requirements.
Alpha testing.
practices for the project. Project Manager Graphic Artist
The detailed plan for the Requirements
Iteration Develop workshops.
next iteration, not a plan of Change A uniform way to track all Manage change.
Plan iteratively.
all iteration. Request requests for work
(enhancements, defects,
etc). Process Engineer
Risk with severity and Leads the definition and Early architecture,
Risk List refinement of the Technical Writer
mitigations. prefer existing
Development Case. components.
UP Workproducts You don’t Understand UP If You…
❑ Often misunderstood.
❑ Perception: Agile people call UP Heavy weight (as too many ❑Think UP = requirements design implementation.
documentation). ❑Think Inception = Analysis.
❑ Fact: Not all documents are needed, and should be tailored depending
on projects. ❑Think Elaboration = Design + Requirement Analysis.
❑ Provides common vocabulary. ❑Think Construction = Programming after design.
❑Think Transition = Testing.
❑ Provide information abstraction which can take many forms:
❑ Risk list as a poster on the wall. ❑Want to do most requirements analysis or design before programming.
❑ Software Architect Document can be a video. ❑Test near end of project.
❑Define iterations in months rather than weeks.
❑ Design model can be a UML whiteboard sketches captured on a
digital camera. ❑Create Software Architecture Document before the end of elaboration.
Larman, C. (2004). Agile and interactive development: A managers guide. Boston: Addison Wesley.
 Examples of Projects with
Significant Scrum
Large - IDX Web-enabled benefits suite.
❑ One year, 330 people across multiple related projects. An E300 project on
the Cockburn classification.
Cycles and Ceremony Cockburn Classification Key Practise ❑ A suite of 15 related applications were developed within one year of
adopting Scrum, after three years of struggle to deliver one application.
Scrum is suitable for ❑ Self-directed and self-organising team.
More sequential
(no iterations) Criticality (defects cause projects for all sizes ❑ Once chosen, no external addition of work to an iteration. ❑ Prime developer: IDX.
and criticality
loss of…)
SCRUM ❑ Daily stand-up meeting with special questions.
Life ❑ Usually 30-calendar day iterations. Medium – Caremark.
(L) L6 L20 L40 L100 … ❑ Demo at end of each iteration. ❑ Four months, 20 people, an E20 project on the Cockburn classification.
❑ Each iteration, client-driven adaptive planning.
Cycles

Essential E6
❑ After two years of struggle, 160 staff at its height, and no delivery, Scrum
Few documentations More documentations E20 E40 E100 …
Few steps Formal steps Money(E)
UP
was introduced with a reduced team size of 20 developers (10 new
… Ceremony …
hires). In four months, a successful production release was created.

Severity
SCRUM Discretionary
Money(D)
D6 D20 D40 D100 …
Scrum Daily Meetings ❑ Prime developer: Caremark and consultants.

Unified Process Comfort (C)

C6 C20 C40 C100 … ❑ Length: 15 to 20 minutes for 7-10 people.
❑ Other members can attend (chicken) but not talk. Small – Individual Personal NewsPage
(UP) 1-6 7-20 21-40 41-100 …
XP
❑ Held next to a whiteboard. ❑ One month, eight people, a C20 project on the Cockburn classification.
Project size
❑ Questions asked: ❑ After nine months without delivery, Scrum was adopted, and a usable
1. What have you done yesterday? production release emerged after one 30-day iteration. After five months
More short iterations (5 days)
2. What will you do today? of releases, most of the original goals were achieved.
3. What blocks you from achieving the next iteration goal? ❑ Prime developer: Individual Inc.

Life cycle Non-Software Workproducts Roles Practices

PRE-GAME DEVELOPMENT RELEASE Requirements Design Requirements Design

Customer Development
Repeated
Vision
PLANNING STAGING Pregame
Planning.
High Level
Design Phase.
Purpose: Purpose: Purpose: Purpose: Product Owner
Repeated Scrum Team
Establish the Identify more Implement a system Operational deployment. Work on the Sprint (iteration)
vision, set requirements and ready for release in a One person who is responsible for
Backlog. Sprint
Product & All items for the product. creating and prioritizing the Product
expectations and prioritise enough for first series of 30-day Planning.
Release The Release Backlog is a Backlog. Sprint
secure funding. iteration. iterations (Sprints). There is explicitly no other title
Backlog. subset. Review
Chooses the goals (from the Product than “team member”.
Activities: Activities: Activities: Activities: Includes features, use Backlog) for the next Sprint.
Write vision, Planning Sprint planning meeting Documentation. cases, enhancements,
budget, initial each iteration, defining Implementation Test and Verification
defects, technologies Along with other stakeholders,
Product Backlog Exploratory design and the Sprint Backlog and Training. reviews the system at the end of
and estimate prototypes. estimates. each Sprint.
items. Marketing and sales.
Daily Scrum meetings. Sprint
Exploratory design Implementation Review
and prototypes. Sprint Review.
Test & Verification Management Other

Scrum Master
50 % developer, not just management.
Project Management Configuration and Change
Project Management Configuration & Change Knows and reinforces the project and
Management Environment
iteration vision and goals.
Management Environment http://www.stickpng.com/img/animals/chickens/chicken-brown
Don’t Add Chickens Pregame
Backlog Estimate of work remaining to Iteration. and Pigs. Planning.
Ensures Scrum values and practices followed. Chickens
Graph versus days. Common Room
Everyone else can observe, but not interfere Daily Build.
Mediates between Management and Scrum Scrum (preferred).
or speak during an iteration. Self- Sprint
Team. Master
directed Planning.
Tasks for the iteration. Firewall.
Sprint Note: This is a bacon and egg story. The pigs are the Scrum team and self-
Listens to progress and removes members holding the meeting and their stake is high (think bacon
Backlog. Granularity 4-16 hours. and pig – pig has to die for the bacon to be served). Chickens have organising
impediments. little to risk – only need to provide eggs, their lives are not at risk. Daily team.
So chickens can attend but not speak, not even the CEO. Unless Scrum. Sprint.

Common Mistakes in Product & Release

Backlog
Conducts the Daily Scrum.

Conducts the Sprint Review (demo).

the management (CEO, etc) give feedback or provide points
relevant to the team’s work.

Decisions in
Blocks
Gone in 1

Implementing Scrum
1 hour. Teams in 7.
Day.

❑ Not a self-directed team; managers or Scrum Master direct or organise

the team.
❑
❑
No daily update of the Sprint Backlog by members or daily tracker.
New work added to iteration or individual. Facts vs Fantasy
❑
❑
Product Owner not involved or doesn’t decide.
No Sprint Review. ❑Scrum practitioners reported that they put in practice You don’t Understand Scrum If You…
❑ Many masters. the “ideals of Scrum in real life. ❑ Think a manager or Scrum Master tell the team what to do or how to solve its problem.
❑ Documentation is bad – still need documentation but only if it adds ❑ Create a plan with exact number of iterations and what will occur in each and think you CAN
values. ❑Most common problems: enforce it.
❑ Design or Diagramming is bad. ▪ team members were asked to perform tasks outside the iteration. ❑ Create a PERT chart or other plan of dependent, ordered tasks with estimated durations.
❑ Only brief some members in the team.
▪ Management attempts to direct or organise the team or solve (unasked) its
❑ Scrum meeting is too long or unfocused. Must be on Scrum questions. problems.
❑ Scrum Masters fail to regularly reinforce the project Vision and Sprint
goals, and the team drifts……..

Larman, C. (2004). Agile and interactive development: A managers guide. Boston: Addison Wesley.
 Cycles and Ceremony
More sequential
(no iterations)
Cockburn Classification
XP 12 Key Principles Story Cards Examples of Projects with
Criticality (defects cause ❑ Planning – based on user stories.
loss of…)

Life
XP is suitable for smaller
projects that are not life
❑
❑
Testing – thorough testing at every step.
Pair Programming – watch, inspect, trade off.
❑

❑
User stories: features, fixes, non-
functional requirements.
Written in one day to three weeks.
Significant XP
L6 L20 L40 L100 … critical.
❑
Large - Atlas leasing system.
(L) ❑ Simple Designs – Agile modeling principles. NOT use cases.
❑ Three years, 60+ people, Java technologies. An E100 project on the
Cycles

Kent Beck (creator of XP) argued that XP

Few documentations More documentations XP can scale, but so far, there is no

evidence.
❑ Refactoring – redo and cleanup as you go. Cockburn classification.
Essential
Few steps
Ceremony
Formal steps
Money(E)
E6 E20 E40 E100 … ❑ Owning the code collectively – egoless development, ❑ Fully adopted practices: simple design, testing, frequent refactoring,
… …
anyone can review and improve code. collective code ownership, continuous integration.

Severity
Front of Card
SCRUM
Discretionary D6 D20 D40 D100 …
❑ Continuous integration – grow the software continuously. Back of Card
❑ Pair programming attempted but did not last.
UP
Money(D) ❑ On-site customer – get sign-off as you go. ❑ No on site customer.
Unified Process ❑ System metaphor – what should the final system look like. http://www.agilemodeling.com/artifacts/userStory.htm ❑ Prime developer: ThoughtWorks.
C6 C20 C40 C100 …
(UP) Comfort (C) ❑ Small releases – turn over to user frequently (one to two
XP weeks if possible). Medium – Orga security incident-response.
1-6 7-20 21-40 41-100 …
❑ Forty-hour work week – don’t overload the developers. ❑ One year, 25 people. A D40 project on the Cockburn classification.
Project size
❑ Coding standards – follow standards for code. ❑ Fully adopted practices: most practices, with the exception of small,
More short iterations (5 days) frequent releases as this was a commercial product.
❑ Prime developer: Symantec.
Life cycle
Small – C3 payroll
EXPLORATION PLANNING ITERATIONS PRODUCTIONISING MAINTENANCE ❑ One year, 10+ people. An E20 project on the Cockburn classification.
TO FIRST ❑ Fully adopted practices: this was the original project that defined XP,
RELEASE coached by Kent Beck and Ron Jeffries. All practices were adopted.
Purpose: Purpose: Purpose: Purpose: Purpose: ❑ Prime developer: Chrysler.
Enough well-estimated Agree on date and Implement a tested Operational deployment. Enhance, fix.
story cards for first stories for first system ready for
release. release. release. Build major release.

Ensure feasibility.

Activities: Activities: Activities: Activities: Activities:

Prototypes. Release Planning Testing and Documentation. May include these
Roles Practices
Exploratory proof of
Game. programming.
Training.
phases again, for
incremental releases. Non-Software Workproducts
technology Story card writing Iteration planning
programming. and estimating. game. Marketing
Requirements Design Requirements Design
Customer Development
Story card writing and Tasks writing and … CRC cards Repeated
estimating. estimating. (week 8). System Frequent
Repeated Planning
metaphors. refactoring.

Common Mistakes in
game.
Paper index cards on which Responsibilities
Attributes
Collaborating
Story cards. are written brief feature classes Customer
Programmer Tester
requests (not use cases).

Implementing XP They are just “a promise to

talk” with the customer for
details. Each story to be
completed within 2 – 10
Write user stories and acceptance
tests.

Picks stories for release and

Writes tests, designs,
code.

Refactors (modify
Helps customer write
and develop tests. Acceptance
testing.
Onsite
customer.
Simple design.

source code without

❑ No on-site customer; rather, use specification written for the next iteration. days. iteration.
changing
❑ Only one on-site customer. functionality).
Test and Verification
Implementation
❑ Applying a subset of uncompensated practices; customisation before trying: Sketches.
Identify tasks and
❑ Collective code ownership requires testing, continuous integration and coding standards. estimates. Frequent Coding Acceptance Test-first
❑ Minimum documentation requires an onsite customers. Refactoring. standards. testing,
customer
development
unit testing.
❑ Frequent refactoring requires unit tests. tests.
❑ XP = iterative development + minimal documentation + unit testing. Implementation Test & Verification Management Other Pair Team code
Programming.
❑ Not writing unit test FIRST. ownership.
Onsite
Note that in XP, the unit tests
❑ Customer doesn’t decide. are part of the documentation. customer.
❑ No customer-owned tests. Coach Tracker
❑ Customer writing acceptance tests does not review the results. Process conscience. Collect metrics.
Consultant
Technical consulting.
❑ Minimal refactoring. Project Management Configuration and Change
❑ Task cards too fine-grained. Should be in one to two days range, not hours! Project Management Process customising. Tell progress.
Either paper cards or whiteboard
Configuration & Change Coaching. Management Environment
❑ Pairing with one partner for too long. list on which are written the tasks Management Environment Intervention. Feedback on poor
Task List
❑ Customer is tracker. for stories, within an iteration.
Teaching.
estimates. Planning Short Continuous
❑ Not integrating the QA team. Each task to be completed within Game. releases. Common Room. integration.
1-2 days.
❑ Post-development documentation is wrong.
❑ Diagramming is bad.
On the wall, in order to better
❑ Only pair young programmers or newbies. Visible
communicate. Contents depends
Sustainable
pace (no Stand-up
❑ One partner going too fast. graphs.
on teams; for example, number of overtime). meeting. Planning
Game.
❑ Observer can’t easily see the monitor. tests defined vs. passing.

❑ Unwilling to learn or explain or pair. 3

❑ Only briefing some team members. Story cards.

❑ Stand up meeting too long or unfocused. Should be 20 minutes or less and on status not
discussions of design and requirements.
❑
❑
❑
Group unrelated bug fixes into one card.
No dedicated acceptance tester.
Onsite customer and Big Boss in charge of milestones and goals are not aligned.
You don’t understand XP If You…
❑ Iterations too long. Should be 1 to 3 weeks.
❑ Iterations aren’t timeboxed. Should modify goals rather than time, and analyse why the ❑ Think XP = Avoidance of documentation or writing unit tests.
estimation was off.
❑ Integration doesn’t end in an integrated and tested baseline. ❑ Leave out customers from the Planning Game, writing acceptance tests, or reviewing
❑ Each iteration ends in production release. Each iteration is an internal release, not a the test iteration results.
shippable product.
❑ Predictive planning. ❑ Create a plan with exact number of iterations and what will occur in each and think you
CAN enforce it.
Larman, C. (2004). Agile and interactive development: A managers guide. Boston: Addison Wesley.