OMG Steve McConnell (p&p, day 2)

Basic motivations for agile:

Developers: want less overhead, want to focus on "real" work
Customers: want flexibility

Value delivery keeps up with cost

"Especially useful when schedule and resources are fixed, and mission is to provide maximum business value within those constraints"

Agile Manifesto (ca. 2001)

"Reduced emphasis on long-range predictability of features--especially of the combination of cost, schedule and features"

Variation of methodologies is really about the balance of up-front work vs. in-iteration

In-phase defect removal goal is always 100%, at least in theory

Aha: in addition to code defects, can also find requirements defects, architecture/design defects... leaving major testing to end allows build-up of latent defects (all kinds), unexpected fix time

("Evolutionary Delivery" illustrated with arbitrary 25% balance, looks good for us)

Packaged methodologies

XP: developer focused; abandoned more often than retained
Scrum: workflow/management focused; retained more often than abandoned

Few projects use all the practices of a given method; claim of "synergy" among practices is invalid

Useful practices

• Short release cycles (1-4 weeks): does not have to be externally to the customer; virtually always valuable
• Rolling-wave planning: long-term (2-12 months); detailed (30-60 days)
• Timebox development: commit to delivering fixed set of functionality in given timeframe; high morale, visible progress; need a rest period or different activity between sprints
  
• Empowered, small, cross-functional teams: include all stakeholders needed to make binding decisions
  
• Active management (coach, Scrum Master): "Theory Y" style; remove barriers to good work
  
• Coding standards
• Frequent integration & test: daily build and smoke test (no point building if don't also test that build is OK); note that you don't have to deliver new functionality every day, nor even check code in every day
  
• Automated regression test (TDD): virtually always a good practice with new development, problematic for existing/legacy systems
• Postmortem for each release

Hit or miss

• Customer-provided acceptance tests: ongoing participation hard to sustain; customer testers don't always know meaningful comprehensive tests
  
• Daily stand-up meetings: a good idea that can go too far; less often, shorter, can be OK
• Simple design: don't oversimplify; must fully satisfy known requirements
  
• Test-first development: culture shift is difficult, high discipline required, worth the effort
• 40-hour work week: we really mean a sustainable pace of work

Problematic

• System metaphor
• Onsite customer
• Collective code ownership
• Pair programming: good if used selectively
• Refactoring: prone to abuse

Legacy

Overhyped, buzzwordy, has led to cynicism

Not the best solution for every company, just for many; there are still cases where sequential dev is the best fit

Best outcomes

Importance of short, iterative and/or incremental cycles
Die Waterfall die!
Check-and-balance against overly bureaucratic CMM
Reality check against "omniscience" of requirements, planning, design

In conclusion:

Steve McConnell is a great communicator. I feel like this stuff is really accessible to folks at all tech levels, which makes it helpful for me in taking the Gospel back to our stakeholders.