No one can fully and perfectly specify a non-trivial system up front to any degree of accuracy. It is impossible to know exactly how much time a project or component is going to take and it is equally impossible to know exactly what the end product will be. Software developers cannot predict the future any better than you or I.

Much of this is due to the changing nature of software requirements, the needs of the customer, and the uncertainty that developers have before a project begins, not knowing how quickly they will be able to work within the framework of the project, etc.

We know this, we have worked on painful projects, been a part of the guessing game of spec documents. We have been there and now - like us - more and more developers and project managers are realizing that the old methods don't make sense.

1,2,3 - Chaos research by The Standish Group (1994-2004), The landmark study of IT project failure (http://www.standishgroup.com/chaos_resources/)

• Analysis paralysis
• CYA
• Telephone problem - requirement expressed one way by stakeholder, understood differently by participant, captured differently by document, and finally interpreted differently by developer
• Over-architected solutions
• Over-documented solutions (with documents getting out-of-date unless constantly monitored)

• People are more valuable than tools and process.
• Software is not technical. It's social.
• Interactions should be efficient and enjoyable.

• Provide smallest feature set with business value.
• Deliver fast, deliver often. Get product into customers hands quickly.
• Do. Don't document.

• Respect your users.
• Build relationships.
• Be transparent.
• Get users using the software quickly.
• Pave the cow paths.

• Fowler: "A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw"
• It won't turn out how you thought it would.
• Embrace change.

• An Iterative Process
• Discuss rough feature set with stake-holders and create stories
• Stake-holders prioritize features
• Developers produce estimates
• Work begins in iterations (typically 1-6 weeks)
• Each iteration produces a workable piece of software.
• The end product of every iteration is reviewed by stake-holders. While there are customer touch-points throughout this process, there is a larger dialog that occurs at both Discover and Deploy
• Before each iteration, stake-holders can re-prioritize features as they like.
• This allows us to move as needed with the market
• Allows long term plans to be fluid - only "lock-in" features for the upcoming iteration
• "the ability to make decisions as late as possible provides a competitive advantage" - Mary Poppendieck
• Contracts
• Can't fix time, price, AND scope (it doesn't work)
• Since time really is money the best method is to box sets of features into timeframes

• 1-2 weeks - short feedback cycles
• Agile methods are adaptive, rather than predictive
• Short iterations allow us to respond and change rapidly and get customers using products earlier.

• User stories (written on story cards) encourage deferring detail until you have the best understanding you are going to have about what you really need
• Feature-driven design - Based on user input
• It is more important to think about user goals than to list the attributes of a solution
• Readability, understandability, non-technical, written in terms of business value

• Emphasize verbal communication
• Are they comprehensible by everyone
• Are they the right size for planning
• Will they work for iterative development
• Support opportunistic design
• Encourage participating design
• Build up tacit knowledge

• Easier communication
• Greater understanding of project and business proposition by all
• Team mentality (we're all in this together)
• Speed

• Scrum
• Continuous improvement of products, people, processes
• Agile methods are people-oriented, rather than process-oriented.
• Agile teams focus on Collaboration
  • over comprehensive documentation
  • over Command and Control

• A generalizing specialist is someone who is "a jack-of-all-trades and a master of a few."
• Traditional roles and titles become unimportant
• Individuals need to:
  • Become cross functional experts,
  • Build their interpersonal skills, and
  • Focus on team goals rather than individual recognition.