agile cmm worlds apart or best of both l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Agile & CMM: Worlds Apart, or Best of Both? PowerPoint Presentation
Download Presentation
Agile & CMM: Worlds Apart, or Best of Both?

Loading in 2 Seconds...

play fullscreen
1 / 53

Agile & CMM: Worlds Apart, or Best of Both? - PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on

Agile & CMM: Worlds Apart, or Best of Both?. Philly SPIN Jan 23, 2007 Clif Kussmaul & Roger Jack. Overview. Concepts & Challenges Case Study Key Ideas & Lessons Learned Next Steps. I. Concepts & Challenges. Problems Processes - Disciplined & Agile Comparing, Choosing, & Mixing.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Agile & CMM: Worlds Apart, or Best of Both?' - issac


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
agile cmm worlds apart or best of both

Agile & CMM:Worlds Apart, or Best of Both?

Philly SPIN Jan 23, 2007

Clif Kussmaul & Roger Jack

overview
Overview
  • Concepts & Challenges
  • Case Study
  • Key Ideas & Lessons Learned
  • Next Steps
i concepts challenges
I. Concepts & Challenges
  • Problems
  • Processes - Disciplined & Agile
  • Comparing, Choosing, & Mixing
a problems
A. Problems
  • high percentage of projects fail
    • exceed budget, cancelled, never used, …
  • changing requirements
  • hard to coordinate knowledge workers
  • worse with bigger projects & teams
    • distributed, outsourced, …
  • others?
virtual teams
Virtual Teams
  • functions - marketing, dev, QA
  • locations - room, city, country
  • organizations - partner, vendor
  • time zones - 3, 6, 12 hours
  • cultures - company, country
outsourcing
Outsourcing
  • reduce cost, headcount, etc
    • most common (59.8%) goal of offshoring
    • 73.5% of CIOs feel this is overrated
    • save 15%-25% in Y1 and <40% by Y3
  • access specialized skills & facilities
  • faster development & time to market
outsourcing relationships kishore et al 2003
Outsourcing Relationships (Kishore, et al 2003)

Reliance

Alliance

Dependence & Substitution

Support

Alignment

Strategic Impact

b processes
B. Processes
  • goals - leverage best practices
    • decrease defects, effort, & schedule
    • project management & scheduling
    • focus on interesting & difficult aspects
  • risks
    • process rather than product
    • following rules rather than thinking
    • mismatch between process & project
more disciplined rigid
More Disciplined (Rigid?)
  • development as manufacturing
    • documentation of processes
    • measurement, analysis, & feedback
  • motivated by very large projects
    • e.g. US Dept of Defense
  • ISO-9000, SEI CMM, etc
    • assessment models, not processes
capability maturity model e g paulk 1995
Capability Maturity Model(e.g. Paulk, 1995)
  • 5 levels of increasing maturity
    • Initial - ad hoc or chaotic
    • Repeatable - for similar projects
    • Defined - activities & processes
    • Managed - detailed measures
    • Optimized - continuous feedback
offshore cmm
Offshore CMM
  • embraced by offshore organizations
    • 75% of CMM-4
    • 84% of CMM-5
  • useful credential for big companies
  • “The British invented bureaucracy, but the Indians perfected it.”
other disciplined approaches
Other Disciplined Approaches
  • Personal Software Process (PSP)(Humphrey 1994; Humphrey, 1997)
  • Team Software Process (TSP)(Humphrey, 1999)
  • similar focus: repeat, define, measure, optimize
more agile flaky
More Agile (Flaky?)
  • developers as skilled craftspeople
    • individuals & interactions over processes & tools
    • working software over comprehensive docs
    • customer collaboration over contract negotiations
    • responding to change over following plans
extreme programming e g beck 1999
Extreme Programming(e.g. Beck, 1999)
  • whole team – developers, customers, testers, etc
  • small releases
  • release & iteration planning
  • metaphor, simple design, continuous refactoring
  • customer defined tests
  • test-driven development, continuous integration
  • coding standard, collective code ownership
  • pair programming
  • sustainable pace
feature driven development e g palmer felsing 2002
Feature Driven Development(e.g. Palmer & Felsing, 2002)
  • overall model with domain experts
      • object model, sequence diagrams, design notes
  • feature list, grouped into sets
      • form: <action> <result> <object>
  • high-level plan by feature sets
  • design & build sets in two week iterations
  • 6 key roles + 6-9 supporting roles
fdd best practices
FDD Best Practices
  • domain object modeling
  • developing by feature
  • individual code ownership
  • matrixed feature teams
  • regular builds & inspections
  • configuration management
  • reporting / visibility of results
