Your SlideShare is downloading. ×
Agile project management
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Agile project management


Published on

Learn Agile Software development in one hour by Bhawani Nandan Prasad

Learn Agile Software development in one hour by Bhawani Nandan Prasad

Published in: Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Agile Software Development Bhawani Nandan Prasad
  • 2. Objectives  Agile Development Basics Traditional methods Iterative development Benefits of iterative development Different flavors of Agile  “Managing” Agile projects Self-organization and self-management Tracking Agile projects (without micro-managing) PMBOK and Agile  Q&A
  • 3. Problems Companies Face  Excessively long “time to market” for products  Customer orientation is lacking  Over-engineered products (~60% features on a product are never used!)  Cost of delivering software is too high  Poor productivity of teams  Too much “wasted work” to fix defects and rework designs  Software quality is poor  Ability to responding to change is low  Employee morale is low (and attrition rates are high!)  Project failure rate is too high (~70% or more)  RoI delivered falls short of expectations
  • 4. Traditional Software Development Design Coding Testing DeployAdvantage: Logically sound Disadvantage: Assumes predictability! Analysis
  • 5. The answer …  Iterative development, done in small incremental chunks, validating requirements at each step  Agile development evolved in mid-90’s – the word “Agile” was adopted in 2001  Various flavors of Agile development include …  Scrum (the most popular)  Extreme Programming (or XP)  Crystal Clear  Adaptive software development  Feature driven software development  Dynamic Systems Development Method (DSDM); etc.  Has significant parallels with “Lean movement” in the manufacturing world, though they are not necessarily analogous
  • 6. Providing early value Value Realized Time Incremental delivery All-at-once Delivery
  • 7. Agile Manifesto – Feb 2001 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
  • 8. 12 Principles of Agile 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • 9. 12 Principles of Agile (continued) 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • 10. 12 Principles of Agile (continued) 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility.
  • 11. 12 Principles of Agile (continued) 10.Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • 12. Characteristics of Agile Process 1. Modularity 2. Iterative 3. Time-Bound 4. Parsimony - minimal number of activities necessary to mitigate risks and achieve their goals 5. Adaptive 6. Incremental 7. Convergent - actively attacking all of the risks 8. People-Oriented 9. Collaborative
  • 13. Scrum Basics
  • 14. Product Owner  Responsible for managing Project RoI and risk  Responsible for consolidating all inputs into what the team should produce and turn it into a prioritized “backlog”  Participate actively in the sprint planning and sprint review meetings and is available to the team throughout the sprint  Determines release plan and communicates to everybody
  • 15. The Team
  • 16. The team!  Ideally 7 people + or – 2 Has worked with as high as 15 and as small as 3 Team can be change between Sprints (better not to) Can be distributed (better results when co-located)  Cross-functional Posses all the skills necessary to produce an increment of potentially shippable product  Self Managing Empowered to do whatever is necessary to produce the potentially shippable product, within the constraints of the organization’s standards.
  • 17. Scrum Master!
  • 18. Scrum Master!  Scrum Master helps the team achieve success using Scrum by Serving the team Facilitate the team’s group interaction to help the team achieve its full potential Helps to remove blocks that are surfaced by the team Protecting the team Protects team from outside interference or disruption Supporting the team’s use of Scrum Organizes and facilitates Scrum related practices Reminds the team Scrum standards
  • 19. Product backlog
  • 20. Product backlog  List of everything that could ever be of value to the business for the team to produce.  Ranked in order of priority Priority is a function of business value and risk  Product owner can make any changes they want before start of a Sprint / Sprint Planning meeting It can be addition of new items, changing or removing or existing items or re-ordering them  Ideally for 2 sprints items should be well defined
  • 21. Example of product backlog
  • 22. Sprint planning meeting
  • 23. Sprint planning meeting  Goal:  For the team to make good commitment around what it will deliver by the end of the Sprint  What’s a Good Commitment?  Clearly understood by all  Shared among team  Achievable without sacrificing quality  Achievable without sacrificing sustainable pace  Attended by Team, Product owner, Scrum Master  Usually take 1-2 Hrs for each week of Sprint duration
  • 24. Sprint calendar – 2 week iterations
  • 25. Sprint backlog
  • 26. No changes during a sprint!  Once team has committed no changes  No changes to deliverables Details will emerge during Sprint, but no new work or substantially changed work Product Owner can terminate the Sprint if necessary  No Changes to Sprint Duration Sprint ends on planned date whether has completed its commitment or not  However Product Owner can make the changes to the remaining Product backlog before the start of the next Sprint
  • 27. Daily standup meeting
  • 28. Daily standup meetings  Every weekday  Whole team attends (including QA)  Everyone stands  15 minutes or less  Everyone reports three things What was able to accomplish since last meeting What will try to accomplish since by next meeting What is blocking me  No discussion, conversation until end of meeting  Update of artifacts after standup
  • 29. Closing a sprint
  • 30. Sprint review Purpose of Sprint Review Demo (not power point presentation) what the team has built Generate feedback which Product Owner can incorporate in the product backlog Attended by Product Owner, Managers, Scrum Master and Team Usually lasts 2 Hrs Followed by Sprint Retrospectives
  • 31. Sprint retrospective  What it is? 1-2 Hr meeting followed by each Sprint Review/Demo Attended by Product Owner, Scrum Master, Team What’s working and what could work better  Why does Retrospective matter Accelerate visibility Accelerate actions to improve It’s a key mechanism of continuous improvements (Inspect & Adopt)
  • 32. Advantages of Agile Development  Customer is able to see “value” much faster Near releasable product every 2 weeks!  Reduces “waste” by continuously validating the output  Forces orderly management of changes during the life-cycle
  • 33. Disadvantages of Agile development  Scrum doesn’t fix anything, team has to do it  May feel like things are worse at the beginning due to Scrum makes all dysfunction visible  Bad product will be delivered sooner  Some team or Organization are not ready for it  Team willingness is important  Managements active support is important  Inevitably some people will get fed up and leave  Partial adoption is worse than none
  • 34. Agile or Waterfall? If Waterfall is working for you, don’t use Scrum! – Ken Schwaber See link: http://leadinganswe rs.typepad. com/leading_ answers/files/ agile_suitabilit y_filters. pdf
  • 35. Engineering best-practices  Teams need to be prepared to work with “minimal” specifications  “Test-driven” development  Continuous integration: “Automated” builds and tests  Highly functional, motivated teams are needed  Ability to work in cross-functional teams is critical
  • 36. “Managing” Agile projects  Note that Scrum does NOT talk about a role for “Manager” or “Project Manager”.  So what do Managers do on Scrum projects?  A project manager or coordinator operating in a “matrix” environment can be trained to morph into a Scrum Master  Line managers (who have reporting authority) should …  Be the “Functional” and/or “Technical” expert  Help the team understand the larger context of the project  “Protect” the team during prioritization battles  Foster the right “culture” in the team  Act as a mentor or a coach to the team  Represent the team at external forums  Be risk managers for the projects
  • 37. Release Planning  Though Sprint contents can change, there often needs to be a long- term “roadmap” for software projects – evolved during “release planning” sessions  What should happen during a release planning?  Prepare of a release roadmap with “epics” defined at high level  High-level guesstimate of what and how much can be accomplished in a release  Identify project dependencies on external factors or events  Prepare and secure approval for a high-level project plan with milestones  Mode of release planning  Usually face-to-face, lasting up to a week  The entire team need not attend– key representatives should be identified  Product Owner and optionally other stakeholders can attend
  • 38. Tracking Agile Projects  Contrary to perception, managers should NOT micro-manage Scrum teams  Tracking mechanisms Daily stand-up meetings Scrum-of-Scrums (for bringing a number of inter-related Scrum teams together) Burn-down chart (automated or manual) Progress chart  Common metrics in Agile Velocity (Stories/Story points delivered/Sprint) Stories Delivered/Stories Planned Scrum Maturity Model
  • 39. Burn-down chart
  • 40. Progress chart
  • 41. Agile and Process (Myth V/s Reality) Myth Reality Agile means no documentation Agile means “just-enough” documentation Agile works on “trust” and is informal, hence cannot work with CMMi and other process models Agile actually enforces discipline and frequent check points. Many CMMi Level-5 and ISO certified teams use Agile Agile works only with “mature” teams Having a mature team helps, but it is no different from conventional models Agile works only when teams are co- located Co-location helps communication, but it is no different from conventional models Agile is cowboy programming, does not allow any time for design Agile calls for “just-enough” design effort – nothing stops teams spending time on design
  • 42. Tools used in Scrum project management  In principle, Agile likes simple, easy-to-use tools. Agile projects can very well be managed using post-its, spreadsheets, etc.  Some of the other tools in vogue are … Rally ( Mingle ( project-management) Scrum Desk ( VersionOne ( X-planner ( (open-source)
  • 43. Agile and PMBOK  All the Agile practices can be mapped to the processes in the PMBOK  Agile is a wonderful framework (mainly) for executing and monitoring/controling processes  But 23 processes in the PMBOK have no matching practice in Agile  Agile does not obviate the need for conventional project management methods, but “supplements” it
  • 44. Agile and Program Management Programs may contain components (projects) executed in the Agile model The challenge is to make sure that dependencies are identified out and honored Projects to compromise flexibility for getting more predictability in programs
  • 45. Iteration Wise Features & Dependencies Product = <name> IC #1 IC #2 IC #3 IC #4 IC #5 IC#6 IC >6 Key Features/ Themes in IC 1. Asset & Network Discovery (without Topology) 1. Agent detection 2. Normalization/ reconciliation of Windows data with CD 1. Normalizatio n of Windows and Unix # 1 2. Agent detection – queries and GUI configuration • Normalized Unix and Windows asset discovery # 2 • GUI-based Domain import • New database support (Oracle 10g, SQL Server 2005) • GUI wizard optimization (grouping methods) 1. Model convergence to CDM (Classes and atributes) 2. Unix & Windows normalization 3. Map sharing, 4. export (filtering per instance via GUI) 5. Wizard parameters ordering 1. GUI features and model change finalization 2. Other discoveries and asset data normalization (tokenid generation and export to CDM) 3. Domain hostname management (allow hostname entry) 4. Wizard paramenters ordering 1. Bug-fixes 2. Integration with any revised drops 3. Documentation Delivered On: Best Case Date = Most Likely Date = Worst Case Date = 12/20/2006 12/16/2005 12/23/2005 1/17/2006 01/13/2006 01/17/2006 01/21/2006 1/31/2006 01/27/2006 01/31/2006 02/06/2006 02/16/2006 02/10/2006 02/14/2006 02/21/2006 02/21/2006 02/24/2006 02/28/2006 3/1/2006 3/6/2006 3/8/2006 Product dependencies (need) IC #1 IC #2 IC #3 IC #4 IC #5 IC #6 <Project> (by worst case date) ABC 2.0 locked down 12/9/2005 Unit tested drop of XYZ 5.3 1. ABC 2.1 early access drop 1. ABC 2.1 early access drop 1. XYZ 5.3 release candidate drop XYZ 5.3 release candidate drop) XYZ 5.3 release candidate drop <Project> (by worst case date) <Project> (by worst case date) <Project> (by worst case date)
  • 46. Integrations and Dependencies  NOT on Track  Concern  On Track Product using this product Suppor ted Revisio ns Stat us Comments, Issues, notes ITSM 7.0  SIM (via CMDB) 7.0  Product dependency (used by this product) Suppor ted Revisio ns Stat us Comments, Issues, notes CMDB 2.0  Mostly on track. Only issue is that TD needs “early access” drops of CMDB before the drop dates to ensure that nothing blocks the inter-op cycle Marimba CD 7.0  Need to discover Marimba agent and reconcile output with CD
  • 47. Important links Scrum Alliance  Wikipedia on Scrum  t)
  • 48. Thank You