Problems with traditional PM Golden triangle (scope, time and costs) 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
Project noise level Simple Complex Anarchy Technology Requirements Far from 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
Hob and Nob: a reference problem Geach’s puzzle: “Hob thinks 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.
Lean principles 2. Map the value stream 3. Create flow 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
Lean software development Optimize the whole Focus on 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/
Kanban: six core practices Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively, evolve experimentally by David J. Anderson, taken from Wikipedia
Summary Lean development addresses problems of traditional PM problems by focusing on customer needs visualizing current state of affairs avoiding waste continuous learning
Agile manifesto Process and tools Individuals and interactions over Following a plan Responding to change over Comprehensive documentation Working software over Contract negotiation Customer collaboration over cf. http://www.agilemanifesto.org/
Agile principles Satisfy the customer Welcome changing requirements 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
Sequential vs. overlapping development Source: “The New New Product Development 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
Continuous feedback cycle Team communicates in daily meetings about 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
Definitions of … Done (for current / last iteration) 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 ….
INVEST in SMART I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable S – Specific M – Measurable A – Achievable R – Relevant T – Time-boxed
The agile release train from SAFe incremental releases of 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/
Summary Agile methods build on top of lean principles Agile addresses problems of traditional PM problems by focusing on customer needs continuous learning embracing changes time boxing in iterations minimizing overhead