is never met … because of external reasons Scope changes over the project … because of need to adapt Implemented plan doesn‘t fit needs … because the world moved on Requires lots of artifacts … which do not add value Command and control approach … is hindering positive collaboration
Agreement Close to Agreement Close to Certainty Far from Certainty Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle, Taken from “Redistributable Intro to Scrum”, Mountain Goat Software
a witch has blighted Bob's mare, and Nob wonders whether she killed Cob's sow.” Hob and Nob may not even recognize that there is a problem. Wait … there are no witches, they are mythical creatures. Take away: resolving the reference problem requires communication in order to come to a common understanding.
4. Establish pull 5. Seek perfection 1. Identify value http://www.lean.org/WhatsLean/Principles.cfm … for customers … and eliminate waste … create value in tight sequence … (not only) for customers … continuously
customers Energize workers Eliminate waste Learn first Deliver fast Build quality in Keep getting better Defer commitment by Mary and Tom Poppendieck cf. http://www.poppendieck.com/
Manage flow Make policies explicit Implement feedback loops Improve collaboratively, evolve experimentally by David J. Anderson, taken from Wikipedia
a plan Responding to change over Comprehensive documentation Working software over Contract negotiation Customer collaboration over cf. http://www.agilemanifesto.org/
Deliver working software frequently Business and developers work together daily Build projects around motivated individuals Convey information via face-to-face conversation Working software is the primary measure of progress Promote sustainable development Continuous attention to technical excellence Simplicity is essential Emergent design and architecture from self-organizing teams Team reflects on how to become more effective, tunes and adjusts Condensed from http://www.agilemanifesto.org/principles.html
Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986, taken from MountainGoat Software ‘Redistributable Intro to Scrum’, http://www.mountaingoatsoftware.com/uploads/presentations/English-Redistributable-Intro-Scrum.ppt Rather than doing all of one thing at a time... … agile teams do a little of everything all the time Requirements Design Code Test
current sprint issues Product owner and team work on the plan / backlog for next iteration(s) Review of the built results at the end of a sprint provides feedback about quality and velocity and influences future plan Development team reflects after each sprint to improve
User level acceptance tests pass Development quality goals are met Design requirements are met … Ready (for next / current iteration) “INVEST” in “SMART” requirements / specifications Required architecture is understood Required technology is mastered Design is ready ….
value in a value stream Potentially shippable increments (PSI) vs. Releases Development occurs with a standard cadence Dates are fixed – quality is fixed – scope is variable Release Planning Meeting to align to a common, committed set of objectives for next PSI timebox. cf. Scaled Agile Framework, D. Leffingwell http://scaledagileframework.com/agile-release-train/
Agile addresses problems of traditional PM problems by focusing on customer needs continuous learning embracing changes time boxing in iterations minimizing overhead