scrum schwaber beedle 2002 schwaber 2004
Scrum(Schwaber & Beedle, 2002; Schwaber 2004)
  • Product Backlog - prioritized
  • 30-day Sprints with 4 key meetings:
    • Planning – to set scope & design
    • Daily Scrum – 15 minute update
      • status? plans? problems?
    • Review – for stakeholders
    • Retrospective – to reflect & improve
  • roles: Owner, Master, Dev Team
c comparing choosing
C. Comparing & Choosing
  • many styles & colors
  • when is each approach most useful?
  • consider 2 main dimensions
    • from developers to management
    • from agility to discipline
  • when & how to combine approaches?
two dimensions
Two Dimensions

CMM

PSP

TSP

agile disciplined

FDD

Scrum

XP

developers managers

matching process to project
Matching Process to Project
  • requirements
    • how well understood?
    • how stable or likely to change?
    • external requirements? (DoD, FDA, etc)
  • activities
    • how repeatable?
      • continuous process vs. one-off project
matching process to project22
Matching Process to Project
  • culture
    • large or small, startup or monolith
    • group communication & experience
  • people
    • experiences & abilities
    • personalities & priorities
ii three year case study
II. Three Year Case Study
  • Client Context
  • High-Level Process & Roles
a client context
A. Client Context
  • successful software product company
    • extensive domain expertise
    • accustomed to distributed teams
  • new engine for data mapping
  • domain-specific products using engine
objectives challenges
Objectives & Challenges
  • flexible staff, manage $$$
  • rapid startup & delivery
    • market windows, partnering, etc.
  • frequent requirement changes
    • prospects, customers, & standards
  • multiple locations & cultures
evolving relationship
Evolving Relationship
  • initial analysis & requirements
    • hourly consulting
  • proof-of-concept & sales demo
    • inhouse team with hourly consulting
  • ongoing development
    • inhouse & offshore teams
    • 4-6 week sprints (occasionally longer)
b high level process
B. High-Level Process
  • initial analysis & modeling phase (FDD)
  • product backlog (Scrum)
    • priorities, risks, scope, cost, ..
  • 2-8 week iterations (Scrum)
    • prioritization, planning & estimation
    • formal proposal with target date & price range
    • offshore development & reviews (CMM)
    • customer deliveries & reviews
organization
Organization

INHOUSE

OFFSHORE

Analyze, Design, & Plan

Engine

Data Model

Configuration

GUI & Logic

Doc & QA

roles
Roles
  • Technical Lead
    • primary interface for offshore team
    • daily status meetings, onsite 1-2 days per week
  • Team Leaders – inhouse & offshore teams
    • coordinate with Technical Lead
  • developers: ~5 inhouse + 5-10 offshore
  • ~5 others (some part time)
    • analysis & design, QA, documentation, etc.
technical lead activities
Technical Lead Activities
  • morning
    • “standing IM” meeting with offshore team
    • breakout on specific issues
  • daytime
    • check progress & current issues
    • follow up with inhouse team, vendors, etc.
    • review designs, prototypes, code, etc
  • evening
    • send or discuss status with offshore team
iii key ideas
III. Key Ideas

Test fast, fail fast, adjust fast. - Tom Peters

The major problems of our work are not so much technological as sociological in nature.

- Tom DeMarco & Tim Lister

Systems reflect the structures of the organizations that produce them. - Melvin Conway (rephrased)

recurring themes
Recurring Themes
  • good fit
    • “impedance matching”
  • ongoing communication
  • co-evolution of projects & processes
    • be willing to make mistakes
  • value of bottlenecks
  • not quite enough is about right...
1 avoid small projects
1. Avoid Small Projects
  • amortize project overhead
    • e.g. communication
  • start small but plan to grow
2 focus on win win
2. Focus on Win-Win
  • emphasize common goals
    • downplay contracts & boundaries
  • few negotiations  risk
    • more need to define details
    • incentives to cut corners, creep scope
  • many negotiations  cooperation
    • reconsider, adjust, & evolve
3 deliver early often
3. Deliver Early & Often
  • review status & overall direction
  • identify defects & changes (e.g. GUI)
    • be willing to make & correct mistakes
  • build confidence & trust
4 management still matters
4. Management Still Matters
  • monitor costs
  • address near-term priorities
  • maintain sustainable pace
  • not quite enough is about right...
5 questions near clients
5. Questions Near Clients
  • critical for high-impact activities
    • requirements analysis
    • research & prototyping
    • architecture
  • physical or virtual
    • Technical Lead onsite 1-2 days/week
    • instant messaging, phone, email, etc
