Agile Methodologies for Project Management By – Komal Mehta

Agenda  What is Agile?  Why Agile?  Are we sure that Agile will succeed?  Birth of Agile  Agile Methodologies  SCRUM  Team Composition  Process  Artifacts  Timeline  Ceremonies  Take-away from this meeting

What is Agile  By Oxford dictionary  Agile means – “Able to move quickly and easily”  By IT Industry Standards  Set of methodologies to manage and run IT Projects

Why Agile?  Traditional Waterfall model has a frightening history of failure, in over 30 years of practice  68% of IT projects fail due to Poor Requirement  68% of IT projects have marginal or outright failure  41% of time is spent in Requirement gathering  Most projects take over 180% of target time  Most projects consume 168% of allocated budge  Overall 66% project failure rate These statistical evidences became a proponent of corrections in Requirement gathering, Estimations, Time, over consuming budget and project execution.

Are we sure that Agile will succeed?  Agile removes few blind assumptions made by traditional waterfall model  Customer knows all!  Customer has complete set of requirements while allocating projects to us!  Market conditions, sponsors, competitors will never have a better product idea!  Our processes are mature and don’t need revision!

Birth of Agile  Dr. Winston Royce in 1970 claimed the failure mode of traditional sequential development model.  Later in 2001 a group of 17 professionals met to brainstorm about the problem, and come up with a solution of continuous project failure.  They came up with few rules to run modern project management called - 4 Agile Values and 12 Agile Principles.

Agile Methodologies  SCRUM - we will focus here  Xtreme Programming (XP)  Feature Driven Development (FDD)  Dynamic System Development Method (DSDM)  Lean Software Development  Crystal

 Equated to a game of Rugby  A light weight project management framework based upon Agile model.  Software development based upon Iterative and Incremental framework.  2-3 weeks iterations.  Promotes Team work SCRUM In Rugby the whole team works towards the common goal to pass the ball and score goals.

SCRUM - Team Composition Product OwnerTeam  Identifies product features.  Maintains feature priority list.  Defines and elaborates user-stories  Defines acceptance criteria  Defines and coordinates a release  Promotes Team work  SCRUM expert  Process expert  Servant leader  Removes impediments / road-blocks  Resolves conflicts  Shields the team from outside pressures  Product quality owner  Composed of developers, testers, graphics designers, technical writers, etc. all as part of one team.  Commitment owner - authorized to make team, development, and execution commitments.  Negotiate for deliverables, in good faith of the project SCRUM Master

SCRUM - Process

Sprint Timeline  A sprint iteration of 10 days (2 weeks)  Sprint Planning - 1 Day  Sprint Development - 8 days (each day starts with a Standup meeting)  Sprint Review (Demo and Retrospective) - 4 hrs each

SCRUM Ceremonies  Sprint Planning  The daily stand-up meeting  Sprint Review  Sprint Retrospective

SCRUM – Sprint Planning  Sprint Planning  Product Owner discusses high priority user stories.  Team defines Sprint Goal.  Scrum Master communicates Team’s Velocity based upon historic performances  Team will post their queries to PO  Team discusses high level technical approach  Team commits User Stories for the sprint

SCRUM - Daily Stand-up  Status of Team, To the Team  Each member answers 3 questions  What did I do yesterday?  What will I do today?  Is there any road-block in my goal for today?  The road-blocks or Impediments are ToDos of Scrum Master.  These impediments should be resolved ideally in One Day, or ASAP to avoid harming sprint’s goal.

SCRUM - Sprint Review  Are all committed stories complete  Are features Acceptable to the Product Owner  Do the features meet Definition of Done.  Any changes or improvement should be added to Product Backlog as new tasks

SCRUM - Sprint Retrospective  Steps to conduct a retrospective  Set the Stage  Gather data  Generate insight  Decide what to do  Close the meeting  Is an group introspection exercise  What can we start doing ?  What should we stop doing?  What should we continue doing?

SCRUM - Artifacts  Incremental Product  Groomed up Product Backlog  Burndown & Burnup charts (these will help determine team’s Velocity)  Refined and detailed Sprint Backlog

Take-away from this meeting  Trust your team  Involve customer frequently  Get prioritized list of requirements  Refine requirements, refine estimates  Develop in chunks  Get frequent feedback  Retrospect and improve  Leverage available tools to automate and improve

Thank You  My thanks to:  YOU – the great audience!     “PMI-ACP Exam Prep” - Mike Griffiths  “Scaling Software Agility” - Dean Leffingwell