Fluent Essays

525W4 Assignment 2 - Using SCRUM, DSDM, and Lean Software Development Assignment 2: Using SCRUM, DSDM, and Lean Software Development Worth 110 points The following Website may be helpful when completing this assignment: DSDM Consortium, located at http://www.dsdm.org/ The following resources may be helpful when completing this assignment and are located in Week 4 of the course shell: “Product Development with Scrum” (You may also view the article at http://www.agilelogic.com/files/ProductDevelopmentWithScrum.pdf.) “Agile Project Management and the Real World” (You may also view the article at www.diglib.org/wp-content/uploads/2011/01/01PMGLynema.pdf.) “Lean Software Development” (You may also view the article at http://www.projectperfect.com.au/info_lean_development.php.) There are a number of frameworks that have been used for agile development and project management. The purpose of this assignment is to discuss how projects are planned and executed in SCRUM, Dynamic Systems Development Model (DSDM), and Lean Software Development. Using real-world examples in your assignment is highly desired. One way to do that is to relate any projects at your workplace or from your research and think about how you, as a project manager, would run the same project under those frameworks. Write a five to six (5-6) page paper in which you: Analyze the manner in which projects are planned and executed under the following frameworks and provide one (1) example for each: SCRUM DSDM Lean Software Development Highlight three (3) benefits and three (3) trade-offs for each of the following frameworks: SCRUM DSDM Lean Software Development Determine the potential obstacles for using the following frameworks and analyze the major risks and issues associated with each of them. SCRUM DSDM Lean Software Development Suggest key strategies from the perspective of a project manager to avoid the obstacles you have identified in Question 3. Recommend key actions that you can take in order to mitigate the risks associated with those frameworks. Provide three (3) real-world examples to support your suggestion. Use at least four (4) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources. You may use the resources above or others of your choosing. Your assignment must follow these formatting requirements: Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format. Check with your professor for any additional instructions. Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page and the reference page are not included in the required assignment page length. The specific course learning outcomes associated with this assignment are: Compare and contrast among agile coaches, Scrum Masters, project managers, and technical leads. Analyze and differentiate among the different agile project delivery frameworks. Use technology and information resources to research issues in advanced agile project management topics. Write clearly and concisely about advanced agile project management topics using proper writing mechanics and technical style conventions. Click here to view the grading rubric. w4_assignment_2___using_scrum__dsdm__and_lean_software_development.docx agile_project_management.pdf lean_software_development.pdf productdevelopmentwithscrum.pdf Unformatted Attachment Preview 525W4 Assignment 2 - Using SCRUM, DSDM, and Lean Software Development Assignment 2: Using SCRUM, DSDM, and Lean Software Development Worth 110 points The following Website may be helpful when completing this assignment: • DSDM Consortium, located at http://www.dsdm.org/ The following resources may be helpful when completing this assignment and are located in Week 4 of the course shell: • “Product Development with Scrum” (You may also view the article at http://www.agilelogic.com/files/ProductDevelopmentWithScrum.pdf.) • “Agile Project Management and the Real World” (You may also view the article at www.diglib.org/wp-content/uploads/2011/01/01PMGLynema.pdf.) • “Lean Software Development” (You may also view the article at http://www.projectperfect.com.au/info_lean_development.php.) There are a number of frameworks that have been used for agile development and project management. The purpose of this assignment is to discuss how projects are planned and executed in SCRUM, Dynamic Systems Development Model (DSDM), and Lean Software Development. Using realworld examples in your assignment is highly desired. One way to do that is to relate any projects at your workplace or from your research and think about how you, as a project manager, would run the same project under those frameworks. Write a five to six (5-6) page paper in which you: 1. Analyze the manner in which projects are planned and executed under the following frameworks and provide one (1) example for each: a. SCRUM b. DSDM c. Lean Software Development 2. Highlight three (3) benefits and three (3) trade-offs for each of the following frameworks: a. SCRUM b. DSDM c. Lean Software Development 3. Determine the potential obstacles for using the following frameworks and analyze the major risks and issues associated with each of them. a. SCRUM b. DSDM c. Lean Software Development 4. Suggest key strategies from the perspective of a project manager to avoid the obstacles you have identified in Question 3. Recommend key actions that you can take in order to mitigate the risks associated with those frameworks. Provide three (3) real-world examples to support your suggestion. 5. Use at least four (4) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources. You may use the resources above or others of your choosing. Your assignment must follow these formatting requirements: • Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format. Check with your professor for any additional instructions. • Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page and the reference page are not included in the required assignment page length. The specific course learning outcomes associated with this assignment are: • Compare and contrast among agile coaches, Scrum Masters, project managers, and technical leads. • Analyze and differentiate among the different agile project delivery frameworks. • Use technology and information resources to research issues in advanced agile project management topics. • Write clearly and concisely about advanced agile project management topics using proper writing mechanics and technical style conventions. Click here to view the grading rubric. Agile Project Management and the Real World Emily Lynema DLF Fall 2010 November 1, 2010 Outline • • • • Why care about project management? Traditional vs. Agile What is Agile? What is Scrum? • Agile case study: NCSU • Making choices • Resources Why care? • You have too much to do • NCSU Libraries – 6 developers – 33 Digital Library staff – >250 library staff • Core Information Systems – 3 full-time developer positions – 18 supported applications – 10 in active development What makes it harder? • • • • • • Priorities change frequently Requirements change frequently No defined business analysts Emergencies happen every day Many projects across few people Everyone handles full life cycle And it keeps going…. • IT black box – How long? – When will it be ready? – When will you work on my stuff? – Are you actually doing anything? – What do I have to do to get something done? Traditional Project Management …… Agile Project Management ……. What‟s the same? • A project is still a project: – Vision – Life cycle – Requirements – Schedule – Team – Communication mechanisms Project Life Cycle Agile: iterative 1. 2. 3. 4. 5. 6. Envision Speculate Explore Adapt Close Repeat 3 – 5 as necessary Traditional: waterfall 1. 2. 3. 4. 5. 6. Initiate Plan Define Design Build Test Taken from Highsmith, James (2010). Agile project management: creating innovative products What‟s different? • Traditional – Plan all in advance – Work-breakdown structure – Functional specs – Gantt chart – Status reports – Deliver at the end – Learn at the end – Follow the plan – Manage tasks • Agile – Plan as you go – Feature-breakdown structure – User stories – Release plan – Story boards – Deliver as you go – Learn every iteration – Adapt everything – Manage team What is Agile? “Agile development is a method of building software by empowering and trusting people, acknowledging change as norm, and promoting constant feedback” Shuh, Peter (2005). Integrating Agile Development in the Real World. p.2. What is Agile? “The formula for success is simple: deliver today, adapt tomorrow. ” Highsmith, James (2010). Agile project management: creating innovative products. p.29. What is Agile? • Response to waterfall approach • Values: – Individuals and interactions – Working software – Customer collaboration – Responding to change Manifesto for Agile Software Development. Accessible at http://agilemanifesto.org/ Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Manifesto for Agile Software Development. Accessible at http://agilemanifesto.org/ Agile Principles 2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. Manifesto for Agile Software Development. Accessible at http://agilemanifesto.org/ Agile Principles 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Manifesto for Agile Software Development. Accessible at http://agilemanifesto.org/ Agile Principles 4. Business people and developers must work together daily throughout the project. Manifesto for Agile Software Development. Accessible at http://agilemanifesto.org/ Agile Practices - Managerial • Collocate team members and customers • Allow team members to make decisions • Maintain quality of work life • Use information radiators for transparency and accountability • Daily stand-up meetings • Regularly evaluate processes Agile Practices - Technical • • • • • • • Build automation Automated deployment Continuous integration Simple design Collective ownership Refactoring Pair programming Project Life Cycle Agile: iterative 1. 2. 3. 4. 5. 6. Envision Speculate Explore Adapt Close Repeat 3 – 5 as necessary Traditional: waterfall 1. 2. 3. 4. 5. 6. Initiate Plan Define Design Build Test Taken from Highsmith, James (2010). Agile project management: creating innovative products Envision • Initiate project • Develop project vision, objectives, and constraints • Create a core team • High-level feature list Speculate • Plan and Define project • Gather initial broad requirements • Create initial backlog of features with user stories • Develop iterative high-level release plan – Velocity + story points – Must be adaptable over time! What is a user story? See Cohn, Mike (2004). User Stories Applied. It‟s the authoritative source for user stories. Agile Planning • 5 levels of agile planning – Vision – Roadmap (2 years) – Release (2 months) – Iteration (2 weeks) – Daily Image copyright CC-A-SA by jakuza http://www.flickr.com/photos/jakuza/2681648917/sizes/z/ Explore • Design, build, and test project • Iteration planning – Commit to user stories for iteration – Create and estimate technical tasks • Monitor progress – Daily stand-ups – Visual taskboard – Burndown chart • Working code = committed + tested Image copyright CC-A-NC by Gerry Kirk http://www.flickr.com/photos/gkirk/3352780464/ Adapt • Review everything! – Not part of traditional model • Customer demonstrations – Feedback used to plan next iteration • Technical review • Team performance – Do need to change process? • Project status – Do we need to re-align release plan? Close • Release (maybe) • Celebrate! Agile Development Methodologies • • • • • eXtreme Programming Crystal Lean Software Development Scrum Feature-Driven Development (FDD) What is Scrum? • Focuses on iteration management • Roles – Product Owner – ScrumMaster – Team • Artifacts – Product Backlog – Sprint Backlog A Scrum Sprint Image from www.mountaingoatsoftware.com/scrum A Scrum Sprint • Sprint Planning – Commit to certain functionality & estimate – Produces Sprint Backlog • Daily Scrum – 15 minutes @ start of day – What have you done since last Scrum? – What will do before next Scrum? – What obstacles? A Scrum Sprint • Sprint – Team does the work! • Sprint Review – Show off completed functionality – Add new requests / changes to backlog • Sprint Retrospective – What went well during the Sprint? – What could be improved for the next? Agile Case Study: NCSU Agile in Libraries • What makes agile challenging to apply in libraries? – Small development teams – Responsible for both operational support and development – Often *many* smaller projects to handle – Fewer defined project roles Why Agile @ NCSU? • • • • Tackle big problems in small pieces Be more transparent Be more adaptable Produce tangible results quickly and frequently What is Agile @ NCSU? • Loosely based on Scrum • Iterative development cycles followed by release • Ongoing, just-in-time planning & documentation • Collaboration with customers – Cross-functional teams w/IT point person – Developers participate Transition • Migrating from 6 week to 3 week cycle • Goals – Focus on fewer projects at a time – Increase collaboration and cross-training – Reduce complexity of planning – Easier to estimate and plan velocity – Easier to freeze requirements & projects – Technology spikes Real world • 3 week iteration – Speculate: release planning prior to start of iteration – Explore: 3 weeks development • Start with sprint planning • Re-align as necessary – Adapt • Expose to customers during cycle NCSU Toolbox • • • • • • • Requirements: Confluence + JIRA Product & Sprint backlog: JIRA Release planning: Google docs Sprint planning: Google docs + JIRA Daily Scrum Sprint review: Product Team meetings Sprint retrospective Speculate Release Planning • Ongoing – Each stakeholder team works with IT representatives to lay out functional priorities for upcoming releases – This is very flexible and changeable! • Core IT team prioritizes several projects each cycle Release Planning • 3rd week of previous iteration – High level overview of upcoming projects out 3 months – Prioritize projects for the next 3 week iteration with core IT staff – Goal: no more than 2 projects at a time – Just in time requirements gathering this week, if necessary Sprint Planning • Day 1 of iteration – 2-hour meeting – Include all development team members – Goal: utilize stories already entered in JIRA – Collaboratively create and estimate tasks for all stories – Collaboratively assign / volunteer for tasks Sprint Planning • Day 2 or 3 – Add up task estimates across projects – Ensure that individual developers are not over-committed – Scope down at project level or divide work as necessary Explore Development • Get it done • Daily scrum 10 – 15 minutes – Identify obstacles and priorities – Emphasize collaboration • Weekly review – How does progress look for cycle? – Requires estimation and work logging • Subversion -> JIRA integration Testing • “the weakest link” • Manual testing throughout iteration – Utilize weekly product team emails – Demo at regular meetings – Need automated testing! • Developers and IT product managers are first line of QA Adapt Weekly Review • How much progress are we making toward sprint goal? – Things are harder than you expect – New requests come in – Emergencies crop up Sprint Retrospective • Last day of iteration – Did we accomplish what we wanted to? – If not, why not? – What went well? – What would we do differently next time? Close Release • Release at end of cycle if approved – Stakeholders may prefer to wait for new features – Release can be delayed if testing is not performed during cycle – Need automated testing! • If release is large or complex, may need an entire cycle to test prior to release Things we‟ve learned • Prioritization difficult for library staff. – Work at release level or higher • Reduce „churn‟ by trying to focus on fewer projects within a given cycle. • Limit the unknown – don‟t combine new projects with new technologies. • Difficult to freeze plans for 6 weeks. Challenges • Many small projects to support at once – Not traditional for Agile practices – Each iteration can be a release • Difficult to estimate story points – Planning hindered with estimates at tasklevel only • Tough to fit it all into 3 weeks – Develop a rhythm of staggered release? Challenges • Difficult to develop requirements in time – True customer not collocated with team – Teams of librarians work slowly • Testing – How and when to automate for small projects? – No „QA‟ experts • Simultaneously handle support and development Outcomes • Positive movement across multiple projects – Individual development efforts timeboxed – In 2010, ~32 releases across 9 projects – Increased user satisfaction • Increased flexibility to adapt to changing priorities and needs Why Choose? • Traditional – Change is very expensive – Well-defined requirements – Project is familiar territory – Customer is difficult to communicate with • Agile – Change happens frequently – Requirements not well-defined – New technology or project domain – Customer isn‟t sure of what is desired Agile Tools • JIRA + Greenhopper – 10 users for $20 (local installation) – http://www.atlassian.com/software/jira/ – http://www.atlassian.com/software/greenhopper/ • Agile Zen – Free for one project (hosted) – http://agilezen.com/ • VersionOne – Free for one team (hosted) – http://www.versionone.com/ Online • Agile Manifesto http://agilemanifesto.org/ • Agile for All blog: http://www.agileforall.com/blog/ • Succeeding with Agile: http://blog.mountaingoatsoftware.com/ Books • Agile Project Management with Scrum ISBN: 073561993X • Agile Software Development with Scrum ISBN: 0130676349 • Managing Agile Projects ISBN: 0131240714 • Agile Project Management: Creating Innovative Products ISBN: 0321658396 Questions • Emily Lynema • Associate Head of Information Technology, NCSU Libraries • emily_lynema@ncsu.edu 1/14/2020 Lean Software Development PROJECT PERFECT Project Management Software Specialists in Project Infrastructure HOME OTHER S/WARE WHITE PAPERS ONLINE METHODOLOGY PM FOR STUDENTS MS ACCESS COMPANY Home - White Paper Index Free use of the only online process to select software. Includes dozens of templates. Sign up for our newsletter. Hear about new Project Management White Papers. Lean Software Development First published Mar 05 Dasari. Ravi Kumar Rating (Download pdf version) Introduction They may be clearly identified, but are poorly acknowledged. The problems of the software development planet are responsible for most of the project failures that force managements worldwide to put more rigid processes in place to ensure compliance. More stringent processes at each stage are making the whole process a “Concrete-Life jacket”. By using Lean Production/Manufacturing principles not only quality concerns and other issues can be resolved, but also a continuous improvement cycle can be built in to the process. This can help in improving the quality of the software solutions/products each time a new software solution/product is built. Root Causes of Software Failure In most of the unsuccessful projects the following factors are identified as the root causes: � When you subscribe you can download a free eBook Click Here to Join Frequently and Rapidly Changing Customer Requirements: The problem with the conventional software development approach lies in the assumption that customer requirements are static and can be defined by a predetermined system. Because requirements do change, and change frequently, throughout the life of most systems, they cannot be adequately fulfilled by a rigid design. Do It Right has also been misinterpreted as dont allow changes”. If the changes are not allowed customers are not satisfied. If the changes are allowed the company will have problems in delivering the software in compliance with the project base line. Centralized Decision Making At large the Software development firms still follow the traditional “control and command” style in decision-making concerning the projects. Every time a decision has to be made it has to come all the way from the top of the project organization structure. This method actually increases the lead-time and makes the whole process rigid and slow. Rigid Project Scope Management Holding the project scope to exactly what was envisioned at the beginning of a project offers little value to the user whose world is changing. In fact, it imparts anxiety and paralyzes decision-making, ensuring only that the final system will be partially outdated by the time its delivered. Managing to a scope thats no longer valid wastes time and space, necessitating inefficient issue lists, extensive trade-off negotiations and multiple system fixes. However, as long as limiting a project to its original scope is a key project management goal, local optimisation will flourish—at the expense of the projects overall quality. www.projectperfect.com.au/info_lean_development.php 1/7 1/14/2020 Lean Software Development Traditional Software Practices (Linear Development) Most of the quality issues in the software components are also because of the linearity in the development process that does not allow the iterations and quality checks to occur before the components move to the next stage in the development cycle. So the development progresses even there are some quality issues Bugs. Lean Manufacturing Principles The principles of Lean Manufacturing, which are summarized below, can be used as a framework, or a guideline to address most of the issues of software development world : Add nothing but Value 1. Eliminate waste 2. Minimize inventory 3. Do it right the first time Focus on those who add value 4. Empower those who add value 5. Practice continuous improvement Pull value from Customers 6. Meet customer requirements 7. Pull from demand 8. Maximize flow Optimizer the value tributary 9. Ban local optimisation 10. Partner with ... Purchase answer to see full attachment