Select Page

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
customer’s 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

Release plan

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

Task board for day one

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
“don’t 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 it’s
delivered. Managing to a scope that’s 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 project’s 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