4. Project Management Process Groups – PMBOK 4th Edition
Knowledge Monitoring &
Initiation Planning Executing Closing
Areas Controlling
Integration Develop Project Charter Develop Project Direct & Manage Project Monitor & Control Project Close Project or Phase
Management Plan Execution Work
Perform Integrated Change
Control
Scope Collect Requirements Verify Scope
Define Scope Control Scope
Create WBS
Time Define Activities Control Schedule
Sequence Activities
Estimate Activity Resources
Estimate Activity Durations
Develop Schedule
Cost Estimate Costs Control Costs
Determine Budget
Quality Plan Quality Perform Quality Assurance Perform Quality Control
HR Develop HR Plan Acquire Project Team
Develop Project Team
Manage Project Team
Communications Identify Stakeholders Plan Communications Distribute Information Report Performance
Manage Stakeholders
Expectations
Risk Plan Risk Management Manage and Control Risks
Identify Risks
Perform Qualitative Risk
Analysis
Perform Quantitative Risk
Analysis
Plan Risk Responses
Procurement Plan Procurement Control Procurements Administer Procurements Close Procurements
5. Project Management Process Groups – PMBOK 4th Edition
Knowledge Monitoring &
Initiation Planning Executing Closing
Areas Controlling
Integration Develop Project Charter Develop Project Direct & Manage Project Monitor & Control Project Close Project or Phase
Management Plan Execution Work
Perform Integrated Change
Control
Scope Collect Requirements Verify Scope
Define Scope Control Scope
Create WBS
Time Define Activities Control Schedule
Sequence Activities
Estimate Activity Resources
Estimate Activity Durations
Develop Schedule
Cost Estimate Costs Control Costs
Determine Budget
Quality Plan Quality Perform Quality Assurance Perform Quality Control
HR Develop HR Plan Acquire Project Team
Develop Project Team
Manage Project Team
Communications Identify Stakeholders Plan Communications Distribute Information Report Performance
Manage Stakeholders
Expectations
Risk Plan Risk Management Manage and Control Risks
Identify Risks
Perform Qualitative Risk
Analysis
Perform Quantitative Risk
Analysis
Plan Risk Responses
Procurement Plan Procurement Control Procurements Administer Procurements Close Procurements
7. Is this your approach?
Analysis
Design
Develop
Implement
Evaluate
8. Is this your approach?
Analysis
Design
Develop
Implement
Evaluate
Is it effective? Efficient?
9. The Agile Manifesto
“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
That is, while there is value in the items
on the right, we value the items on the
left more.”
http://www.agilemanifesto.org/
10. The Agile Manifesto
“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
Individuals and interactions
tools
Working software
- Working software over comprehensive
Customer collaboration
documentation
- Responding to change over contract
Customer collaboration
That is, while there is value in the items
on the right, we value the items on the
we value the items on the left more
left more.”
http://www.agilemanifesto.org/
11. The Agile Principles of useful
- Customer satisfaction by rapid delivery
software
- Welcome changing requirements, even late in
development
- Working software is delivered frequently (weeks
rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant
pace
- Close, daily co-operation between business people
and developers
- Face-to-face conversation is the best form of
communication (co-location)
- Projects are built around motivated individuals, who
should be trusted
- Continuous attention to technical excellence and
good design
- Simplicity
- Self-organizing teams http://www.agilemanifesto.org/principles.html
- Regular adaptation to changing circumstance
12. The Agile Principles of useful
- Customer satisfaction by rapid delivery
software
- Welcome changing requirements, even late in
development
- Working software is delivered frequently (weeks
rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant
pace
- Close, daily co-operation between business people
and developers
- Face-to-face conversation is the best form of
communication (co-location)
- Projects are built around motivated individuals, who
should be trusted
- Continuous attention to technical excellence and
good design
- Simplicity
- Self-organizing teams http://www.agilemanifesto.org/principles.html
- Regular adaptation to changing circumstance
13. The Iron Triangle
Traditional
Scope
Cost Schedule
Highsmith, Agile Project Management, p 21
14. The Iron Triangle
Traditional Agile
Scope Value
Cost Schedule Quality Constraints
Highsmith, Agile Project Management, p 21
15. Traditional vs what you
Plan Agile
expect to happen
Enforce the plan
Large, in-charge
PM
Directive, top
down
Use change
control
16. Traditional vs Agile
Plan what you expect
by iteration
Control is through
adaption/inspection
Use Agile proactively
to manage change
17. Why Agile?
>>
Less Defects QUALITY
productivity, faster time to
market
$$
Market alignment
Quicker identification of loser projects
LEAN
http://blog.mountaingoatsoftware.com/presentation-on-the-benefits-of-agile
23. As a .. .. <Us e r ro le>
I wa n t .. . <G o a l>
S o t h at .. .<B us i ne s s Va l ue>
24. As a learner, I want my elearning courses to
have open navigation so that I can freely move
through the course
As a SME, I want the elearning courses to have
linear navigation so that the learners progress
in an orderly fashion
As a manager, I want my employees to be able
to test out of content that they already know
so that the training is efficient and they’re back
to work as soon as possible
25. As a .. .. <Us e r ro le>
I wa n t .. . <G o a l>
S o t h at .. .< B us i ne s s Va l ue>
36. Classroom to Online
3.5 hrs classroom
Test out of lecture content
Scenarios with branching
Learner must pass test
37. 3.5 hrs classroom Test out of lecture content
convert PPT
Scenarios with branching Learner must pass test
to elearning
38. 3.5 hrs classroom Test out of lecture content
convert PPT
Scenarios with branching Learner must pass test
to elearning
create sb
create gfx
create audio
create ...
39. 3.5 hrs classroom Test out of lecture content
convert PPT
Scenarios with branching Learner must pass test
to elearning
create sb
create gfx
size = how
much effort
create audio
create ...
40. 3.5 hrs classroom Test out of lecture content
convert PPT
Scenarios with branching Learner must pass test
to elearning
storyboard
graphics
audio
create ...
41. 3.5 hrs classroom Test out of lecture content
convert PPT
Scenarios with branching Learner must pass test
to elearning
storyboard
graphics
audio
create ...
42. Daily Scrum
Meeting
Ask
What did you yesterday?
What will you do today?
What obstacles are there?
15 Minutes Only pigs, no chickens
43. Scrum Taskboard
in Sprint
story to do progress done Goal
unplanned next
44. Scrum Taskboard
in Sprint
story to do progress done Goal
burndown
unplanned next
51. Sprint Review /
Retrospective
Reviews what and was not
completed
Presents the “working” “Shippable”
Product
increment - demo
Reflects on what worked,
what didn’t
Identify improvements
76. References
David J Anderson, Kanban 2010
Jim Benson & Tonianne DeMaria Barry, Personal Kanban: Mapping Work |
Navigating Life
Pete Deemer, et al, The Scrum Primer, ver 1., 2010 http://
www.scrumalliance.org/resources/339
Jim Highsmith, Agile Project Management, 2010
Henrick Kniberg, Scrum And XP from the Trenches, 2007
Henrick Kniberg & Mattias Skarin, Kanban and Scrum, Making the most of
both, 2010
Project Management Body of Knowledge, 4th Edition, 2008
Ken Schwaber, Agile Project Management with Scrum
Ken Schwaber & Jeff Sutherland, Scrum Guide July 2011 http://
www.scrum.org/
Michele Sliger & Stacia Brokerick, The Software Project Manager’s Bridge to
Agility
Welcome to Agile for elearning development\nToday we&#x2019;ll look at Agile and explore some tools/methodologies that hopefully will be useful to you.\n\nYou&#x2019;ll probably discover that you&#x2019;ve been doing some of these proactices in the past. \n
Why do we manage? This isn&#x2019;t a rhetorical question. Why do we manage projects? \nANSWER - We need some structure so successes can be repeated versus the just do anything approach. \n
Identify appropriate agile practices for his/her organization.\nApply agile practices that align with organizational project practices.\n
From the Project Management Body of Knowledge (affectionately known as PMBOK) we have these knowledge areas and process groups. \nY&#x2019;all use these, right? Each and every day? CLICK The PMBOK is a guide rather than a methodology and is not intended to be applied uniformly. (it&#x2019;s there on Page 4) \nHowever, if you have a PMO, you probably have some prescribed PM process.\n\n
So why do we have problems with projects?\nResearch I&#x2019;ve read shows that 1 in 5 IT projects are likely to bring &#x201C;full satisfaction&#x201D; (Failure Rate, retrieved from http://www.it-cortex.com/Stat_Failure_Rate.htm 10/26/2011) and one survey showed that 37% projects are troubled and at risk of failure. \n\nA $5 million project that leads to an almost $200 million loss is a classic &#x201C;black swan.&#x201D; he average overrun was 27%&#x2014;but that figure masks a far more alarming one. Graphing the projects&#x2019; budget overruns reveals a &#x201C;fat tail&#x201D;&#x2014;a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%\n
You recognize this right? ADDIE. The waterfall approach may be the issue; you do Analysis, some approval gate, the start Design, etc. CLICK for build At Delta (and many orgs I&#x2019;ve consulted with), have a gated ISD process. What happens when you get to implement and something happened to change your content? If we have issues, imagine the challenges in software development\n\n
The Agile manifesto was a response to the waterfall approach to software development in February 2001. \nLet&#x2019;s reflect for a moment. What strikes you about the manifesto? WAIT and then click for reveal.\nAs one wag noted - &#x201C;It's generally not a good idea to mess with people who issue manifestos.&#x201D;\n\n
Here are the paraphrased principles behind the manifesto. Again let&#x2019;s reflect. What strikes you about these principles? CLICK to reveal next slide\n\n\n
Enough of these dense wordy slides, let&#x2019;s start to compare traditional project management to agile \n
The iron triangle, AKA the triple constraints, the trade off triangle. These variables limit our choices in managing our projects - Remember that old chestnut &#x201C;Good, Fast, Cheap; pick any two&#x201D; This is how we measure our project&#x2019;s success &#x2013; did it deliver on time and on budget. But where is quality? \nQuick question, what do we mean by scope? From PMBOK &#x2013; it&#x2019;s the sum of products, services and results to be provided by the project. \nRemember Jim Cameron&#x2019;s Titanic (the movie) - applying time/cost this project was not successful but generated $1.8 B gross revenue\nCLICK for reveal In Agile, our measures are: \nvalue to the customer, quality required to deliver continuous value and constraints (scope, schedule, cost)\n\n
Let&#x2019;s compare, traditional PM is about the plan and then enforcing to the plan, we don&#x2019;t like it when things don&#x2019;t go according to plan\n
In Agile, planning is closer to reality with short iterations, hey this plan ain&#x2019;t working, let&#x2019;s change. In the PMBOK, this is called rolling wave planning (progressive elaboration meaning that near term work is planned in detail while future work is planned at a &#x201C;higher&#x201D; level, p 135) Sadly many orgs and PMO don&#x2019;t embrace rolling wave. \n
from four studies - Agile delivers quality improvement of +63%, 70% decrease in code defects\nSalesforce.com more cumulative value in releases, lower dev costs, faster time to market \n\nBy Lean, it follows lean principles - Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build integrity in, See the whole\n\n
Here&#x2019;s a great visualization for Agile S/W development. VersionOne is an ATL company. You can get this poster from their website. Agile is incremental and iterative, using small, dedicated co-located and self organizing teams in close collaboration with a business customer. Agile is value-driven focused on delivering most important features first and in the ways the teams chose to work together TDD = test driven environment Refactoring = cleaning code for maintenance and enhancements\nAgile Project Management mode >> Envision - Speculate- Explore-Adopt-Close (Highsmith, p81)\n
So how can we make this work? Enough history and background&#x2026;\n\n
Agile gathers user stories for requirements and product expectations\n\n
From there we build a backlog, a set of requirements for something.\n
lets do a planning activity\n
you&#x2019;ll assume a role (the persona) and you will fill in the blanks\nAs a ______, I want _____ so that _____. \n
as example\n
my lovely assistants will distribute the post its and go forth. We&#x2019;ll timebox (more about timeboxing in a few) this and sdebrief\n\n3 minutes - who wants to share? Moving on....\n
let&#x2019;s talk about agile tools \n
CLICK to reveal. Better in many cases is determined by need and culture\nSo true in one&#x2019;s org. Lift and shifted practices don&#x2019;t always translate or work well when transplanted\n
what is this &#x2013; right it&#x2019;s a scrum, a way to restart play in rugby, in this game you advance the ball by passing the ball. Scrum is an agile tool/process/approach/methodology/framework that forces focus on delivering the highest business value in the shortest time. \nScrum has rules. Scrum calls for Sprints, rapid and repeated development and inspection of actual working software (every 2 or 4 weeks).\nThe business sets the priorities. Scrum teams self-organize to determine the best way to deliver the highest priority features. \nWith every Sprint, everyone can see real working software and decide to release it as is or continue to enhance it for another sprint.\n\n
The Scrum Guide updated in July, is a mere 17 pages. Ken Schwaber and Jeff Sutherland developed scrum. \nMicrosoft, Google, IBM, Siemens, John Deere, Lockheed-Martin, Time-Warner, Turner Broadcaating use Scrum\n\n
Who has heard about pigs and chickens? Pigs are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress.\n
Scrum Teams are self-organizing and cross-functional \nThe Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner is a sole person (NOT A COMMITTEE). The Product Owner clearly communicates vision and goals. For the Product Owner to succeed, the entire organization must respect his/her decisions. \n&#xA0;\nThe Team is responsible for delivering the product. The team is cross functional and typically 5&#x2013;9 members.\n&#xA0;\nScrumMaster facilities the Scrum, main role removing obstacles and &#x201C;enforces&#x201D; the scrum rules. The scrum master is likened to a servant leader. SM finds ways effective product backlog management; coaching self-organizing teams and facilitating scrum adoption in the org. The SM is a protector of the team from distractions\n\n\n\n
Here&#x2019;s what scrum looks like, we&#x2019;ll talk about Sprint Planning, the Daily Scrum meeting and Review/Retrospective in a moment\n
Is timeboxed to no more than 8 hours for one-month sprint (2 weeks, 4 hours)\nWhat will be delivered in upcoming sprint? How will the work be achieved? Product owner present the product backlog. The team figures out what can get done and selects the work for the sprint backlog. An important concept is what does &#x201C;DONE&#x201D; mean. The team will use group decision techniques to arrive at consensus - planning poker, fist of fives, other group techniques. \n\n\n
lets do an activity, organize with your neighbors,\nWe have two week sprints ...\n\n
I&#x2019;m the product owner and here&#x2019;s our story backlog\nYou&#x2019;ll take these stories and then break out the tasks and &#x201C;size&#x201D; your sprint and define what DONE is\n\nMandatory manager course 3.5 hours in classroom with lecture, case study and debrief with PPT (very bad PPT) Requirements are to allow test out of lecture content and add branching scenarios. If learner tests out, must do the scenarios and then successfully pass test for LMS credit. \n
CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
Let&#x2019;s take stories and break them down into tasks so we can plan our sprints and have something to &#x201C;ship&#x201D;. What are the tasks to create the storyboard, audio, scenarios, graphics, audio, tests, other stuff that can go into the courseware? CLICK to reveal The team then estimates effort (days, hours, points) and who is responsible. Finally - what is DONE. So pick one aspect to work with your group.\n\nQuick debrief\n
Daily Scrum - The team should be able to describe how it will work together each and every day. This is a standup meeting. NOTE - not a status meeting. \n
The Daily Scrum meeting occurs in front of the Taskboard. How is this visible? Transparent?\nQuestions? CLICK to reveal burndown Measures, I need measures, I went to metrics session this morning\nSo how do you measure this Sprint stuff?\n\n\n
Does everyone know what burndown means? You look at the work remaining over time and you want to see if you&#x2019;re on track. Think of those 60 mile cancer walks, end of day 1 you should have walked 20 miles. \n\n\n\n
bad\n
Not so good either, can do way more stories off the sprint backlog\n\n
here&#x2019;s real &#x2018;tho messy burndown chart.\n
CLICK TO REVEAL. At the end of the sprint, you will conduct a Sprint Review and a Sprint Retrospective. These are two events\n
Sprint review is the show and tell. Retrospective is the lessons learned and what can we improve in next sprint\n\n\n
Think Scrum can only work in the workplace? Here&#x2019;s a family Scrum board\n\n
And one for organizing weekend chores\n
Scrum in summary \nWhat are the roles? Product Owner, Team, &#xA0;Scrum Master \nHow long are SPRINTS typically? 2-4 weeks\nMeetings? \nQuestions about SCRUM Can you do something like this in your org?\nSunGard presented in an online forum in Feb 2011 in using Scrum in developing learning paths for EE, they used this across departments using Agile approaches - developed learning game prototypes for testing (some on paper)\nIn the same OLF, Lowes&#x2019; developers presented Applying Agile Game Development Techniques to E-Learning\nWikispeed used lean/agile/scrum software-development process WIKISPEED has designed and built the SGT01&#x2014; a 100 mpg, four-seat commuter car with a mid-engine and rear-wheel drive with goal to mass produce this car price of under $20,000 USD.&#xA0;http://www.wikispeed.com\n\nAnyone have some examples?\n\n
Kanban from Japanese means signboard, foundational to the Toyota Production System. Kanban can be defined as &#x201C;visual card&#x201D;\n\n
Visualizing the flow of work and making it visible is core to building an understanding how work works. Limiting work-in-progress implies a pull system across the workflow - yes this is PULL. Flow of work through each state in the workflow should be monitored, measured and reported. Handoff, what&#x2019;s &#x201C;done&#x201D; or ready for testing really mean must be explicit. Agree that you need (and want) to improve. Kanban doesn&#x2019;t timebox per sprints. You&#x2019;re pulling from the backlog.\n\n
from David Anderson&#x2019;s Kanban Start with what you do now with the roles and processes you have. Agree to pursue incremental, evolutionary change. The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. You start by planning, devising a system for the work. Remember, this grew out of software development with the goal of regular delivery of working product. We can do the same thing. \n\n\n
CLICK for flow Here&#x2019;s a sample Kanban board. Backlog from planning meetings (some type of process) Note in this case we&#x2019;re limiting the WIP to 3, We have some stories in testing and a bunch DONE. \n\nBacklog from planning meetings (some type of process) - planning poker, fist of five, managers meet and give backlog, etc. \n
Here&#x2019;s a real world example.\n
lets do an activity, go back to your groups, take your sprint backlog discuss and arrive at your WIP limit.\n
CLICK for flow Here&#x2019;s a sample Kanban board with urgent. CLICK Once an item moved into testing, we have capacity. Rather than picking from the backlog, we pull the urgent task. B\n
CLICK for flow Here&#x2019;s a sample Kanban board with urgent. CLICK Once an item moved into testing, we have capacity. Rather than picking from the backlog, we pull the urgent task. B\n
Other tools exist many with free trials or limited free access\nhttp://www.versionone.com/; http://agilezen.com/; http://www.rallydev.com/index.php\n\n
Here&#x2019;s a personal Kanban board from a PMI colleague\n
Use a Kanban board, build it to suit your org and work flow. Pull systems will expose bottlenecks. Limit WIP, reducing WIP will increase quality. Be explicit in process, don&#x2019;t just throw over the cube wall. Deliver often - delivering small high quality releases will build trust. Make continued, evolutionary improvements.\n
Reducing WIP shortens lead time (cycle time) Anderson, p 29\n\n\n
More frequent release of working stuff build trust with customers and the team\n\n
Pull the work from the backlog, everyone sees the backlog and what &#x2018;s coming next\n\n
It&#x2019;s on the board, transparent. What are questions are answered at the daily scrum meting?\n
Use a daily stand up, encourage daily interactions with product owner, the team, stakeholders Use the board!!!!\n\n
One of the tenets in Agile is adapting to different situations - from the Declaration of Interdependence. Remember your people change skills\n
Don&#x2019;t be afraid to do a mashup &#x2013; turns out in 1995 at Delta in Video Services we were using Scrum-like, Srum-ish, Scrumban to manage our episodic production &#x2013; who knew? From David Anderson tweet - 10/18 "If there is a way to do Kanban wrong, it's to copy someone's existing process."\n\n
try it, run a pilot, do it in stealth mode, experiment, be patient and don&#x2019;t be afraid to fail, you may learn something. \n\n