ISECON 2003 San Diego, California Integrating Agile Methodologies into the Project Capstone Christopher G. Jones, CPA/PhD Utah Valley State College [email protected]

ISECON 2003 San Diego, California

Integrating Agile Methodologies into the

Project Capstone

Christopher G. Jones, CPA/PhDUtah Valley State College

[email protected]

mailto:[email protected]


The Setting Large U.S. Intermountain West university with

18,500 students I.S. program in AACSB School of Economics and

Business Two undergraduate concentrations

• Systems Development

• Information Security Senior Project Capstone required for both tracks

• Team-based end-to-end production of a new system for a real client


The Challenge (1)

Mixed development backgrounds• SA/SD in Systems Analysis & Design

• OOAD in Advanced Programming course

Uneven preparation levels • Two different program concentrations

• Traditional Systems Development

• Information Security

• Students substitute security/computer forensics for advanced development coursework


The Challenge (2)

Little experience with heavy-weight methodologies• Full-blown SA/SD

• OOAD a la UML/RUP

Project artifacts a drag on project momentum rather impetus


The Experiment (1) Intervention

• Use of an ultra-lightweight methodology framework to drive the development process in the capstone• Crystal Clear – “the lightest of the light”• Minor modification to documentation requirements

Subjects• Two sections of Senior Project, Spring 2003

• Day • 7 Students -- 2 project teams

• Evening • 18 students -- 5 project teams


Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Robert C. MartinSteve Mellor

Ken SchwaberJeff SutherlandDave Thomas

James GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian Marick

Kent BeckMike Beedle

Arie van BennekumAlistair Cockburn

Ward CunninghamMartin Fowler

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice


Crystal: Goals

“Software development is viewed as cooperative game of intervention and communication, with a primary goal of delivering useful, working software and setting up the next game.”

--Cockburn, 2001


Crystal: Core Values

Strong on communications. Light on deliverables. Keep the communications paths

short, rich and informal. Deliver frequently. Reduce overhead.



What’s Crystal Clear?

Development methodology for a 2 to 6 person team

Project criticality, low to medium• Failure would not

hurt the bottom line Minimal set of work

products

Crystal ClearCrystal Clear


Crystal Clear Work Products (1)

Mission Statement Team Structure Development

Methodology Release Sequence Viewing & Release

Schedule

Risk List Project Status Actor-goal List Annotated Use

Cases Requirements File System Design


Crystal Clear Work Products (2)

Design Sketches Common Object

model Screen Drafts Source Code Packaged System

Migration Code Test Cases Defect Reports User Manual


Design Sketches Common Object

Domain model Screen Drafts Source Code Packaged System

Crystal Work Products (2) Revised

Migration Code Test Cases Defect Reports User Manual

Assistance

××


The Essence of Crystal Clear

“The lead developer and two to five other developers in a large room or adjacent rooms, with whiteboards (preferably printing whiteboards), access to key users, distractions kept away, delivering running, tested, usable code to the users every month or two, periodically reflecting and adjusting their working conventions” (CC, p. 7).



The Experiment (2)

Treatment• Project Management Body of Knowledge

• Agile Development Exercise

• Crystal Clear Overview

• Work Product Tutorials

• Milestone Presentations

• Reflection Workshops• Analysis/Design/Implementation Retrospectives

• Methodology Retrospective


Agile Development Exercise

Based on the eXtreme Planning Game Working in teams, students design and

“build” a hot drink maker to the client’s specification

High-level Use Cases to capture system requirements

Client available to help prioritize functionality and validate prototypes


Reflection Workshops

“Periodically reflecting and adjusting their working conventions” (CC, p.7)

On-going evaluation of • Team structure

• Team process

• Working conventions One page retrospective following each milestone

• What would you like to keep?

• Where are you having problems?

• What will you do differently in the next phase?


Analysis Phase Retrospective Keepers

• Team roles• Communication channels

Problems• Scope creep• Shared access to work products• Divergent views/Personality differences• Insufficient time to master new technology• Burdensome documentation levels

Adaptations for Design Phase• Increase team meeting frequency• Clarify team member assignments• Establish a team repository• Increase team communication frequency from weekly to daily


Design Phase Retrospective Keepers

• Reworked team roles• Development process• Increased communication levels• Regular team meetings

Problems• Getting all team members to meetings• Occasional communication lapses• Tendency to over-”tech” the project

Adaptations for Implementation Phase• Realign roles to focus on coding/testing• Meet more often/Communicate even more• Emphasize project management to ensure assignment deadlines

met• Focus on functionality over “look and feel”• Meet with client/sponsor more frequently


Implementation Phase Retrospective Keepers

• Team dynamics/balanced team• Team commitment• Regular meetings• High communication levels• Adaptive development process

Problems• Sense of insufficient time to deliver primary functionality• Struggles with technology, whether new or familiar• Synchronizing team meetings as meeting frequency

increased


Results of Experiment

All 7 project teams deployed working code• Met or exceeded client expectations

• Highest priority functionality delivered

Use of agile methodology allowed students to adapt process midstream as necessary


Lessons Learned (1)

Agile methodologies though often targeted to the OO community support traditional development approaches as well

Even with a reduced artifact set, students still perceive any form of documentation (other than uncommented source code) as excessive


Lesson Learned (2)

Adopting Use Cases as the underlying mechanism for functional requirements specifications requires more than a 2-hour in-class tutorial

Students appreciate the adaptiveness and flexibility of the agile approach


Should You Go Light? (1)

These factors suggest a traditional predictive process:• A team over fifty

• Fixed price, or more correctly a fixed scope, contract

• Regional development preferences for heavy-weight methodologies


Should You Go Light? (2)

The following factors suggest an adaptive process:• Uncertain or volatile requirements

• Responsible and motivated developers

• Client/User who understands and will get involved

• Students with mixed development backgrounds

• Teams under fifty


Questions?

Documents

ISECON 2003 San Diego, California Integrating Agile Methodologies into the Project Capstone Christopher G. Jones, CPA/PhD Utah Valley State College [email protected]