Your SlideShare is downloading. ×
Introduction to Scrum.ppt
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

Introduction to Scrum.ppt

5,709

Published on

Published in: Business, Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,709
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
76
Comments
0
Likes
9
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. An Introduction By Mohan Late
  • 2. The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.
  • 3.  Approach is simple  It is more disciplined  Is well structured  the model itself progresses linearly through discrete, easily understandable and explainable phases  Provides easily markable milestones in the development process.
  • 4. "Many times, thinking things out in advance saved us serious development headaches later on. ... [on making a particular specification change] ... Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.“ - Joel Spolsky
  • 5.  Software projects that are stable  Unchanging requirements  Where it is possible that designers will be able to fully predict problems  Where it is possible that designers produce a correct design
  • 6.  A bug found in the early stages is cheaper in money, effort, and time, to fix than the same bug found later on in the process.  An early defect that is left undetected until development or maintenance is estimated to cost 50 to 200 times as much to fix as it would have cost to fix at requirements time
  • 7.  BDUF is poorly adaptable to changing requirements  BDUF assumes that designers are able to foresee problems without extensive prototyping.  There is an overhead to be balanced between the time spent planning and the time that fixing a defect would actually cost.  In most projects there is a significant lack of comprehensive written requirements.  In BDUF a lot of assumptions are made that later prove to be false e.g. The program's design should be perfect before people begin to implement the design
  • 8.  Doesn’t handle change very well  Requirements specifications are an abstraction and can be interpreted differently  Business engagement is high at the start of the project but then tapers off  Insufficient testing during development  Late integration  QA is trailer-hitched, so quality isn’t baked in and testing gets crunched at the end  Progress measured by task % complete  Often don’t know until it’s too late  Whole project planned up-front
  • 9.  16.1 % of projects as successful  31.1% of software development projects get cancelled  52.7% do not meet their original cost Conclusion:  The organization is immature and to aim for more maturity  More requirements documentation, more analysis, more planning and tracking
  • 10. "The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labour to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labour to perform the same task.― -Tom Clancy (The Sum of All Fears)
  • 11.  Business practices that accommodate changes.  Flexible model
  • 12. Project Success Factors Points 1. User Involvement 19 2. Executive Management Support 16 3. Clear Statement of Requirements 15 4. Proper Planning 11 5. Realistic Expectations 10 6. Smaller Project Milestones 9 7. Competent Staff 8 8. Ownership 6 9. Clear Vision & Objectives 3 10. Hard-Working, Focused Staff 3 TOTAL 100
  • 13.  Adaptive, empirical process  Small repeating cycles  Short-term planning with constant feedback, inspection and adaptation  Fail-early lifecycle
  • 14.  Breaks complex projects down into simpler mini-projects  Accommodates change easily  Improves ROI  Increased business involvement and satisfaction  Increased visibility  Lower development risk, higher quality, less defects  Produce incremental product quickly  Progress measured by running tested software  Early and regular process improvement
  • 15.  35 % of projects as successful  19% of software development projects get cancelled  46% do not meet their original cost  three reasons for the improvement in software quality—better project management, iterative development and the emerging Web infrastructure.
  • 16.  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan
  • 17. 1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software is delivered frequently 4. Working software is the principal measure of progress 5. Sustainable development, able to maintain a constant pace 6. Close, co-operation between business people and developers 7. Face-to-face conversation is the best form of communication Projects are built around motivated individuals, who should be trusted 8. Continuous attention to technical excellence and good design 9. Simplicity 10. Self-organizing teams 11. Regular adaptation to changing circumstances
  • 18.  Agile Modeling  Agile Unified Process (AUP)  Dynamic Systems Development Method (DSDM)  Essential Unified Process (EssUP)  Extreme Programming (XP)  Feature Driven Development (FDD)  Open Unified Process (OpenUP)  Scrum  Velocity tracking
  • 19. Scrum
  • 20.  Simple and scaleable  Empirical process  Short-term detailed planning with constant feedback provides simple inspect and adapt cycle  Simple techniques and work artifacts  Requirements are captured as user stories in a list of product backlog  Progress is made in Sprints  Teams collaborating with the Product Owner  Optimises working environment  Reduces organisational overhead  Detects everything that gets in the way of delivery  Fosters openness and demands visibility
  • 21.  Contains all potential features, prioritized as an absolute ordering by business value.  It is therefore the ―What‖ that will be built, sorted by importance.  It contains rough estimates of both business value and development effort.  Those estimates help the Product Owner to gauge the timeline and, to a limited extent prioritize.
  • 22.  Captures Product Vision  Represents the voice of the customer  Creates initial Product Backlog  Writes customer-centric items  Helps set the direction of the product  Accountable for ensuring that the Team delivers value to the business  Responsible for: ◦ Product Backlog ◦ Prioritization
  • 23.  Using story points instead of hours  numeric sizing (1 through 10)  t-shirt sizes (XS, S, M, L, XL, XXL, XXXL)  Powers-of-2 (1,2,4,8...)  the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)  Planning Poker  Basing on historical trends  The best people to make the estimates are the people who build the product.
  • 24.  These are the people who build products, make estimates  Scrum recommends team sizes of 7  The teams are cross functional
  • 25.  Combination of Coach, Fixer and Gatekeeper.  Make sure the project is progressing smoothly  Every team member has the tool they need to get the job done  Sets meetings  Monitors the work done  Facilitates release planning  to protect the team and keep them focused on the tasks at hand  servant-leader
  • 26.  Three core roles and a range of ancillary roles  Core Scrum roles: ◦ Product Owner ◦ Team ◦ Scrum Master  Ancillary roles: ◦ Stakeholders (customers, vendors) ◦ Managers (including Project Managers)
  • 27.  Start with the Product Backlog items  Identify features to put into release  Team prioritizes the features
  • 28.  Is an iteration  Can have 1 day of sprint planning, 4 days of work and 1 day of sprint review  Sprints are short duration milestones  Sprints range from a couple of days to 30 days  Need atleast 4 to a dozen sprints to get to the release
  • 29.  Break Release backlog items into several tasks  each sprint should deliver a fully tested product with all the features of that sprint backlog 100% complete  late finish of the sprint is a great indicator that the project is not on schedule
  • 30. Actual estimates for each feature in the backlog during the initial planning process
  • 31. Actual estimates for each feature in the backlog during the initial planning process Daily progress on one ore more features is updated by team member by updating the amount of time remaining for each of their items
  • 32.  Tracks bugs separately from features in their own Defect Backlog  Any bug found relating to the feature should be dealt with immediately before marking the feature complete  Plan for 1-2 sprints focused only on Defect backlogs
  • 33.  Should not last more than 15 minutes.  The meeting starts precisely on time.  Every team member has to answer 3 questions – ◦ What have I done since last meeting? ◦ What will I do until next meeting? ◦ What problems do I have?  ScrumMaster to facilitate resolution of these impediments  resolution should occur outside the Daily Scrum itself to keep it under 15 minutes
  • 34. Capitalizing software development costs – waterfall, agile and cloud.
  • 35.  Waterfall model  Agile methodologies  Cloud
  • 36.  Preliminary project stage or evaluation phase ◦ essentially R&D costs, and are charged to opex  Software development or application configuration phase. ◦ Capex, because the end result is an asset.  Post implementation or production phase ◦ This is opex because these are day-to-day running costs
  • 37.  Enterprise software licenses are capex, but the corresponding annual maintenance costs are opex.  Functional design is opex and technical design is capex, but the border between the two can be blurred when done by collaborative teams.  Production upgrades or enhancements are capitalizable, whereas maintenance and bug fixing are not, even though they both have development costs.  An ERP-to-CRM order entry interface is a capital cost, whereas a one-time ERP-to-CRM data migration interface is an expense.  Software as a Service or SaaS is pure opex. Even if you end up customizing a SaaS application, the development costs will still be opex because you are renting.
  • 38.  it is not the activity in itself that is capitalizable, but rather the outcome of that activity and the ownership of the resulting asset.
  • 39.  According to FASB, technological feasibility can be based on either a detailed design or a working product: ◦ Detailed design: ―The detail design of a computer software product that takes product function, feature, and technical requirements to their most detailed, logical form and is ready for coding‖. ◦ Working model (or prototype): ―An operative version of the computer software product that is completed in the same software language as the product to be ultimately marketed, performs all the major functions planned for the product, and is ready for initial customer testing (usually identified as beta testing)‖
  • 40.  In Scrum, technological feasibility is reached after a number of iterations after which capitalization can start  Amount of development costs which can be capitalized is less as compared to waterfall’s detailed design up-front approach  Iterative development generally requires far less time to reach technological feasibility compared to waterfall, which is heavily front-loaded with opex prior to the start of development.
  • 41.  A waterfall or an agile project can be developed and run either on-premises or in the cloud  For IaaS and PaaS ◦ Capex vs opex rules apply when developing the software using agile or waterfall.  For Saas, ◦ There is no software assets created by the client ◦ So, even if you end up customizing your SaaS CRM application, for example, the development costs will still be opex because you are renting. You don’t own the asset, ie it doesn’t sit on your company’s balance sheet.  Public SaaS is therefore pure opex, and the capex vs opex rules for waterfall and agile do not apply.
  • 42. Lean startup solutions We help you answer the question-‖Can a sustainable business be built around this set of products and services?‖ and ―How can we raise investment to do so?‖ We help startups follow the lean startup approach by providing tools to test a vision continuously. We help you right from building each component of a sustainable business model to weaving a financial model based on extensive market research to producing VC-friendly attractive data driven business plans. We strictly follow the Lean Startup methodologies and tools throughout our approach to help you solve real problems and provide detailed specifications of what needs to be done to build solution.
  • 43.  ValueFacture Lean Startup Consultant http://www.valuefacture.in  Email me at ◦ Mohan@valuefacture.com ◦ Mohan.Late@gmail.com  Skype me at ◦ mohan.late Disclaimer : No animals (pigs/chickens) were harmed in the making of this presentation.

×