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

1. Agile & CMM:Worlds Apart, or Best of Both? Philly SPIN Jan 23, 2007 Clif Kussmaul & Roger Jack

2. Overview • Concepts & Challenges • Case Study • Key Ideas & Lessons Learned • Next Steps

3. I. Concepts & Challenges • Problems • Processes - Disciplined & Agile • Comparing, Choosing, & Mixing

4. 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?

5. Virtual Teams • functions - marketing, dev, QA • locations - room, city, country • organizations - partner, vendor • time zones - 3, 6, 12 hours • cultures - company, country

6. 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

7. Outsourcing Relationships (Kishore, et al 2003) Reliance Alliance Dependence & Substitution Support Alignment Strategic Impact

8. 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

9. 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

10. 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

11. CMM Defect Levels(1 FP ≈ 100 LOC) (Jones, 2000)

12. 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.”

13. Other Disciplined Approaches • Personal Software Process (PSP)(Humphrey 1994; Humphrey, 1997) • Team Software Process (TSP)(Humphrey, 1999) • similar focus: repeat, define, measure, optimize

14. 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

15. 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

16. 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

17. FDD Best Practices • domain object modeling • developing by feature • individual code ownership • matrixed feature teams • regular builds & inspections • configuration management • reporting / visibility of results

18. 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

19. 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?

20. Two Dimensions CMM PSP TSP agile disciplined FDD Scrum XP developers managers

21. 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

22. Matching Process to Project • culture • large or small, startup or monolith • group communication & experience • people • experiences & abilities • personalities & priorities

23. II. Three Year Case Study • Client Context • High-Level Process & Roles

24. A. Client Context • successful software product company • extensive domain expertise • accustomed to distributed teams • new engine for data mapping • domain-specific products using engine

25. Objectives & Challenges • flexible staff, manage $$$ • rapid startup & delivery • market windows, partnering, etc. • frequent requirement changes • prospects, customers, & standards • multiple locations & cultures

26. 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)

27. 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

28. Organization INHOUSE OFFSHORE Analyze, Design, & Plan Engine Data Model Configuration GUI & Logic Doc & QA

29. 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.

30. 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

31. 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)

32. 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...

33. Lessons Learned

34. 1. Avoid Small Projects • amortize project overhead • e.g. communication • start small but plan to grow

35. 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

36. 3. Deliver Early & Often • review status & overall direction • identify defects & changes (e.g. GUI) • be willing to make & correct mistakes • build confidence & trust

37. 4. Management Still Matters • monitor costs • address near-term priorities • maintain sustainable pace • not quite enough is about right...

38. 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

39. 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...

40. 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

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

42. 8. Tools for Leverage • mail archives • source code & document control • issue tracking • unit tests & regression tests • not quite enough is about right...

43. 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

44. 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

45. 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

46. 12. Manage Cultures • organizational culture • more authoritarian (top-down) • more entrepreneurial (bottom-up) • question & conflict strategies • real & perceived social norms • job security?

47. 13. Communicate Effectively • email (archived) • phone & instant messaging • conferencing - phone/web/video? • face to face contact when feasible • even short trips can help

48. IV. Next Steps • Review your current approach. • Identify opportunities to improve. • Start with small experiments. • Share successes & failures.

49. 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

50. 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