pmi-acp_copy_20230125221955 Flashcards
1
Q
Product roadmap
A
1) planned or proposed product releases2) listing high level functionality or release themes3) usually the target calendar or fiscal quarter4) 2 or 3 significant feature releases into the future.
2
Q
User stories/backlog
A
1) very high-level definition of a requirement2) containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.
3
Q
Story maps
A
1) Story Maps are a different way to visualize your Product Backlog2) This is a way of organizing stories that provides richer context and can help with release planning
4
Q
Progressive elaboration
A
continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and thereby producing more accurate and complete plans that result from the successive iterations of the planning process.
5
Q
Wireframes
A
1) It helps the team to communicate better internally as well as with the stakeholders. 2) The key lies in doing just enough and keeping the process lightweight. 3) It is also important that the wireframes are of a decent quality.
6
Q
Chartering
A
Creating a charter provides an opportunity for the team to begin demonstrating self-organization by articulating a shared project vision, defining their criteria for success and agreeing the working practices to be used.
7
Q
Personas
A
1) reduce waste by ensuring all solutions are aligned from their conception with real end-users needs, goals, capabilities, attitudes and behaviour. 2) act as a sounding board throughout the Agile process with features, information, content, and interaction.
8
Q
Agile modeling
A
Agile modeling
9
Q
Workshops
A
Workshops
10
Q
Learning cycle
A
Learning cycle
11
Q
Collaboration games
A
Collaboration games
12
Q
Features of good user story
A
IndependentnegotiablevaluableEstimableSmalltestable
13
Q
3 steps to create story map
A
1) Build the map2) Validate the map3) Plan the releases
14
Q
Five steps in progressive elaboration
A
1) Decide on release time box2) Look the requirements at the high level3) More accurate estimation at each sprint planning meeting4) End of iteration add the new information you have5) Repeat 3 and 4
15
Q
Personas type includes
A
Behavior patternsGoalsSkillsAttitudesMotivationEnvironment
16
Q
T-shirt sizing
A
Relative estimation| Small, medium, large, extra large, xx large
17
Q
wide band Delphi
A
1) consensus-based technique for estimating effort.2) Greater interaction and more communication between those participating3) Coordinator prepares and distributes a summary of the estimates4) Experts fill out forms, again anonymously, after discussing why their estimates differ widely
18
Q
planning poker
A
1) Reveal card at the same time2) Avoid bias3) Similar to expert estimation
19
Q
affinity estimating
A
1) quickly and easily estimate (in Story Points) a large number of user stories.2) Particularly starting of project3) It’s quick and easy; 4) it feels very natural; and, the entire decision making process is made very visible.
20
Q
ideal time
A
time spent exclusively on the task, with no interruptions and in a good work disposition
21
Q
Agile estimation overview
A
1) Part of adaptive planning process (increment)2) Estimates uncertain by definition3) Further out, the more inaccurate4) Complex problems cannot fully defined
22
Q
Cone uncertainity
A
1) Beginning relatively sized (t shirt)2) Narrow cone uncertainty as project progress 3) Story points and hours
23
Q
Size units
A
1) Real time (actual day / time)2) Ideal time (Assumption no interruption)3) Relative sizing (ideal estimation)
24
Q
Real time
A
Not realistic| Includes unproductive tasks
25
Ideal time
100% productive assumption8 ideal hours could equal 2-3 real daysRatio real to ideal not all consistent
26
Relative sizing
1) How much user story compared to other user story2) Does not equal any specific time3) Story points4) Fibonacci sequence
27
5 steps in affinity estimating
1) Silent relative sizing2) Wikipedia like editing wall3) Place Items into Relative Sizing Buckets4) Product Owner “Challenge”5) Get it into an Electronic Tool
28
Affinity size
minimum of 20 user stories to group
29
Normative methodologies
1) Sequence of steps known to solve the problem
30
information radiator
Any of a number of handwritten, drawn, printed or electronic displaysHighly visible location, all team members as well as passers-by can see the latest information at a glance
31
Team space agile tooling
tools for more effective communication (reduce roadblocks for collecting, maintaining and disseminating information)types: low-tech high-touch tools, digital tools
32
Osmotic communications for co-located and/or distributed teams
Way information flows of background hearingPickup relevant informationTune in or tune out whatever they hear
33
two-way communications (trustworthy, conversation driven)
Face to Face communication, email and chat
34
social media–based communication
social media–based communication
35
Basics of active listening
1) Focus your attention2) Take notes3) Paraphrasing4) Summarizing
36
Need for brainstorming
1) level the playing field and discourage dominating personalities2) the process helps increase the level of participation among ALL group members3) it allows all members to participate regardless of level of experience or tenure with the company
37
XP feedback methods
1) Pair programming2) Unit tests3) Continuous integration
38
Caves and commons
Common area, private area of working(caves), sharing information
39
Team space configuration example
Place office furniture in the center of the spaceEmpty wall space availableEasy access to low-tech / high touch tools and suppliesStock all of the team's required technology
40
Collaction
Solve problems informally and quicklyCompleting working instead of formal structure processCollaborate and communicate naturally
41
Distributed teams
Virtual team spaceVirtual high tech/low touch toolsVirtual daily stand-upsVirtual information radiators
42
Distributed teams challenges
Osmotic communication is not possibleSynchronization is difficultAll must work harder for basic communication and team goverance
43
Virtual team space
maximize team work productivity and focusGrouped with other virtual team membersWeb based info-sharing solution
44
Virtual team space best practices
Maintain a metaphor for the project vision| Frequent and multiple scheduled meetings
45
Distributed team concepts - Impacts
Globalization (Communication/collaboration issues,team sizes, process adjustments)Culture - agile approach differs from current cultureDiversity - (uniqueness of each team individual, independent thinking, creative and unique contributions)
46
Schneider culture model
```Dominant culture in the organizationCollaboration - ScrumControl - kanbanCompetence - agileCultivation - xp and scrum method```
47
Find dominant culture type
Understand values and principlesWhat is important to teamDiscover how people approach workhow people relate to one another
48
Questions in active listening
1) Prefer open-ended questions2) Clarifying questions3) Ask for more information4) Ask for their opinions and analysis5) When you aren't getting it, let the speaker know6) Listen all the way to the end
49
The Nuances in Active Listening
1) Use silence2) Body language3) Acknowledge, and ask about emotions4) Validate concerns5) Verify assumptions
50
Five Steps to Effective Brainstorming in Agile Projects
```Step 1: Who wants to Lead?Step 2: Ready, Set, Goal.Step 3: Got an Idea? Share it.Step 4: Put the Puzzle Together.Step 5: Solve it as a Team.```
51
The Generic Brainstorming Meeting Process
1) Location matters2) Have a specific purpose3) Know what you want, and what to do with it4) Know how to facilitate5) Put the focus on the list6) Comfort is key7) Establish the ground rules8) Postpone criticism
52
Scrum feedback methods
1) Daily scrum| 2) Sprint
53
Agile process which supports feedback
1) Code reviews2) Static code analysis3) Automated integration tests4) Automated acceptance tests5) Having the customer and business experts work closely with you throughout the process6) Increasing the frequency of releases tenfold (at least to test environments)
54
benefits of emotional intelligence
Improved leadershipMore effective handling & resolution of disputesMore effective development of team workingImproved negotiationsMore cost-effective decision makingBetter quality problem-solving & decision-making
55
Components of Emotional Intelligence
```Self AwarenessEmotional ResilienceMotivationInterpersonal SensitivityInfluenceIntuitivenessConscientiousness```
56
adaptive leadership
Being agileDoing AgileAdapting facilitative leadership
57
servant leadership
servant leadership
58
Agile negotiation - Key elements
Separate People from the ProblemFocus on Interests, not PositionsInvent Options for Mutual GainUse Objective Criteria
59
Conflict Resolution Diagram (CRD)
to better understand conflicts between two ideas or two courses of actionmay help to clarify a conflict of idea
60
Effective collaboration
1) Early involvement and the availability of resources to effectively collaborate2) A culture that encourages teamwork, cooperation and collaboration3) Effective teamwork and team member cooperation4) Defined team member responsibilities based on collaboration5) A defined product development process based on early sharing of information and collaboration6) Collocation or virtual collocation7) Collaboration technology
61
Four levers of change
Do LessSpeed-to-ValueQualityEngage/Inspire
62
Adaptive leadership - quality
Managing the technical debt| Incremental investment in addressing the technical debt situation.
63
Doing Less - Adaptive leadership
1) The project teams should do the simplest thing possible that delights the customer.2) deliver the right features.3) reducing work-in-process (WIP) and multi-tasking (duration/effort). 4) Agile value curve can be used to prioritize features between different projects in an organization to realize agility at the organizational level, not just at project level.
64
Engage/Inspire - Adaptive leadership
Agile leadership should encourage and promote the concept of self organizing teams that have autonomy, mastery, and purpose
65
Speed-to-Value: Adaptive leadership
Agile triangle - Value (releasable product), Quality (reliable, adaptable product) and Constraints (cost, schedule, scope)Need to be managed properly to realize the value.
66
Adaptive Leadership Behaviors
agile leader focuses on adapting successfully to inevitable changesadaptable versus predictableEnvision-Explore approach rather than a Plan-Do approachFacilitative in nature and encourage a collaborative engagement
67
Conflict Resolution Strategies
Get connected….how are you feeling?Own your it….what are the facts around your “it”?Make your decision….are you willing to release your “it”?Opt for action….Let it go!
68
Colloboration Process
1) Parallel performance of activities which require early sharing of information and feedback2) Deliverables that require input, review and approval by other team members3) Early supplier involvement and less formal procedures that enhance collaboration4) Defined responsibilities (e.g., responsibility matrix) that require multiple team members involvement in activities and deliverables
69
General Colloboration Tools and Technology
Email exchange of drawings, models and project information (asynchronous)Teleconferencing and videoconferencing (synchronous)Web-hosted meetings (synchronous)Project hosting tools to create one pool of all released project documentation, with email alerts for updates (asynchronous)Drawing viewing sites (intranet and web-based) with view and mark-up capabilities (asynchronous)CAD collaboration sessions (synchronous)Workflow and groupware software (asynchronous)Product data management, product information management, collaborative product commerce (generally asynchronous)
70
Overview of velocity
Extremely simple, powerful method for accurately measuring the rate at which teams consistently deliver business value. Simply add up the estimates of the features (user stories, requirements, backlog items, etc.) successfully delivered in an iteration.
71
Throughput
Throughput
72
productivity
productivity
73
cycle time
1) time between two successive deliveries2) 34 enters the Deployed stage on day 11, then two days after, the next story-- Story 37--enters the Deployed stage; cycle time equals 2 days (day 13 – day 11).
74
lead time
1) time between the initiation and delivery of a User Story2) Story enters the Deployed stage minus the time the story has entered the Backlog stage.3) Story 34 has entered the Backlog in day 4, and enters the Deployed stage on day 11; lead time equals 7 days (day 11- day 4).
75
EVM for agile projects
1) Establish baseline2) Measure progress at defined boundaries3) Current iteration number.4) Number of story points actually completed.5) Number of story points added to or removed from the release.6) Actual Cost in dollars or hours. It is critical that the actual cost amount used reflects the cost needed to generate the completed story points.
76
Escaping defects
1) should then be treated as ranked backlog work items2) Watch the defect backlog as part of the project metrics3) A growing defect backlog is a key indicator that the team is taking on more new work than it can handle4) requiring more collaboration between Dev and Quality Engineers and early testing5) Drop the number of new items the team works on until the escaping defects are well managed or eliminated.
77
Approved iterations
approved iterations
78
work in progress
work in progress
79
Why is Velocity Important in Agile
After you do a few iterations, you will become better at estimating and your velocity should start to stabilize. With a stable velocity, planning releases and iterations becomes much easier. Management and the business are also loads happier as you are delivering standard size iterations with less surprises.
80
How is the first iteration's velocity estimated?
1) one-third of available time if estimating in ideal programmer time2) If underestimated, velocity in the first iteration will rise as new features are included; 3) if overestimated, velocity will decrease as features are removed.
81
Should velocity be accumulated across teams or projects?
1) Velocity is very much a localized measure2) different team members with different team 'personalities', projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement
82
What if velocity fluctuates?
1) Velocity will typically fluctuate within a reasonable range, which is perfectly fine. 2) If velocity fluctuates widely for more than one or two iterations, the team may need to re-estimate and/or renegotiate the release plan.
83
How do I estimate velocity if project teams change size?
1) Velocity relies on team consistency in order to be most valuable. 2) It will only take the length of the next iteration to understand better what the team can deliver and thus their new velocity.
84
Does maximum velocity mean maximum productivity?
1) Absolutely not. 2) In an attempt to maximize velocity, a team may in fact achieve the opposite. 3) there will be a negative long-term impact.4) The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
85
How do we measure velocity if our iteration lengths change?
1) A fixed iteration length helps drive the reliable rhythm of a project. 2) Without this rhythm, you are constant revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results3) adapt iteration dates or velocity accordingly
86
Agile resource utilization
1) Capacity (individual, team) -during iteration planning2) Estimated3) Actual (recorded before standup meeting)4) Performance (compare capacity vs actual)
87
Estimated utilization
1) Capacity vs Estimated (iteration level)2) E=64 hrs, C = 60hrs3) utilization = E / C = 106.67%
88
Actual utilization
1) Actual 55hrs2) estimate 64hrs3) capacity 60hrs4) Actual utilization = actual / capacity = 91.67%
89
three categories of defects
1) Defects found and fixed in the iteration2) defects accepted by PO3) defects that escapted
90
Defect detection rate
1) No, of defects per project iteration2) correlated with velocity3) drop in velocity & rise in defect detection rate should trigger an alarm4) low rate is not better than a higher one
91
Defect closure rate
1) amount of defects fixed and closed per iteration2) should be equal to defect detection rate3) if
92
Total vs closed defects
1) should be as low as possible| 2) indicates velocity and burn rate are reliable indicators
93
A healthy agile project
1) Stable velocity and burn rate2) high defect detection rate3) low total vs closed defects gap
94
Agile approved iterations
1) approval is documented2) by PO or customer3) after passing definition of done (before end of iteration)4) sometimes after end of iteration5) document guidelines and criteria
95
reviews
reviews
96
Kanban board as information radiator
1) Kanban board2) Burndown charts3) Parking lot charts4) Calendars
97
timeboxing
Core aspect of rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development.
98
Advantages of iteration
1) Velocity can be measured and scope can be adjusted quickly2) forces work into byte sized chunks where define/build/test cycle has to be concurrent3) More opportunity to succeed or fail early
99
Challenges with Variance Analysis
Time DelayVariance Source InformationStandard setting
100
WIP limits
WIP limits
101
burn down charts
1) A burn-down chart tracks how much work remains on your project and whether you’ll hit your deadline.2) The vertical axis measures work remaining. The horizontal axis marks your iterations
102
cumulative flow diagrams
1) Graphic depiction of how stories are moving through various statuses on the way to being “Done”2) Total scope of a project, grouped by status, and thus lets us know how much of that scope is in a particular status at a given time
103
backlog grooming/refinement
backlog grooming/refinement
104
product-feedback loop
product-feedback loop
105
Planning initiation concepts
d
106
Planning overview
1) Work is not predictable, so adapt2) Just in time approach to planning3) Frequent customer involvement4) Success linked directly to proper agile planning
107
monitoring overview
all members Responsible release level and iteration level monitoringCorrective action implementationMajority monitoring and iteration level
108
adapting overview
Occurs at all levelIncludes all stakeholdersMinimize what isn't working and optimize what is workingPerformed continuously throughout project
109
Project planning initiation tools
1) Project charter2) Business case3) Statement of work4) Project Data Sheet5) Project Kickoff meeting
110
Project charter
1) Before agile strategic planning2) Includes how to execute the project3) Processes not in Organization's operating procedures4) Max 2 to 3 pages in length
111
Kanban
1) card or sign2) standard units or lot sizes with single card attached to each3) New card is pulled into the system only when the work represented by an "in progress" card is completed
112
Kanban board
1) Visualization tool| 2) Use a card as a token of task, feature and stick them to a timeline(board)
113
Burndown charts(kanban)
1) Count the number of Kanbans(backlog task) and track it in a timebox2) Shows the trend of work accomplished
114
Parking lot charts
Summarize the top-level project status
115
Three viewpoints of Kanban boards
1) Time - Releases to iterations to Days2) Task - Features to stories to tasks3) Team - Manager, customers, developers, business analysts, users, testers and other stakeholders
116
Kanban board task
1) A feature is a function useful and meaningful to users2) A story is a testable piece of a Feature (described in words of users)3) Task is work unit of story (described in terms used by developers)
117
Why use time boxing
1) Avoid missing windows of opportunity2) Chunk up a problem3) Deliver incremental results4) Defeat analysis paralysis - switch gears from think mode to execution
118
Using Timeboxes effectively
1) Identify candidate areas for time boxing2) Identify your objectives3) Identify the appropriate time box4) Execute results with your time box5) Evaluate and adapt
119
Identify your timebox objectives
1) Meet a deadline2) Show incremental results.3) Make incremental progress on a tough problem.4) Build momentum.
120
Execute results within your time box
1) Execute within your timebox and stop when you run out of time2) how to stay completely focused3) how to treat time as a limited resource, 4) how to tune your results.
121
Iteration planning
1) selects and reviews the stories for the current iteration2) defines and estimates the tasks necessary to deliver the increment of work3) tasks are typically estimated in “ideal developer days” or even hours4) details of the requirements are discussed and negotiated
122
Iteration Planning Guidelines
1) first day of the iteration, first thing in the morning. no more than 4 hours.2) Create task estimates for each story on the basis of ideal effort hours, or points3) at least one story with a demonstrable function included in the iteration4) if a story breaks out into seven or more tasks, consider splitting the story.5) Once the iteration is underway, no change requests by the product manager are allowed
123
Agile Release Planning
1) Small releases are better2) They provide a constant flow of shippable product increments and generate regular feedback from the end-users3) The logistics and overheads of releasing need to be minimized
124
Purpose of Agile Release Planning
A goal for the release.A prioritized set of stories that will be developed in the release.A coarse estimate for each story.A date for the release.
125
Preparing for the Release Planning Meeting
1) Define a goal for the release2) Produce a prioritized wishlist of stories for the release3) Time permitting, have some developers preview the wishlist to ensure they understand the gist of the stories4) Review the wishlist
126
Purpose of the Release Planning Meeting
1) everyone in the team understand and commit to delivering the agreed release by the agreed date.2) The product owner explains the release goal to the team3) The developers provide their team’s velocity4) In the order of value, the product owner introduces each story to the developers.5) The developers ask enough questions6) The developers assess the technical risk for each story and provide some classification, e.g. high, medium or low.7) the product owner selects the stories from the wishlist to make up the release plan.8) Consensus
127
Daily standups
1) What was accomplished yesterday2) What is planned to accomplish today3) What issues are blocking progress
128
Goals of daily standups
```GIFTS (Good start, Improvement, Focus, Team, Status)To help start the day wellTo support improvementTo reinforce focus on the right thingsTo reinforce the sense of teamTo communicate what is going on```
129
Burn up charts
1) A burn-up chart tracks how much work is done.| 2) Line showing how much work is in the project as whole (the scope as workload), and this can change
130
Overview of Cumulative Flow Diagrams
1) Whether or not value is being delivered as the result2) Are stories reaching the final status?3) Where the bottlenecks are in our workflow4) How long it takes something of value to be produced5) Whether the scope of a project is changing
131
Burndown chart vs Cumulative flow diagram
1) Outstanding work at a particular time vs how we are doing in terms of delivering value2) The cumulative flow graph is not bound by sprint boundaries
132
Kanban cumulative flow diagram items
1) Backlog2) Priority 33) Priority 24) Priority 15) Working6) The Pen7) Complete8) Archive
133
Downsides of Cumulative Flow Graph
1) The CFG is information dense, so it is harder for a beginner to understand and interpret.2) CFGs are a lot harder to maintain by hand
134
Intraspective
1) similar to retrospective2) Discussion of issues3) determine needed process changes4) Intra -> with in (during the sprint)
135
agile discovery
1) find what customer want2) Listening - build an understanding by listening to customer3) interacting up front4) gaining clarity
136
discovery team
1) PO put together a team2) progressive elaboration => user story3) Continuous customer engagement4) requirements handed off to delivery team5) discovery continues
137
agile req review
1) backlog grooming| 2) no formal requirements signoff
138
Agile tools
1) learn and grow2) collaboration games3) 5 whys4) intraspective meeting
139
Collaboration
1) leader is not necessary2) members are responsible and accountable3) trust and respect
140
Collaboration games
1) having fun and learning2) build rapport and accountability3) structured activities4) improved understanding ownership and relationships5) eg. the broken telephone, human knot, one word story telling
141
Intraspective explained
1) Scrum master (PO not involved)2) Held as necessary3) discuss issue and to identify solution
142
Kaizen
1) constant improvement of all company functions2) change happens one time or is constant, big or small, as long as it is a change for the better3) making little changes, monitoring the results and then readjusting
143
the Five WHYs
1) “Why?” five times| 2) it would point us towards a root cause and a solution
144
retrospectives, intraspectives
1) What worked well for us?2) What did not work well for us?3) What actions can we take to improve our process going forward?
145
process tailoring
1) Process tailoring is about roles and procedures2) Identifying which individuals perform which roles3) Identifying which individuals do which approvals4) Where each work product is stored.5) Creating project plans with work items that reflect the process.
146
value stream mapping
1) Value stream maps can be used to map the flow of work from the start of the delivery process (ex: client request) to the end of the delivery process (ex: system delivered to the client). 2) They are similar to process diagrams, but meant to be much less detailed, but getting things into process areas
147
control limits
1) Three-sigma (σ) limits are generally used for control limits2) probability the false-alarm risk, the α-risk, or the probability of a type 1 error (process really is in control)3) control charts by hand were set up for 25 subgroups
148
pre-mortem
With a pre-mortem you try to think about everything that might go wrong before it goes wrong
149
fishbone diagram analysis
1) Agree on a problem statement2) main causes and sub causes leading to an effect (symptom)3) focus attention to places on the chart where ideas are few
150
hybrid models
Implementing Agile-Waterfall Hybrid allows software teams to work “agile”, while hardware development teams and product managers can use traditional PMP/waterfall approach
151
Project specific process tailoring
1) Adding/removing work products and tasksChanging milestones, and what work products will be made available at each milestone, and their state of completionTool and/or format used for each work product2) Responsibilities for review and approval3) Detailed procedures for reporting progress, performing measurements, managing requirements, managing change requests, etc.
152
Process instantiation
1) process instantiation is about specific individuals and specific work products2) Sometimes projects will combine process tailoring and process instantiation3) you can create a RACI table that includes both individuals and roles, and create a table that says not only which work products will be produced, but also where the specific instances will be stored
153
waterfall-agile hybrid
1) dependency tracking and clarity of Waterfall| 2) flexibility and transparency necessary to adapt to the fast changing requirements of stakeholders
154
why pre mortem
1) surveys the group and compiles a consolidated list of why the project failed.2) ask everyone in the room to think up one thing that they could do to help the project. 3) Ideally the team is more attuned to what could go wrong and willing to engage in risk management.
155
focus of value stream mapping
The focus of value stream mapping is on discovering the positive values provided by the activities of the organization, enhancing those values and removing any performance robbing waste.
156
focus of process mapping
1) The focus of process mapping is on discovering the current processes of an organization, establishing the root cause problems with those processes, and looking for solutions. 2) While improvements can be made using this approach, it is difficult to align the problem/solution pairs so that each cycle of problem/solution implementation builds towards a strategic objective.
157
agile verification
1) change control mechanisms2) tracking and traceability matrices 3) regression test automation.
158
done thinking grid column 1
1) User Story Clarity2) Task identified3) Build setup changes4) Product owner approval5) Product backlog updated
159
continuous integration
1) team integrate their work frequently2) verified by an automated build3) allows a team to develop cohesive software more rapidly
160
testing, including exploratory and usability
testing, including exploratory and usability
161
agile validation
1) before any software is released for use by the end user – be it alpha, beta or production code – the results of all this work will have to be validated.2) “Validation shall be performed under defined operating conditions
162
Steps in agile validation
1) Finalize traceability from PRD to SRS2) Run all unit testing and story level acceptance testing regression tests3) Finalize and execute PRD (system) level feature acceptance tests4) Run all system qualities tests for nonfunctional requirements (reliability, accuracy, security)5) Run any exploratory, usability, and user acceptance tests6) Finalize and update traceability matrices to reflect current state7) Finalize/update risk analysis/hazard mitigation8) Conduct a design review
163
done thinking grid column 2
1) Environment Ready2) Design Complete3) Unit test cases written4) Documentation5) Pre-Release builds
164
done thinking grid column 3
1) Code complete2) Unit tests executed3) Refactoring4) Code Checkin5) Code merging & tagging
165
done thinking grid column 4
1) Automated code review2) peer review3) Code Coverage4) Burndown chart ready5) release build
166
done thinking grid column 5
1) Functional testing2) Regressing testing3) Performance testing4) Acceptance testing5) Closure
167
Practices of Continuous Integration
1) Maintain a single source repository2) Automate the build3) Make your build self-testing4) Everyone Commits To the Mainline Every Day5) Every Commit Should Build the Mainline on an Integration Machine6) Keep the Build Fast7) Test in a Clone of the Production Environment8) Make it Easy for Anyone to Get the Latest Executable9) Everyone can see what's happening10) Automate Deployment
168
risk adjusted backlog
1) focuses on where investment needs to be undertaken, based on risk2) decreasing list of priorities from the risk calculation3) Potential Consequence x Likelihood4) rectify all high and significant risks
169
risk burn down graphs
1) Risk Burndown graphs are very useful for seeing if the total project risk is increasing or decreasing over time.2) Whether individual risks are increasing in severity over time and whether new risks are being introduced.
170
risk-based spike
Spikes are a really good way for teams to figure out stuff that they don't know and need to know in order to understand the complexity so that it can be properly estimated, or quoted on or simply to find out if something is technically possible or not.
171
architectural spike
architectural spike
172
Why use spike
1) basic research to familiarize the team with a new technology of domain2) story may be too big to be estimated appropriately and the team may use a spike to analyze the implied behavior so they can split the story into estimable pieces.3) story may contain significant technical risk and the team may have to do some research or protoryping to gain confidence4) The story may contain significant functional risk, not clear how the system needs to interact with the user to achieve the benefit implied.
173
Alternatives to Agile Spikes
1) increases the scope of possible error2) For stories that you can't estimate accurately, an alternative to scheduling a spike story is to provide a high estimate
174
ROI/NPV/IRR
ROI/NPV/IRR
175
five major focus of Agile Compliance
1) Information Security Governance policy2) Discover the optimal level of security and compliance without compromising business agility3) Manage human and organizational factors that impede agility and compliance4) (SOA) on compliance5) Find the correct path to secure, agile compliance in your organization
176
customer valued prioritization
customer valued prioritization
177
requirements reviews
requirements reviews
178
minimal viable product (MVP)
minimal viable product (MVP)
179
minimal marketable feature (MMF)
minimal marketable feature (MMF)
180
relative prioritization/ranking
relative prioritization/ranking
181
MoSCoW
MUSTShouldCouldWould like (least priority)
182
Kano analysis
1) Is the feature mandatory?2) This feature is excitement. It is possible differentiator3) improved a performance of the application. This is valuable.4) this feature is indifferent5) This feature is really questionable6) This feature reverse me to really find a different product
183
SOA in agile
1) Using SOA as the basic architectural approach helps isolate changes and standardize interfaces. 2) This makes agility more practical as it helps with swapping out pieces, 3) changing the behavior of one service is easier to control and so on
184
Agile values
1. 1 Individuals and interactions over processes and tools.1. 2 Working software over comprehensive documentation.1. 3 Customer collaboration over contract negotiation.1. 4 Responding to change over following a plan.
185
Agile frameworks and terminology
Agile frameworks and terminology
186
Agile methods and approaches
Agile methods and approaches
187
Assessing and incorporating community and stakeholder values
Assessing and incorporating community and stakeholder values
188
Stakeholder management
Stakeholder management
189
Communication management
Communication management
190
Facilitation methods
Facilitation methods
191
Knowledge sharing/written communication
Knowledge sharing/written communication
192
Leadership
Leadership
193
Building agile teams
Building agile teams
194
Team motivation
Team motivation
195
Physical and virtual co-location
Physical and virtual co-location
196
Global, cultural, and team diversity
Global, cultural, and team diversity
197
Training, coaching, and mentoring
Training, coaching, and mentoring
198
Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha Ri)
Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha Ri)
199
Self-assessment tools and techniques
Self-assessment tools and techniques
200
Participatory decision models (for example, convergent, shared collaboration)
Participatory decision models (for example, convergent, shared collaboration)
201
Principles of systems thinking (for example, complex adaptive, chaos)
Principles of systems thinking (for example, complex adaptive, chaos)
202
Problem solving
Problem solving
203
Prioritization
Prioritization
204
Incremental delivery
Incremental delivery
205
Agile discovery
Agile discovery
206
Agile sizing and estimation
Agile sizing and estimation
207
Value based analysis and decomposition
Value based analysis and decomposition
208
Process analysis
Process analysis
209
Continuous improvement
Continuous improvement
210
Agile hybrid models
Agile hybrid models
211
Managing with agile KPIs
Managing with agile KPIs
212
Agile project chartering
team understand the parameters of its work and its context within the project, preparing them to make well-informed decisions going forward
213
Regulatory compliance
Regulatory compliance
214
12 principles
1) satisfy customers2) welcome changing reqs3) frequent delivery4) collaboration business people and developers5) motivated individuals6) face-to-face communications7) working software is measure of progress8) sustainable development9) continuous improvement10) emergent11) simplicity12) regular retrospection
215
Components of an Agile Charter
1) Vision2) Mission3) Success criteria
216
Tuckman's model
Forming – Storming – Norming – Performing
217
Dreyfus Model
1) Novice - adhere to rule and plan2) Experienced Beginner -develop situational perception 3) Practitioner - actively make decisions and solve problems4) Knowledgeable - formulate plans based on past learning5) Expert - own intuition and understanding
218
Shu Ha Ri Model
1) used to describe the progression of training or learning2) shu, we repeat the forms and discipline ourselves 3) ha - we make innovations4) ri- open door to creative technique,we act in accordance with what our heart/mind desires, unhindered while not overstepping laws
219
Five concepts
1) Self Organization2) Right skill set and perspective, personal strength (Team building)3) Motivated team4) Empowered teams5) High performing teams
220
Self organization team
1) Organizing, managing and directing| 2) authority and resources to plan work and resolve roadblocks
221
Self organization team characteristics
1) Adopt and commit to a common purpose2) How to resolve problems3) Organize and direct themselves4) Increase collaboration and communication to help ensure success
222
Team building best practices
1) Move beyond roles to integrated team2) Trust and accountability3) Right skill set and perspective
223
Tuckman's development model
Forming - first impression of othersStorming - Compete for acceptance of their conceptsNorming - work naturally as a teamPerforming - work consistently Adjourning - project concludes and team members transition
224
Whitworth and biddle study (motivation)
1) Continuous and open communication2) Accept to the most current information3) Clear team goal4) Unrestricted ease of interaction5) Engaging in Innovation games6) Iterative delivery helps sense of immediacy for the team
225
Maslow's hierarchy of needs
1) Physiological (survival)2) Security 3) Social4) Self Esteem5) Self actualization (fulfillment and achievement)
226
Maslow's for agile teams
1) Team space and tools (Physiological )2) Safe and secure team work environment3) Daily stand-ups and other team events4) Respect, inclusion and mutual appreciation5) Team success over individual success
227
Herzberg's motivation theory
Motivation hygiene theory (factors)1) Must enjoy their work(align with skill set and capabilities)2) Sense of achievement3) Recognition4) Responsibility5) Personal growth and advancement
228
Herzberg and Agile
```Hire people with diverse skillsCreate collocated team Recognize members (team member of the week)Work as collective unitCross functional training opportunity```
229
McClelland theory of needs
Theory of needs1) Achievement2) Affiliation (liked and accepted by others)3) Power (prefer to direct other)4) Avoidance (fear rejection failure and success)
230
Theory of needs and agile
Achievement - more challenging work to high achieversAffiliation - personal interactionPower causes disruption don't useAvoidance - team disruptions so don't use
231
McGregor's Motivation (X and Y) theory
X- close supervision, inherently lazy, disciplinary actions| Y - Self motivated, self control, seek and accept responsibility (use in Agile)
232
Empowered teams defined
Owns the project| Authority to make decisions on their own
233
Agile development survey
1) Most companies follow a traditional command and control project culture2) Agile teams are self-directing and self-organizing
234
High performing teams
1) High quality results2) Build the right team culture3) Culture - Organization, and team adapt to agile culture4) Right people5) Mutual trust
235
ARCS J.M. Keller
1) Attention 2) Relevance3) Confidence/Competence4) Satisfaction
236
Three step intervention for CR
1) Have you shared your concerns and feelings about this with 2) should know of your concerns. Would it help if I go with you?"3) May I tell that you have these concerns
237
Task 1
1) Advocate2) Discuss and develop shared mindset 3) Across Team as well as between customer and team
238
Task 2
1) Common understanding2) Common knowledge3) For effective work
239
Task 3
1) support change2) Educating and influencing3) Make organization more effective and efficient
240
Task 4
1) Practice visualization2) Information radiators real progress and performance3) Enhance transparency and trust
241
Task 5
1) Safe and trust environment2) Experiment, make mistakes3) Learn and continuously improve
242
Task 6
1) Enhance creativity2) New process ideas3) discover effective and efficient way of working
243
Task 7
1) Reduce knowledge silos2) Share and collaborate3) Reduce bottlenecks
244
Task 8
1) Foster self organization2) Emergent leadership3) Safe and respectful environment
245
Task 9
1) Practice servant leadership2) Encourage others to perform at their highest level 3) Continue to improve
246
Task 1
1) Maximize value2) Minimize non value added work3) Units that can be produced incrementally
247
Task 2
1) Gain consensus on requirements2) Just in time basis on acceptance criteria3) To deliver value
248
Task 3
Process based on team experience, organization characteristics and based on project
249
Task 4
1) Small releasable increments2) group requirements into min marketable feature / min viable product3) early recognition and delivery of value
250
Task 5
1) Limit increment size2) Increase Review frequency3) To identify risk early on 4) At minimal cost
251
Task 6
1) Solicit and request feedback| 2) In order confirm and enhance business value
252
Task 7
1) Prioritize unit of work in collaboration with stakeholder
253
Task 8
1) Maintenance of internal quality by2) Frequent reviews and prioritizing3) To reduce overall cost of development
254
Task 9
1) Continuously identify environmental, operational and infrastructure factors2) To improve quality and value of the deliverables
255
Task 10
1) Periodic operational review / checkpoints with stakeholders2) To obtain and feedback and corrections to work in progress and planned work
256
Task 11
1) Balance development and risk| 2) by including development and risk reducing items in backlog
257
Task 12
1) Re prioritize periodically to reflect change| 2) To maximize value
258
Task 13
1) Elicit and prioritize relevant non functional requirements
259
Task 14
1) Conduct frequent reviews and incorporate improvements in overall process, product and service
260
Task 1
1) Engage empowered stakeholders with periodic review| 2) Ensure team is knowledgeable about interest, needs and expectations
261
Task 2
1) Promote knowledge sharing early and through out| 2) Ensure unimpeded flow of information
262
Task 3
1) Working agreement between key stakeholders| 2) Promote participation and collaboration
263
Task 4
1) Appropriately engage new stakeholders
264
Task 5
1) Fostering group decision making2) group conflict resolution3) To improve decision making and reduce the time taken for decision making
265
Task 6
1) Establish a shared vision2) developing a high level vision and supporting objectives 3) align stakeholders’expectations and build trust.
266
Task 7
1) Shared understanding of success criteria,deliverables2) Acceptable trade-offs by facilitating awarenessamong stakeholders
267
Task 8
1) Transparency regarding work status| 2) Help primary stakeholders make informed decisions.
268
Task 9
1) Provide forecasts at a level of detail that balances the need for certainty and the benefits of adaptability in order to allow stakeholders to plan effectively.
269
Task 1
1) Cooperate with the other team members 2) Devise ground rules and internal processes3) Foster team coherence and strengthen commitment to shared outcomes.
270
Task 2
1) Help create a team with interpersonal and technical skills2) To achieve objectives to create business value with minimal delay.
271
Task 3
1) Encourage team members to become generalizing specialists2) To reduce team size and bottlenecks3) To create a high performing cross-functional team
272
Task 4
1) Contribute to self-organizing 2) Empowering others3) Encourage emerging leadership
273
Task 5
1) Continuously discover team and personal motivators and demotivators2) To keep team morale is high 3) Team members are motivated and productive throughout the project.
274
Task 6
1) Facilitate close communication within the team and with appropriate external stakeholders through co-location2) Use of collaboration tools in order to reduce miscommunication and rework.
275
Task 7
1) Reduce distractions in order to establish a predictable outcome 2) To optimize the value delivered.
276
Task 8
1) Participate in aligning project and team goals 2) by sharing project vision in order to 3) ensure the team understands how their objectivesfit into the overall goals of the project
277
Task 9
1) Measure its velocity by tracking andmeasuring actual performance in previous iterations 2) To better understanding of their capacity and create more accurate forecasts.
278
Task 1
1) Plan at multiple levels (strategic, release, iteration, daily) 2) creating appropriate detail by using rolling wave planning and progressiveelaboration3) balance predictability of outcomes with ability toexploit opportunities.
279
Task 2
1) Make planning activities visible and transparent 2) encourage participation of key stakeholders3) Publish planning results in order to increase commitment level and reduce uncertainty.
280
Task 3
1) As the project unfolds, set and manage stakeholder expectations by making increasingly specific levels of commitments2) in order to ensure common understanding of the expected deliverables
281
Task 4
1) Adapt the cadence and the planning process based on results of periodic retrospectives about characteristics and/or the size/complexity/criticality of the project deliverables in order to maximize the value.
282
Task 5
1) Inspect and adapt the project plan to reflect changes in 2) requirements, schedule, budget, priorities, delivery experience, stakeholder feedback, and defects
283
Task 6
1) Size items by using progressive elaboration techniques in order to determine likely project size 2) independent of team velocity and external variables.
284
Task 7
1) Adjust capacity by incorporating maintenance and operations demands and other factors in order to create or update the range estimate.
285
Task 8
1) Create initial scope, schedule, and cost range estimates that reflect current high level understanding of the effort necessary to deliver the project in order to develop a starting point for managing the project.
286
Task 9
1) Refine scope, schedule, and cost range estimates that reflect the latest understanding of the effort necessary to deliver the project in order to manage the project.
287
Task 10
1) Continuously use data from changes in resource capacity, project size, and velocity metrics in order to evaluate the estimate to complete.
288
Task 1
1) Create an open and safe environment by encouraging conversation and experimentation,2) In order to surface problems and impedimentsthat are slowing the team down or preventing its ability to deliver value.
289
Task 2
1) Identify threats and issues by educating and engaging the team at various points in the project in order to resolve them at the appropriate time and improve processes that caused issues.
290
Task 3
1) Ensure issues are resolved by appropriate team members and/or2) reset expectations in light of issues that cannot be resolved in order to maximize the value delivered.
291
Task 4
1) Maintain a visible, monitored, and prioritized list of threats and issues in order to elevate accountability, encourage action, and track ownership and resolution status.
292
Task 5
Communicate status of threats and issues by maintaining threat list and incorporating activities into backlog of work in order to provide transparency.
293
Task 1
1) Tailor and adapt the project process by periodically reviewing and integrating team practices, organizational culture, and delivery goals in order to ensure team effectiveness within established organizational guidelines and norms.
294
Task 2
Improve team processes by conducting frequent retrospectives and improvement experiments in order to continually enhance the effectiveness of the team, project, and organization.
295
Task 3
Seek feedback on the product by incremental delivery and frequent demonstrations in order to improve the value of the product.
296
Task 4
Create an environment of continued learning by providing opportunities for people to develop their skills in order to develop a more productive team of generalizing specialists.
297
Task 5
Challenge existing process elements by performing a value stream analysis and removing waste in order to increase individual efficiency and team effectiveness.
298
Task 6
Create systemic improvements by disseminating knowledge and practices across projects and organizational boundaries in order to avoid re-occurrence of identified problems and improve the effectiveness of the organization as a whole.
299
The structure of Atern
1) Process2) People3) Products4) Practices5) Principles6) Philosophy
300
Atern approach
1) Variable - Features| 2) Fixed - Quality, Time and Cost
301
DSDM Atern delivers because
1) Remain focused on business outcome2) Delivery on time3) Collaboration4) Prioritized according to business need5) Accommodate changes in agreed timescale6) Does not compromise on quality
302
Atern agility
1) Avoids big design up front| 2) Just enough design upfront
303
Atern flexibility
1) Can be used to complement other project management disciplines
304
Appropriate level of rigour
1) determine the correct level of rigour2) Too much formality can slow progress down and even cause paralysis3) Atern should be tailored to suit a project’s individual needs4) A risk assessment is undertaken early on in the project lifecycle in order to determine the level of rigour that must continually be applied throughout
305
Atern principles
1) Focus on the business need2) Deliver on time3) Collaborate4) Never compromise quality5) Build incrementally from firm foundations6) Develop iteratively7) Communicate continuously and clearly8) Demonstrate control
306
Demonstrate control
1) Use an appropriate level of formality for tracking and reporting2) Make plans and progress visible to all3) Measure progress through focus on delivery of products rather than completed activities4) Manage proactively5) Evaluate continuing project viability based on the business objectives
307
Factors instrumental to the success of Atern projects
1) Acceptance of the Atern philosophy before starting work2) Appropriate empowerment of the Solution Development Team.3) Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement4) Incremental delivery5) Access by the Solution Development Team to business roles6) Solution Development Team stability7) Solution Development Team skills8) Solution Development Team size9) A supportive commercial relationship
308
The Project Approach Questionnaire
1) that helps to identify and confirm the level of achievement of all the above factors and to assess potential risk areas to be addressed2) he questionnaire is completed during Feasibility and re-assessed as part of Foundations
309
Atern life cycle
1) Pre-Project2) Feasibility3) Foundations4) Exploration5) Engineering6) Deployment7) Post-project
310
Atern Pre-Project Objectives
1) To describe the business problem to be addressed.2) To identify a Business Sponsor and Business Visionary.3) To confirm that the project is in line with business strategy.4) To scope, plan and resource the Feasibility phase.
311
Atern Feasibility Objectives
1) To establish whether there is a feasible solution2) To identify the benefits likely to arise from the delivery3) To outline possible approaches for delivery4) To describe the organisation and governance aspects5) To state first-cut estimates of timescale and costs for the project overall6) To plan and resource the Foundations phase.
312
Atern Foundation Objectives
1) high-level requirements2) business processes to be supported3) strategies for all aspects of solution deployment4) how quality will be assured.5) assess and manage risk associated with the project
313
Atern Exploration Objectives
1) elaborate on the requirements captured2) explore the full detail of the business need and provide detailed requirements3) create a functional solution that demonstrably meets the needs of the business.4) early view of the solution that they will eventually operate, support and maintain5) models that describe how the solution works
314
Atern Engineering Objectives
1) To refine the Evolving Solution from the Exploration phase to meet the agreed acceptance criteria.2) To expand and refine any products required to successfully operate and support the solution in live operation.
315
Atern Deployment Objectives
1) To confirm the ongoing performance and viability of the project and re-plan as required.2) To deploy the solution 3) train the end users of the solution4) To train and/or provide documentation for operations and support staff5) To assess whether the deployed solution is likely to enable the delivery of intended elements of business benefit described in the Business Case (where created).
316
Atern Post-Project Objectives
To assess whether the benefits described in the Business Case (where created) have actually been achieved through use of the Deployed Solution.
317
Atern Roles and Responsibilities - Project
1) Business sponsor2) Business Visionary3) Technical Coordinator4) Project Manager5) Team Leader
318
Atern Roles and Responsibilities - Solution development
1) Team Leader2) Business Advisiors3) Business Ambassadors4) Business Analysts5) Solutions developers6) Solution Testers
319
Atern Roles and Responsibilities - Others
1) Atern Coach2) Workshop facilitator3) Specialist roles - as required
320
Iterations within a Development Timebox
1) Kickoff2) Investigation3) Refinement4) Consolidation5) Closeout
321
Iterative development process includes
1) Timeboxing2) Change Control (in association with MoSCoW prioritisation)3) Configuration Management4) Quality Assurance of products (including Testing of software products)
322
Evolutionary Development Strategy
1) Vertical2) Horizontal3) combined
323
Vertical approach
1) Advantage- small and simple availabe very early| 2) It may be difficult to see the context of the requirement
324
Horizontal approach
This approach delivers the solution layer by layer. The layers could be functional or architectural.Advantage - Early on in the project, the end-to-end solution can be demonstrated, which gives a clear view of the full extent of the development. Disadvantage - a bit of everything is available, but nothing is completed (or usable) until the final timebox.
325
A Combined Approach
This approach starts by delivering a (thin) end-to-end slice of the solution (Horizontal) and then reverts to a vertical approach to deliver complete working requirements which fit into the high-level solution framework.
326
A Combined Approach advantage
A Combined approach is useful to confirm the end-to-end scope or the screen flows or user navigation, before getting into the detail of the individual requirements. The Combined Approach, together with the Vertical Approach, is probably the most commonly used approach in Atern projects.
327
Kick-off
Short session for the Solution Development Team to understand timebox objectives and accept them as realistic
328
Investigation
The initial investigation of the detail of all the products to be delivered by the timebox including agreement on the timebox deliverables and quantitative measures that will prove success
329
Refinement
The bulk of the development and testing of the timebox products in line with agreed priorities
330
Consolidation
Tying up of any loose ends related to development and ensuring all products meet their acceptance criteria
331
Close-out
Formal acceptance of the timebox deliverables by the Business Visionary and Technical Co-ordinator
332
BARMAI index
Presenting estimate as a range| relates the estimate range to the likelihood
333
Bespoke model
1) Advantages are that the models are generally fairly simple and easy to understand and that they can be adapted to meet changing project needs. 2) Disadvantages are that they are reliant on good quality, relevant history from similar previous projects and that they have limited functionality. 3) Such models may be used within the team approach described above and indeed may be created by the team.
334
Quality Management – Getting the Balance Right
Quality and quality-related activities are sometimes perceived as adding bureaucracy and overheads. This must be avoided, particularly on a project adopting an agile approach, where it is crucial that all activities add benefit to the end results.
335
The Control Parameters
1) Risk2) Business benefit3) Quality4) Resource5) Time6) Cost7) Features
336
7 key principles of lean software development
1) Eliminate Waste 2. Build Quality In 3. Create Knowledge 4. Defer Commitment 5. Deliver Fast 6. Respect People 7. Optimise The Whole
337
Lean over other
k
338
22 lean tools
1
339
See the whole
1) All the working parts2) Everything integrating3) Focus on overall system performance4) Important in contracting, not individual needs drive the focus
340
Eliminate waste
1) anything does not add value2) Anything not needed immediately3) Handing development one group to another
341
Amplify learning
1) Communicate early and often2) Decision based on empirical finding not on assumptions3) Repeat throughout the process4) Continually improve5) Expect and embrace mistake
342
Decisions as late possible
1) Avoid locking in decision (design should be flexible)| 2) Build a capacity for change in the system
343
Deliver as soon as possible
1) Quick feedback| 2) Discovery cycle is critical (shorter the cycle, more can be learned)
344
Empowering the team
1) Developers can let others know when works needs to be done2) Not possible for central authority to direct3) Pull mechanism, self organizing, do whatever it takes to resolve the challenges
345
Build integrity into the system
1) Whatever delivered is what wanted2) System maintain usefulness3) Adaptable
346
Tools to eliminate waste -Seeing waste
1) partially done work2) Extra processes - someone waiting for the output from the process3) No extra features4) Task switching5) Waiting (not able to realize value)6) Motion (co location), not only people7) Defects (find as soon as it occurs, so test immediately)
347
Tools to eliminate waste -Value stream mapping
1) Flow of work (all process steps) -shows waiting and unnecessary steps
348
Principle 2-Amplifying
1) Feedback2) Immediate customer not a future customer3) Increase frequency loop in problem area4) Iteration5) Synchronization (feature based development)6) Set based development(develop multi options, communicate constraints, letting solutions emerge)
349
Principle - 3, Decide as late
1) Options thinking2) last possible moment3) Making decisions (breadth first, depth first)
350
Option thinking
1) Maximize reward until more information available2) Flexibility to respond to change3) Fact based decision
351
last possible moment
1) Concurrent development
352
Making decisions
1) breadth first - how details most likely emerge, late commitment, business expected to evolve2) depth first - early commitment, focus on particular area
353
Principle 4 - Deliver as fast as possible
1) pull system2) Queuing theory tool3) Cost of delay
354
Pull system development
1) Kanban is most often used tool2) display task progress3) increased team motivation and cross functionality
355
Queuing theory tool
1) remove project bottlenecks2) minimizes task wait time inside a process3) goal is minimize Cycle time
356
Cost of delay
1) Minimize cost of delay2) Understand relationship between cost and time3) Only delay as long as profit is not affected
357
Principle 5 - Empower the team
1) Self Determination2) Motivation3) Leadership4) Expertise
358
Self determination tool
1) Developers chose how and when to do work2) Team leaders enforces standards, coordinate work3) Overall team is responsible
359
Motivation
1) Encourage, recognize and reward creativity and initiative| 2) Building blocks: belonging, safety, competence, progress
360
Leadership
1) Coach and facilitator2) how to use tools and to work as whole3) Facilitate activities so team can focus
361
Expertise
1) Each member as different level of expertise2) Encourage to learn for cross functionality3) Share expertise by knowledge transfer
362
Principle 6 Build integrity in
1) Perceived integrity2) Conceptual integrity3) Refactoring4) Testing
363
Perceived integrity
1) perceived by user of the system2) affected by deliver, access, intuitiveness, cost3) cost
364
Conceptual integrity
1) Central concept work together as unit2) prerequiste for perceived integrity3) emerges as system matures and evolves4) helps to illustrate system purpose
365
Refactoring
1) For continuous improvement2) refactor and realign for conceptual integrity3) key method for avoiding waste
366
Principle 7 see the whole tools
1) Measurements| 2) Contracts
367
Measurements
1) Information measurement (not performance measurement)2) Don't attribute defects to the developer3) collaborate as team to identify defects (information measurement)
368
Contracts
1) Time and material2) Multistage (master contract, work orders)3) Target cost (solution to meet target cost, limit cost)4) Shared benefit contract (mutual benefits)
369
In times of trouble
1) find and fix its root cause2) identify biggest concern and focus on removing it3) move up one level and improve
370
lean vs scrum
1) ability using specific set of engineering2) cost is important3) when driven at process level
371
Crystal Objectives
1) Human powered2) Focuses on team not on processes3) directly tackle cooperative game of team invention and communcation4) Aspires to be sufficient methodology5) This game never repeats
372
Crystal attributes
1) Size and criticality| 2) lighter color and hardness
373
Crystal family characterisation
Vertical axis - life(l), essential money(e), discretionary money(d), comfort(c)Horizontal axis - team size
374
Crystal family characterisation
Methods are not compatible with each other| If size or criticality changes, change the crystal method
375
Crystal family genetic code
1) Design priorities2) Project properties (what team is aiming for)3) Design principles4) Key techniques (specific tools)5) Crystal methods
376
Design priorities
1) What to work on, what specific order2) Project safety (project outcome) 3) Development efficiency4) Habitability (comfortable to use, so that teams do not feel need to avoid it)
377
Project properties
1) Frequent delivery2) Reflective improvement3) Osmotic communication4) Personnel safety (project team and end user)5) Focus (priority items for team members)6) Access to expert users and other users7) Proper technical environment
378
Design principles
1) Face to Face communication2) gauge method weight3) Add weight4) Add ceremony5) Feedback 6) Discipline and skill7) trade efficiency
379
Key techniques
1) Methodology shaping workshop| 2) reflection workshop
380
Popular methods
1) Crystal clear (low criticality, small size)2) Orange3) orange web
381
Project safety
1) If all implemented, project safely reach end goal2) delivered in reasonable period of time3) 7 project properties (3 base properties, 4 not mandatory)4) Project safety increases incrementally
382
Habitability
1) Creating convention, team can live with2) Comfortable to use3) team did not feel need to circumvent or avoid4) includes tolerance for human variation5) Maximum amount of freedom for team members
383
Development efficiency
1) eliminate waste2) team members work continuously on the same project (static team)3) short iteration (able to focus)4) familiarity with requirements
384
Gauge methodology weight
1) Adds cost to the project, constantly monitored 2) less is better3) Darker methods need more weight, frequent communication4) criticality increases documentation and reporting
385
Trade efficiency
1) Non-bottle necks can be less efficient, so bottlenecks can become more efficient
386
Methodology shaping workshops
1) review organization fixed rules2) review liked and kept items3) review disliked and avoid items4) Plan to take advantage of organizational themes5) brainstorm solutions for difficult items6) review and prioritize the items7) review and update at reflection workshop
387
Reflection workshop
1) what should we keep2) where are we in ongoing problems3) what do we try in the next iteration
388
Crystal clear method characteristics
1) Team size 1-62) Colocated3) Project duration release 30 to 904) Tracking technique - Milestones5) Process reviews - discretionary and informal6) Coding standards - discretionary and informal
389
Crystal clear method roles and responsibilities
1) Sponsor2) Senior designer3) designer and programmer4) Business representative5) Coordinator6) requirement gatherer
390
Crystal clear method products
1) Map (project, process, iteration)2) plans3) reports4) lists5) information radiators6) formal documentation
391
Crystal orange characteristics
1) Team size 21-402) distributed (but in a same building)3) Project duration release 90 to 1204) Tracking technique - Milestones(higher level) & deliverables5) Process reviews - mandatory6) Coding standards - mandatory
392
Crystal orange method products
1) user interface designer2) database engineer3) Architect4) full time tester5) User 6) technical writer
393
why use crystal methods
1) there is no 1 to 1 comparison2) team as key elements 3) successfully combined with ASD and Scrum
394
Kanban overview
1) Scrum without timebox2) Value stream start from where are you currently at3) Kaizen (continuous improvement)4) No retrospection (retrospection happen at every time)5) No time boxes for team, but cycle time is used6) But time box for single item7) Work processed in small chunks8) Minimize rework and delay9) System throughput matters
395
Kanban visualization
1) Capacity of the team2) What team is working on, challenges faced with out micro managing3) Clear priorities with Kanban 4) What is the availability5) bottlenecks in value stream6) Dependencies becomes clear7) Cards can be features, task or user stories
396
limit WIP
1) reduce waste2) increase focus3) swarming vs some WIP
397
Kanban solution
1) on demand meetings only (only regular stand up)2) prevents prematurely designating work as complete3) clear quality bars at each step
398
simple work flow
1) Take an item from backlog2) Specify work necessary to implement it3) Implement it4) Validate that it works5) deliver
399
Set limits on chaos
1) by limiting work in progress (add WIP as last step in problem solving) 2) Scrum - time box
400
Run daily standups
1) any one can run| 2) no milestones, no sprints and no retrospectives
401
External bottleneck
Items are moved to the Track column whenever they are blocked awaiting external input. Tracked items don’t count toward the Implement WIP limit
402
parking lot
Occasionally, it becomes apparent that an item will be blocked indefinitely. We have a special area for those items in the corner of the signboard. We call it the “parking lot.” Every few weeks, we check on the status of parking lot items, but we don’t do this daily
403
Deadlines and WIP
Limiting WIP also constrains your team’s size (your costs) and reduces your cycle time (the time for a planned work item to go from specification through validation). Shortening cycle time benefits quality, agility, and customer engagement. It also allows you to accurately measure throughput, and thus accurately estimate completion dates.
404
Minimum viable product
your MVP is the set of work items (note cards) in your backlog that must be completed before release. That is, regardless of the monetary or market impact, you would delay or cancel your product release if those work items were incomplete.
405
Priority
Ordering these cards in your backlog is a team activity. Leadership, internal and external partners, and customers help you prioritize the cards into the big buckets, but day-to-day execution belongs to the team.
406
Calculate your task completion rate
count the number of tasks that are done with their final step within any two-week to four-week period, and divide by the number of days.
407
How soon will a work item be addressed and done
(active tasks + estimated task for the work item and work items ahead of it) / task completion rate
408
when will a significant product release be completed
(active tasks + estimated task for the MVP workitems) / task completion rate
409
complete the current task set
CTE / (TCR – TAR)1) CTE - Current task estimate2) TCR - Task completion rate3) TAR - Task add rate
410
RAD overview
1) Minimal planning in favor of prototype2) Iterative and prototyping3) compromising functionality and performance for faster development and maintenance4) used in fast moving and unpredictable environment5) AD is framework and ASD is a method
411
Four phases of RAD
1) Planning2) User design3) Construction4) cutover (final tasks)
412
Adaptive life cycle
1) Speculate2) Collaboration3) Learn4) Helps with shift from resource based to knowledge based products
413
ASD attributes
1) based on empirical data2) must meet unknown goals3) High anxiety
414
ASD characteristics overview
1) Feature based2) Iterative3) Time boxed4) Risk driven5) Mission focused6) change tolerant
415
Process 1 Speculate
1) Admit you don't know everything
416
Process 2 collaborate
1) Embrace unpredictability and welcome| 2) Most important revelations happen at edge of chaos
417
Process 3 Learn
1) Allow making small mistakes based on false assumptions and correcting them2) Learning is preferred over revising3) constantly testing knowledge over limits
418
Mission focused
1) boundaries rather than fixed destination2) mission broad in the beginning and narrows 3) mission artifacts gives direction and help make decisions4) good mission and constant mission refinement
419
Feature based
1) focus on group of features2) focus on results not on tasks3) direct value to customer4) documentation considered secondary
420
iterative
1) emphasis on redoing(new info and knowledge after each cycle)2) redoing is not rework3) difficulty in any process shows need for redoing4) improve processes (ensure mission supported)5) solicit customer feedback
421
Time boxed
1) To limit time spent| 2) To make task efficient
422
Risk driven
1) identify highest risk features and develop first few cycles2) To identify the risk early before spending considerable amount of time3) Processes to get more information about the risks and monitor the risks4) Identify potential and new risks
423
Change tolerant
1) Changes embraced for continuous improvement2) Create processes which adapts to changes3) independent features4) cross functionally trained team members
424
When to use ASD
1) Interned based software development (high speed, change, uncertainty)2) Continuous adaption and adaptive life cycle3) emergent
425
ASD
1) More than AD2) Specific characteristics3) Considered as method more than framework
426
XP overview
1) extreme and focus dev method2) some principles may be too rigid3) high quality shortly and efficiently
427
XP structure
1) Activities (listening, design, coding, testing)2) values (communication, simplicity, courage, feedback, respect)3) Practices (12)
428
Practices group
1) Feedback2) continuous processes3) Shared understanding
429
Feedback practices
1) whole team2) Pair programming3) testing4) planning game
430
continuous processes practices
1) Simple system2) Collective code ownership3) System metaphor4) Coding standards
431
Shared understanding practices
1) Small releases2) Continuous integration3) Refactoring4) Sustainable pace
432
XP roles
1) Customer2) Coach3) Programmer4) Tracker5) Tester
433
system metaphor
story about the system everybody can tell
434
xp tracker
traces the progress, provides feedback
435
planning game release
1) Exploration phase (requirements shortlist)2) commitment phase (commit to the functionality to be included in release)3) Steering phase (adjustment)
436
planning game iteration
1) Activities of programmer2) Exploration - decomposed to task3) Commitment- task assignment and estimation4) Steering - performance task and test
437
Pair programming
1) All code produced two programmers2) One programmer has control3) Other programmer reviews the code4) Roles and pair switch
438
CRC Card
Use Class, Responsibilities, and Collaboration (CRC) Cards to design the system as a team. The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technology
439
Planning
1) User stories are written.2) Release planning creates the release schedule.3) Make frequent small releases.4) The project is divided into iterations.5) Iteration planning starts each iteration.
440
Managing
1) Give the team a dedicated open work space.2) Set a sustainable pace.3) A stand up meeting starts each day.4) The Project Velocity is measured.5) Move people around.6) Fix XP when it breaks.
441
Designing
1) Simplicity.2) Choose a system metaphor.3) CRC cards for design sessions.4) Create spike solutions to reduce risk.5) No functionality is added early.6) Refactor whenever and wherever possible.
442
coding
1) The customer is always available.2) Code must be written to agreed standards.3) Code the unit test first.4) All production code is pair programmed.5) Only one pair integrates code at a time.6) Integrate often.7) Set up a dedicated integration computer.8) Use collective ownership.
443
Testing
1) All code must have unit tests.2) All code must pass all unit tests before it canbe released.3) When a bug is found tests are created.4) Acceptance tests are run often and the scoreis published.
444
Main purpose
1) Working software in timely manner| 2)
445
FDD attributes
1) Development of domain model (mandatory)| 2) Decomposed subject area to features to tasks
446
FDD reporting milestones
1) Domain walk through for specific feature2) Design feature3) Design inspection4) Coding5) Code inspection6) Promote build
447
Feature naming template
[Action] [Result] [Object]| Calculate Total Debit card sale
448
Translating features into code
1) Class Sale, function calculate
449
Best practices 1
1) domain object modeling2) Developing by feature3) Individual class ownership
450
Best practices II
1) Feature team2) Inspections3) Regular builds
451
Best practices III
1) version control| 2) Progress reporting
452
FDD processes
1) Develop overall model2) Build a feature list3) Plan by feature4) Design by feature5) Build by feature
453
FDD primary roles
1) Project manager2) Chief architect3) Development manager4) Experts5) Chief programmers6) Developers7) Testers8) Deployers9) Technical writers
454
When should use FDD
1) accommodate shorter business cycle2) Model driven short iteration3) Want to adopt proven process for frequent tangible accurate reliable solution
455
TDD vs FDD
1) FDD is a method| 2) TDD is agile tool
456
Scrum overview
1) Rigid2) Roles and responsibilities3) Strategic meetings4) Sprint events5) Artifacts
457
Scrum vs Waterfall
1) defined scope vs changing scope2) well defined req vs changing requirements3) reliable estimation vs not all activities known /non estimateable4) Linear vs iterative5) scope /budget vs value
458
scrum 3 pillars
1) visibility2) inspection3) adaptation
459
Scrum structure
1) Well defined roles2) fixed time boxes3) at least 5, no more than 94) strict enforcement6) burndown chart updated after every scrum meeting
460
Pigs and chicken
1) Chicken is involved but pig is committed| 2) rooster - unproductive
461
Product owner responsibilities
1) Determines features, release date, prioritization,budget| 2) protect team members from distraction
462
Development team
1) membership should only change between the sprints2) Cross functional (everything can be done without outside help)3) Create definition of done
463
Scrum master
1) Usually project manager or project leader2) enacting scrum values and practices3) remove impediments, politics, keep team productive4) foster close cooperation
464
Servant leadership
1) Delegates2) Supports initiative3) Emerges from anywhere (power)4) accesses power for the interest of the team5) gives credits to others and takes blame
465
Scrum events
1) Strategy meeting2) Release planning3) Sprint planning4) Sprint review5) Sprint retrospective6) Daily scrum
466
Strategy meeting attendeess
1) product owner(lead and facilitate)2) stakeholder3) scrum master4) project manager
467
Strategy meeting steps
1) Create product vision statement2) Create initial epic user stories3) Create initial detailed user stories4) Prioritization5) Create initial product road map6) Create initial product backlog
468
Release planning overview
1) Plan the specific release (deliver cycle)2) Plan which features will be included3) Prioritization for each release4) Create initial high level estimates for features
469
Release meeting attendeess
1) product owner(lead and facilitate)2) stakeholder3) scrum master4) project manager5) Development team members
470
Release planning guidelines
1) 4 to 8 hours2) PO creates agenda, leads, establishes the ground rules, documents output3) Conducted periodically based on agreed upon release dates
471
Release planning steps
1) Review product vision (PO)2) Review key dates and milestones (PO)3) Present product backlog (PO)4) Dev team asks questions5) Relative estimation6) determine sprint length7) release theme8) Create release product backlog9) stakeholder consensus10) PO commitment
472
Sprint planning overview
1) backlog items to be completed2) detailed task for the backlog item3) identify acceptance criteria according to the definition of done
473
Sprint planning guidelines
1) 2 hours for every week of sprint| 2) PO creates agenda
474
Sprint planning steps(1)
1) Discuss sprint goal(PO)2) Present user stories (PO)3) estimation (planning poker - more specific level than relative size)
475
Sprint planning steps(2)
1) Define and assign tasks2) review workload and determine feasibility3) agreement4) PO decides what will be included
476
Sprint review
1) ensure product acceptance criteria met2) demo3) process feedback4) outline expected functionality in next sprint
477
Sprint review potential roadblocks
1) Not showing actual functionality2) attempting to include last minute functionality3) PO may not accept certain functionality4) Functionality may have worked, but not anymore
478
Sprint review guidelines
1) 1 to 2 hours2) invite all3) why demo did not happen and when will happen
479
Sprint review steps
1) PO present release goal, sprint goal, and new features2) demo by team members3) Field questions4) PO formally accepts and close the sprint
480
Sprint retrospective
1) 1 to 3 hours2) 45 minutes for each week of sprint3) evaluate what done correctly, what can be approved next4) Plan for improvement and potential roadblocks5) Only to the Scrum team
481
Sprint retrospective roadblocks
1) ganging up on individual team member2) individual or process external team are blamed3) may be facilitator for conflict resolution
482
Sprint retrospective steps
1) What went well2) what did not go well3) improvement for negative items4) determine next sprint roadblocks
483
Daily scrum attendees
everybody involved in the project
484
Daily scrum guidelines
1) Daily 15 minutes, same place same time| 2) scrum team members must attend
485
Daily scrum steps
1) What accomplished from last meeting2) what will be working today3) What roadblock in your way4) log parking lot issues and take it offline
486
Scrum staging
The process of defining and prioritizing the nonfunctional requirements for scaling is called staging. Staging occurs prior to the start of the first Sprint and takes just one day. During this day, the nonfunctional scaling requirements for this particular project are determined and placed in the Product Backlog.
487
three level of listening
Level I – Internal Listening - Listening to our own thoughts and judgementsLevel II – Focused Listening - Focus on what the client is sayingLevel III – Global Listening - Listening focus is on more than just the words
488
3 fallacies
1) don't provide executive visibility2) not compatible with portfolio management3) no clear finish date
489
Big challenge in portfolio management with agile
1) Avoid Releasing large quantities of code at once| 2) Separating code into independent release streams by using modular, rather than monolithic
490
Modular design
Modular design also reduces risk in each release because less code is changing with each release. That makes it easier to diagnose and fix problems afterwards.
491
Overview
1) Share one vision, but embrace diversity| 2) Expand agility as your grow
492
Portfolio success
1) Senior leadership must work in partnership with all teams to build a healthy agile culture2) portfolio will only be as successful as its weakest team3) Agile culture is a force multiplier: it naturally scales upward and outward when its core principles are followed and shared
493
PPM long term vs agile short term
1) both to deliver values
494
Don't stifle
1) Executives for stakeholder checkpoint in traditional| 2) Don't need executive checkpoints in agile
495
Agile story points in PPM
1) Measure of business value
496
Agile team part time worker
1) Product development (dedicated team)| 2) IT - Need part time workers (but possible, collaboration with collocation)
497
Agile delivering stories, not milestones
1) Progress - how many stories finished
498
Planned finish date
1) when do we have to finish that| 2) Agile do not have baseline but planning is possible
499
% complete
1) story points accepted / total story points| 2) It changes re-estimation happens, value may change
500
Scope changes
1) Scope changes all the time| 2) add /remove stories