6 bootstrap documents
6. Bootstrap Documents

A small number of documents become the critical pivots around which every project’s management revolves.

– Brooks, The Mythical Man-Month

  • too few or too many  misunderstandings
  • may take time to find the right ones...
  • not quite enough is about right...
sample documents
Sample Documents
  • master feature list - high level
  • iteration feature list - low level
  • data model & dictionary
  • design docs, diagrams, & mockups
    • temporary
  • dependency matrix for features & components
7 concentrate on interfaces
7. Concentrate on Interfaces

Any problem in computer science can be solved with another layer of indirection.

- David Wheeler

  • don’t micromanage each organization
    • cultures & conditions may vary
  • encourage teams to work differently
    • tools & processes matched to tasks & cultures
    • one size doesn’t fit all
8 tools for leverage
8. Tools for Leverage
  • mail archives
  • source code & document control
  • issue tracking
  • unit tests & regression tests
  • not quite enough is about right...
9 minimize changes
9. Minimize Changes
  • true of most projects
    • easier to manage with shorter cycles
  • especially for distributed teams
    • more inertia
    • last-minute is riskier
    • errors and omissions are more likely
10 coordinate carefully
10. Coordinate Carefully
  • optimize location & avoid duplication
    • be willing to make & correct mistakes
  • round-the-clock development
    • hand-off every 12 hours
    • design; implement; review & test
    • encourages review, discourages overtime
11 ease into relationships
11. Ease into Relationships
  • start small
    • less momentum  easier to change
  • Tech Lead as essential bottleneck
    • hide cultures & learning curves
    • reduce miscommunication & lost info
  • increase interactions gradually
    • as confidence & shared experiences grow
12 manage cultures
12. Manage Cultures
  • organizational culture
    • more authoritarian (top-down)
    • more entrepreneurial (bottom-up)
  • question & conflict strategies
  • real & perceived social norms
  • job security?
13 communicate effectively
13. Communicate Effectively
  • email (archived)
  • phone & instant messaging
  • conferencing - phone/web/video?
  • face to face contact when feasible
    • even short trips can help
iv next steps
IV. Next Steps
  • Review your current approach.
  • Identify opportunities to improve.
  • Start with small experiments.
  • Share successes & failures.
discussion
Discussion

Clif Kussmaul

Roger Jack

Elegance Technologies, Inc.

1721 Green Valley Rd

Havertown, PA 19083

ckussmaul, rjack @ elegancetech.com

www.elegancetech.com

484-431-0722, 484-431-1775

bibliography
Bibliography

Beck & Andres, Extreme Programming Explained, 2004

Brooks, The Mythical Man-Month, 1975, 1995

Conway, How do committees invent? Datamation, 1968

DeMarco & Lister, Peopleware: Productive Projects & Teams, 1999

Humphrey, A Discipline for Software Engineering, 1994

Humphrey, Introduction to the Personal Software Process, 1997

Humphrey, Introduction to the Team Software Process, 1999

Jones, Software Assessments, Benchmarks, & Best Practices, 2000

Kishore, A relationship perspective on IT outsourcing, Communications of the ACM, 2003

Palmer & Felsing, A Practical Guide to Feature Driven Development, 2002

Paulk, et al, The Capability Maturity Model, 1994

Schwaber & Beedle, Agile Software Development with Scrum, 2002

Schwaber, Agile Project Management with Scrum, 2004

abstract
Abstract

We describe techniques and lessons learned from projects combining agile and CMM methodologies with distributed teams. Such teams often need to contend with multiple organizational boundaries, differences in time zone, language, and culture, and other challenges. First, we review background concepts and challenges. Second, we present some key ideas and implications. Third, we describe a case study involving continually changing requirements, outsourcing, offshoring, and a methodology combining CMM, FDD, and SCRUM. We conclude with lessons learned and future directions.

biographies
Biographies

Clif Kussmaul is Chief Technology Officer for Elegance Technologies, which develops software products and provides product development services, and Assistant Professor of Computer Science at Muhlenberg College. Formerly, he was Senior Member of Technical Staff at NeST Technologies. He has a PhD from the University of California, Davis, an MS and MA from Dartmouth College, and a BS and BA from Swarthmore College. His interests include agile development, virtual teams, and entrepreneurship.

Roger Jack is President of Elegance Technologies, Inc. Roger has experience in project management, and creating reliable and robust interfaces and architectures. He was Vice President of U.S. Software Operations for NeST Technologies, where he managed many offshore projects. He has an MBA from Duke University's Fuqua School of Business, and an MS in Computer Science from Villanova University.