My biggest take-aways were all conceptual...All the problems we have with things "breaking" and being generally not (automatically) repeatable come from us not takng the time to mitigate certain common risks:

Risk Aversion

• Automated Testing is acknowledgement that coding bugs can and will occur.
  
  
• Versioning is acknowledgement that shared files can and will be overwritten.
  
  
• Agile is acknowledgment that Requirements Gathering can and will fail.
  
  
• Continuous Integration is acknowledgment that deployments can and will break.
  
  
• TDD is (in a way) acknowledgement that refactoring will constantly occur.
  
  
• ...

If you don't take these risks into account in your process, the problems will all end up getting solved individually for each project (ugh) or worse -- swept under the rug until it's too late. The more common risks we can acknowledge and plan solutions for, the easier our jobs will be.

Presenter – Tim Peek

• History of lifecycle development (mid-70s)
  • Waterfall methodology
    • BDUF – Big Design Up Front
  • Iterative methodology
    • Phase based development
    • Analysis Paralysis is a risk – mitigated by timebox or other constraints
• Agile Philosophy
  • Attempts to look at the root causes of software project failures
    • Good people handicapped by bad processes
    • If value is in the working system, then too much time is spent on non-value-added work
    • Iterative development is valid model but still overburdened by processes
  • “Let programmers be programmers”, not project managers
  • Counterculture swinging against heavily process-based methodologies
    • PMI and PMBOK (Project Management Body of Knowledge)
    • Capability Maturity Model (CMMI)
  • Early proponents appeared in the 1980s
    • Rapid Application Development
  • New ideas, visibility and momentum in the 90s
  • “Agile Manifesto” in 2001 started to bring Agile into the mainstream
• Manifesto
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • Early and continuous delivery of valuable software
  • Welcome changing requirements EVEN LATE IN DEVELOPMENT
  • Deliver working software frequently
  • Business people and developers work together daily throughout the project
  • Build projects around motivated individuals
    • Environment
    • Support
    • Trust
  • Communication face-to-face conversation
  • Working software is the primary measure of progress
  • Agile processes promote sustainable development
  • Continuous attention to technical excellence and good design
    • Continually developing AND
    • Continually testing – testing is key
  • Simplicity (maximizing the work NOT done) is essential
  • The best architectures, requirements and designs emerge from self-organizing teams
  • At regular intervals, the time reflects on how to become more effective, then tunes and adjusts its behavior accordingly
• Initial Agile Mindset
  • Focus on execution
    • Planning is important by not as important as execution
  • Writing plans and documents for development is wasting time from actually developing software
• The Current Agile Mindset
  • Focus on leaner versions
  • Agile project management
  • Agile quality assurance
  • Agile CMM
• The More Mature Agile Mindset
  • The software development world has moved too far toward process-focus
  • Too many processes result in bureaucracy and overhead
  • Most technical people work fine if you allow them
  • Things are rarely black and white
    • Make things as simple as possible, but not chaotic
    • Compromise when necessary
• The Nature of Projects
  • Traditional PM assumes projects are predictable and most are not
  • The nature of the project should be uncovered through exploration
• The Nature of Agile Projects
  • Generally software development
  • Smaller teams (3-5 people)
  • Larger projects
    • Split into smaller Agile projects
    • Use common processes and techniques
    • Might need longer sprints to manage coordination
    • Requires more structure and coordination
      • but keep minimal
• The “Planning Game”
  • Customer, management, users and team meet to determine functionality for next Sprint
  • The team explores requirement details with the customer
    • Detailed specs
    • Detailed test rules
  • Tech team meets afterwards to determine how to meet expectations
  • Ultimately, customer and project team agree what to work on
• Customer Requirements
  • Create test cases along with the requirements
  • Test cases validate completeness and correctness
  • Try to identify means for automated testing
• Project End Date
  • Customer prioritizes
  • High value requirements delivered first
  • Ultimately customer decides if the value is more than the cost of the next sprint
  • If not, the project will end
• Fixed Budget/Deadline
  • Budget delivers sprints with most valuable features until the money runs out
  • Deadline delivers sprints with most valuable features until the time runs out
  • Unlike traditional development, customer will ALWAYS have something delivered (fully tested production code)
• Construct
  • Refactor
    • Look for opportunties to enhance code
    • Make code more adaptable
    • Maintainability is key
    • Need to have solid regression testing process to ensure nothing breaks
    • Don’t try to make it perfect, just look for opportunities to make it better
• TDD
  • Test are defined along with detailed requirement
  • Write the test first, then code to meet the test
  • New tests get added to the repository
  • Programmer tests for 100% of the code
  • Tests must ALL run correctly with each sprint
  • Be sure that tests don’t all become too discrete.  Keep eye on overall design and create tests for integration and end-to-end logic
• Implementation
  • Continuous Integration
    • Daily builds ensure full integration
    • Uncovers integration bugs early, eliminates code freezes
  • Customer decides when the first iteration is usable and then grow features from there
• Scrum
  • “Scrum” metaphor used in 1986 to describe new approach to product development
  • Rugby corollary – adaptive, quick, self-organizing, few rests
  • Scrum approach developed and refined in 1996
  • Looks at software development in “new product” versus “manufactured product” model
  • Scrum Master
    • Management rep
  • Scrum teams
  • Daily Scrum – standup meeting every day
• Extreme Programming (XP)
  • Communication
  • Feedback
  • Whole Team
  • Planning Game
  • Customer Acceptance Tests
  • Small releases
  • Pair Programming
  • TDD
  • Design Improvement/Refactoring
  • Continuous Integration
  • Collective Code Ownership